# Module 3: Collateral Yield Optimization

{% hint style="info" %}
Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)).
{% endhint %}

The PAXG Collateral Yield module converts tokenized gold from a passive holding into an active source of return by using PAXG as collateral in decentralized lending venues. This allows BASIS to preserve gold exposure while allocating borrowed capital into controlled structural alpha capture strategies.

The objective is not directional trading on gold. The objective is capital efficiency under strict risk constraints, deterministic execution rules, and continuous collateral monitoring.

***

## 1. Core Mechanism

In traditional markets, physical gold does not generate native cash flow. Tokenized gold changes this because PAXG can be posted as onchain collateral.

The strategy follows a constrained sequence:

1. Supply PAXG as collateral to an approved lending venue.
2. Borrow against that collateral at conservative loan-to-value levels.
3. Route borrowed capital into BASIS execution systems designed for structural alpha capture.
4. Retain the spread between realized strategy return and borrowing cost, subject to risk limits and market conditions.

{% hint style="success" %}
PAXG is fully supported on BASIS.

* Deposit asset: PAXG
* Receipt asset: stPAXG
* Swap path: PAXG ↔ stPAXG only, at 1:1
* Deposit method: Web3 wallet connection required
  {% endhint %}

### Example workflow

| Step | Action                    | Illustrative Amount                      |
| ---- | ------------------------- | ---------------------------------------- |
| 1    | Post collateral           | 10 PAXG                                  |
| 2    | Borrow against collateral | USD-equivalent value at conservative LTV |
| 3    | Deploy borrowed capital   | BASIS market-neutral execution stack     |
| 4    | Realize spread            | Strategy return minus financing cost     |

The user retains exposure to the underlying gold price through PAXG while the collateral is used in a controlled capital efficiency framework.

***

## 2. Conservative LTV Policy

Loan-to-value management is the primary control variable in this module. Higher LTV increases deployable capital, but it also reduces liquidation distance.

| LTV Level | Risk Profile | BASIS Policy                                       |
| --------- | ------------ | -------------------------------------------------- |
| 30–40%    | Conservative | Preferred safety-first range                       |
| 40–50%    | Moderate     | Maximum operating range under monitored conditions |
| 50–60%    | Aggressive   | Not used in standard operation                     |
| >60%      | Prohibited   | Never used                                         |

BASIS maintains conservative collateral discipline and continuously evaluates:

* collateral ratio
* liquidation distance
* oracle integrity
* borrowing cost drift
* venue-specific stress conditions

If thresholds are approached, the system can reduce exposure by partial repayment, capital rebalancing, or full strategy exit.

{% hint style="warning" %}
Collateralized strategies are governed by state machine risk controls. If risk conditions move outside acceptable bounds, capital preservation takes priority over return generation.
{% endhint %}

***

## 3. Venue Selection Standards

Only venues that meet BASIS operational and risk requirements are eligible.

| Criterion              | Requirement                                                           |
| ---------------------- | --------------------------------------------------------------------- |
| PAXG support           | Native collateral support for PAXG                                    |
| Security review        | Strong independent audit history with no unresolved critical findings |
| Production history     | Established mainnet operating record                                  |
| Liquidity depth        | Sufficient onchain liquidity and borrow capacity                      |
| Oracle design          | Robust multi-source pricing architecture                              |
| Liquidation model      | Transparent and predictable liquidation mechanics                     |
| Operational resilience | Reliable uptime and incident response history                         |

Venue approval is based on both protocol-level review and execution-layer compatibility with BASIS routing systems.

***

## 4. Risk Controls

| Risk                   | Description                                                 | Mitigation                                                    |
| ---------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- |
| Gold price decline     | A drop in gold price can compress collateral coverage       | Conservative LTV, continuous monitoring, automated de-risking |
| Borrow rate expansion  | Financing cost can rise and compress strategy spread        | Dynamic threshold checks and rapid exit logic                 |
| Smart contract failure | Vulnerability or protocol malfunction in a lending venue    | Strict venue filtering and exposure caps                      |
| Oracle failure         | Distorted pricing can affect collateral health calculations | Oracle quality requirements and venue selection standards     |
| Liquidity stress       | Reduced market depth can impair adjustments                 | Capacity limits and staged execution logic                    |

***

## 5. BASIS Infrastructure Context

This module is supported by the same operating philosophy used across BASIS systems:

* deterministic execution
* math-constrained capital allocation
* state machine risk controls
* proprietary routing infrastructure
* structural alpha capture over discretionary prediction

BHLE infrastructure characteristics include:

* sub-50μs latency
* 100K+ OPS throughput
* proprietary routing architecture built for execution precision

These controls are designed to reduce slippage, improve response time under stress, and preserve predictable system behavior.

***

## 6. User Asset Flow on BASIS

For PAXG users, the asset path is standardized.

{% tabs %}
{% tab title="Deposit" %}

1. Open Dashboard → Assets
2. Select PAXG
3. Connect a supported Web3 wallet
4. Confirm the PAXG deposit transaction
5. Receive balance credit in the Funding Wallet
   {% endtab %}

{% tab title="Swap" %}

1. Open Dashboard → Assets
2. Select swap from PAXG to stPAXG
3. Confirm 1:1 conversion
4. Pay swap fee of 0.01%
5. stPAXG appears in the Staking Wallet
   {% endtab %}

{% tab title="Stake" %}

1. Open Dashboard → Stake
2. Select stPAXG
3. Choose booster duration if applicable
4. Confirm full-position staking action
5. Rewards accumulate in real time as stPAXG
   {% endtab %}

{% tab title="Unstake" %}

1. Open Dashboard → Stake
2. Select the staked stPAXG position
3. Unstake when the lock-up period has ended
4. The claimable amount is auto-credited to the Staking Wallet as stPAXG
5. Convert stPAXG back to PAXG if desired
   {% endtab %}
   {% endtabs %}

{% hint style="info" %}
Wallet model on BASIS:

* Funding Wallet: native tokens only for deposit and withdrawal
* Staking Wallet: stTokens only for staking and reward accrual

For PAXG:

* Deposit/withdraw asset: PAXG
* Stake/earn asset: stPAXG
  {% endhint %}

***

## 7. Fees and Operational Parameters

| Item            | Value                |
| --------------- | -------------------- |
| Deposit fee     | 0%                   |
| Withdrawal fee  | 0.05%                |
| Swap fee        | 0.01%                |
| Deposit asset   | PAXG                 |
| Withdraw asset  | PAXG                 |
| Swap ratio      | PAXG ↔ stPAXG at 1:1 |
| Withdrawal time | 1–6 minutes          |

### Booster schedule

| Lock Period | Booster    |
| ----------- | ---------- |
| 14D         | +10%       |
| 30D         | +20%       |
| 90D         | +50%       |
| 180D        | +100% (2×) |

{% hint style="warning" %}
Fixed pools can only be unstaked after the lock-up period ends. Early exit is not available.

Unstaking is processed as a full-position action only. Partial unstake is not supported.
{% endhint %}

***

## 8. Status

The PAXG Collateral Yield module is live and active within the BASIS asset framework, subject to venue eligibility, risk limits, and collateral conditions.

Availability may vary based on:

* venue capacity
* collateral health thresholds
* borrowing cost environment
* execution suitability under current market structure

For operational questions, contact <support@basis.pro>. For research or methodology inquiries, contact <research@basis.pro>.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.basis.pro/paxg-integration/modules/collateral-yield.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
