Key Concepts
iAsset Lifecycle & Delegation
The lifecycle of assets supplied as liquidity to create iAssets is as follows: upon deposit, users are credited with pre-minted iAssets that are not yet transferable. At regular intervals, the supplied assets are locked as collateral to borrow $SUPRA, which is then delegated to Supra delegation pools, at this point, the assets are officially registered as collateral. After delegation, a mandatory holding period applies before users can finalize the mint. Once it ends, users can mint their pre-minted iAssets, fully activating them as live iAssets. The histogram above shows how balances transition across these stages for a representative iAsset.
Deposit Limits
The system can enforce per-asset deposit limits in the vault to safeguard fiscal sustainability, diversify available liquidity, and match inflows with operational capacity and policy requirements. Any deposit attempt that breaches these limits will fail, and the vault will not accept the request.
iAssets
iAssets are reward-bearing tokens native to the Supra chain, functioning as vouchers that represent user ownership in IntraLayer vaults. The term “iAsset” is derived from IntraLayer Asset, holding which brings two primary sources of yield. Users earn staking rewards from $SUPRA borrowed against their collateralized deposits and delegated to validator pools. They can then deploy iAssets as liquidity across Supra DeFi to earn additional protocol fees on top of staking rewards. Over time, as DFMM and other initiatives launch, and IntraLayer Vaults evolve into liquidity pools, iAsset holders may also earn AMM trading fees, followed by yield from actively managed strategies. Consequently, iAssets become multi-yield assets, aligning incentives among validators, liquidity participants, and Supra-based DeFi use cases.
Pre-minted iAssets
Step 1: Pre-minting
Upon deposit, the asset is pre-minted to the user’s account.
A pre-minted iAsset represents the user’s right to mint at a later time.
Pre-minted iAssets do not accrue rewards.
Step 2: Final Minting
After a waiting period of two epochs, the user can finalize the mint.
Once fully minted, iAssets begin generating rewards.
Users must complete this step to start earning.
Delegation Per Pool Analytics
The PoEL system delegates assets to delegation pools that are whitelisted for use. PoEL effectively acts as the delegator, and the design targets a relatively even stake distribution across pools. Within each pool, delegated tokens move through lifecycle states, the diagram above shows three states per delegation pool for $SUPRA delegated by PoEL.
Active - Assets are submitted and begin earning rewards in the delegation pool. Rewards generated by the borrowed $SUPRA that is delegated and in the active state are distributed to iAsset holders.
Pending Inactive - After the borrowed principal is unstaked from the delegation pools, tokens move from Active to Pending Inactive, indicating they are being prepared for withdrawal. Unstaking can occur for several reasons, for example, shifts in the collateral’s value relative to $SUPRA or user withdrawals from liquidity (collateral) pools, both of which may require realigning staked amounts with collateral value.
Inactive - Staked $SUPRA (by PoEL) that is now withdrawable from the pool. After the lockup cycle, assets in Pending Inactive become withdrawable and enter Inactive state.
Delegation Metrics
Delegation metrics present the system’s delegation states and their historical values:
Borrowed Amount — This metric counts all $SUPRA borrowed from PoEL vaults and staked in delegation pools, including tokens in active, pending_inactive, and inactive states.
Borrowable Amount — Total $SUPRA deposited into the PoEL vault by the protocol governance from ecosystem funds, available to be borrowed as principal and delegated to the delegation pools.
Delegated Assets — $SUPRA that, per system accounting, is delegated to pools and currently in the Active state. This accounting state is updated after each delegation or unstaking operation.
Staked Assets — $SUPRA currently staked in delegation pools and in the Active state, as fetched from the pools. This amount includes accrued rewards,since rewards earned on tokens in the Active state are auto-added back into Active.
Available Liquidity — The total nominal, $SUPRA-denominated value of user-supplied collateral in the liquidity pools.
Vault Balance — The $SUPRA balance held in the PoEL vault, including available-to-borrow $SUPRA and any earned rewards that have been credited to the vault but not yet claimed by users.
In the webpage charts, data can be aggregated by interval (e.g., weekly, monthly). When aggregation is applied, the value shown for each day or week is the period’s end-of-period value (the last entry of that interval).
Staking Rewards for iAsset Holders
Multiple factors can affect the rewards distributed per asset and, consequently, that asset’s APY. In the diagram above, Total Distributed Rewards shows the cumulative rewards paid to the specific iAsset holders over time.
Key drivers that affect the APY rate include (non-exhaustive):
Collateral vs. Borrowable Amount: The relationship between total collateral supplied and the total borrowable SUPRA available in the system to match collateral with borrowable SUPRA.
Portfolio Weight Deviation: How far the asset’s current weight in the collateral portfolio is from its target (influences collateralization-rate dynamics).
Stimulus Reward Rate: The applied rate for incentivizing the submission of iAssets to liquidity pools of DeFi applications in the Supra ecosystem.
Asset Desirability Score: The priority or weighting assigned to the asset within the system, based on its value as a source of liquidity.
Capital Efficiency Coefficient: How efficiently the submitted collateral can be converted into productive yield.
These inputs jointly affect reward distribution and, therefore, realized APY. The displayed APY values are dynamic estimates and may differ from actual results.
Total borrowable amount
The total amount of $SUPRA available for borrowing is capped by protocol governance. Each epoch, the system aggregates all user-supplied collateral, converts it into $SUPRA-equivalent terms, and adjusts by the applicable collateralization rates. Based on this adjusted collateral value, the protocol determines how much $SUPRA can be borrowed and delegated to validator pools, generating staking rewards for iAsset holders.
If adjusted collateral < borrowable cap, the system borrows and delegates an equal amount of $SUPRA.
If adjusted collateral > borrowable cap, borrowing and delegation are capped, leaving excess collateral unmatched.
This mechanism ensures predictable borrowing capacity, preventing reward dilution and reinforcing economic security. Governance retains flexibility to adjust the borrowable cap, directly influencing the scale of delegation and the APYs earned by iAsset holders.
Asset Weights: Target vs. Current
Each collateral asset in the system has a target portfolio weight, designed to encourage diversification and strengthen Supra’s economic resilience. In practice, the actual composition of collateral may deviate from these targets. To correct imbalances, the system dynamically adjusts an asset’s collateralization rate. Specifically, as the Composition Gap (the difference between target weight and actual share) widens, the system raises that asset’s collateralization rate. A higher rate reduces its effective loan-to-value (LTV) ratio, which lowers the yield for a particular iAsset. This design creates market-driven incentives that nudge collateral supply toward the system’s optimal portfolio mix. Governance can fine-tune these parameters to maintain balance and resilience across the ecosystem.
We calculate the collateralization rate for asset X as follows:
Here, pmin represents the minimum collateralization rate available in the system, while pImax and pIImax are the maximum collateralization rates for the asset, corresponding to the Second and intervals of the function, respectively. weX* represents target weights of asset X and wXe represents the weight of the asset in the collateral portfolio in e-th epoch.
Asset desirability score
An asset’s desirability score influences its APY relative to other admissible assets, which will have particular importance once the DFMM and other Supra native DeFi liquidity‑pool primitives are live. IntraLayer vaults will then function as both DFMM pools and liquidity sources for other protocols. Each asset’s desirability score is based on the aggregate capital efficiency of its pool, favoring higher-efficiency assets.
Capital efficiency coefficient
The protocol’s collateral pools would also act as shared liquidity for the DFMM and for other DeFi protocols that integrate with them as liquidity pools. To align rewards with capital efficiency and efficient utilization of the liquidity, the mechanism adaptively withholds or releases rewards over time: it distributes less when aggregate capital efficiency of whole system is below target and more when it is above target. Governance/admin-set parameters, and, in future, on-chain programmatic mechanisms, can control how deviations from the target efficiency translate into reward distribution. In PoEL, we introduce a governable minimum-payout floor and an efficiency-responsive release factor (capital efficiency coefficient), ensuring both liveness and efficiency alignment.
where r’i represents the distributable rewards after accounting for the capital efficiency coefficient in allocation cycle i; r_i is the newly distributable rewards accrued in cycle i; p_i is the minimum payout, i.e. the the smallest portion of the distributable rewards that must be distributed in cycle i, which is governed by governance/admin; c_i (capital-efficiency coefficient) scales the base amount r_i, e.g., c_i=1.5 allows distributing 1.5×r_i, limited by the remaining budget; b_i is the reward budget carried forward from prior cycles where distributable rewards were withheld due to poor capital efficiency.
The reward budget then updates as:
Stimulus Rewards
One of the main objectives of the PoEL protocol is to bootstrap Supra’s DeFi ecosystem by attracting a diversified set of collateral and establishing iAssets as a core, yield-bearing asset class. To achieve such adoption PoEL also encourages iAsset utility by incentivizing their use as liquidity across DeFi protocols. To that end, PoEL introduces a complementary lever: Stimulus Rewards, paid at a rate we refer to as - Stimulus Reward Rate.
Stimulus Rewards are an earmarked budget of SUPRA distributed to the liquidity pools of DeFi applications, where iAssets have been submitted. These rewards are intended to be passed through to LPs (responsibility of DeFi apps), potentially increasing the effective yield for providing iAsset liquidity (on top of any fees those apps already pay to their LPs). The applicable rate for stimulus rewards, i.e. the Stimulus Reward Rate, is a configurable parameter (0–100%) that withholds a portion of the baseline rewards that would otherwise accrue directly to passive iAsset holders but is instead redirected to eligible liquidity pools in the form of Stimulus Rewards.
Operationally:
A fraction of baseline rewards equal to the Reward-Reduction Rate is diverted into the Stimulus Rewards budget each epoch.
The budget is distributed to registered pool addresses of DeFi apps operating in Supra’s ecosystem, wherever iAssets are supplied as liquidity or as collateral
To qualify, integrated apps are expected to redistribute received rewards to their liquidity providers (pass-through), so that supplying iAssets to liquidity pools potentially is more attractive than simply holding them.
Governance/parameters (e.g., rate, pool eligibility, allocation weights) can be tuned over time to balance between rewarding passive holders and accelerating iAsset liquidity depth where it is most valuable.
In short, PoEL channels part of the earned staking rewards toward active iAsset liquidity, amplifying TVL, market depth, and utility while keeping the mechanism transparent, configurable, and aligned with ecosystem growth.
Stimulus Reward Distribution Mechanism
The stimulus reward distribution mechanism may evolve, starting with a Merkle‑tree‑based approach.
At regular intervals, the system computes the distributable rewards for each liquidity pool and updates that pool’s cumulative entitlement (i.e., total rewards accrued to date). To make distribution efficient and verifiable, the system encodes the snapshot into a Merkle tree, a cryptographic structure that proves “my entry is included” without storing the full list on‑chain. In this approach, each pool’s entry (address + cumulative amount) becomes a leaf. Leaves are combined layer by layer into a single root hash (a 32‑byte fingerprint of the list), which the system publishes on‑chain. This root commits to the snapshot’s contents. Note, that entitlements are computed off‑chain and may change over time, e.g., rewards could be allocated proportionally to the nominal value of iAssets held per pool or by other evolving criteria.
In this approach, pools claim rewards by submitting their leaf hash (address + cumulative amount), a Merkle proof, and the current on‑chain root. The contract verifies the proof and, if valid, releases the allocable amount (new cumulative − previously claimed). This enables repeated claims without double‑counting. Backend automation may also claim on behalf of pools to streamline the process.
The screenshot above highlights two components:
Base APY is an off-chain pool-level estimate: a weighted average of each iAsset’s base APY (what passive holders earn), weighted by the pool’s nominal iAsset liquidity per iasset.
Stimulus-adjusted APY is an off-chain pool-level estimate of the total APY earned from the PoEL program by the pool. It is computed at each root submission using the pool’s SUPRA-denominated nominal iAsset value and the total SUPRA rewards distributed
Reward Metrics
Reward Metrics aggregate key reward metrics, including
Allocated Reward Balance — the total tokens earned by PoEL for users that have not yet been distributed.
Reward Budget — the carry-over budget from prior cycles in which distributions were withheld due to low capital efficiency.
Stimulus Rewards Accumulated — the total rewards earmarked as stimulus, pending allocation across liquidity pools to incentivize using iAssets as liquidity.
Total Distributable Rewards — the cumulative amount already distributed plus currently distributable to users, excluding stimulus rewards.
Last updated