Whitepaper
The Dera Protocol
A Yield Infrastructure Layer for Digital Assets
Dera Finance · March 2026 · v1.2
This document is provided for informational purposes only. It does not constitute financial, legal, or investment advice. The Dera Protocol is permissionless infrastructure; users interact with it at their own discretion and bear all associated risks. See Section 10 and the Terms and Conditions for full disclosure.
Abstract
The Dera Protocol is a permissionless, asset-agnostic yield infrastructure layer for digital assets. At its core is the Dera Engine: a modular smart contract system that continuously allocates and rebalances capital across governance-approved DeFi integrations, compounding returns directly into the on-chain exchange rate of protocol-issued assets. Unlike rebasing yield mechanisms, this model eliminates the accounting friction that complicates DeFi integration for most yield-bearing tokens.
DERA is the first asset issued on this infrastructure. It is a yield-bearing, fully liquid, permissionless token backed by USDC, structured as an Asset-Referenced Token under MiCA. Yield accrues passively into the exchange rate. No staking, locking, or active management is required from holders.
The Dera Engine is built to operate identically regardless of the underlying asset type. The infrastructure that powers DERA today can be extended to tokenised equities, real-world assets, commodities, and other asset classes as the protocol matures. This paper covers the protocol architecture, token mechanics, security model, and compliance posture.
1. Introduction
Digital assets have resolved meaningful inefficiencies in global finance: settlement speed, custody transparency, borderless transferability. The problem they have not resolved is capital efficiency.
The dominant digital asset category by volume, stablecoins, holds hundreds of billions in value while generating no return for holders. Tokenised real-world assets replicate traditional instrument exposure without improving yield characteristics. Cryptocurrencies require active management to generate returns. DeFi offers yield, but demands technical expertise and risk tolerance that most capital holders are not willing to assume.
The result is a structural gap. Vast pools of on-chain capital remain static, held in assets engineered for stability or speculation, with no built-in mechanism to put that capital to work.
Dera is designed to close this gap. The protocol introduces a yield layer that operates beneath the asset itself, routing capital through governance-approved DeFi integrations and compounding returns directly into token value. Users hold a liquid, transferable asset and receive yield automatically, without ever interacting with the underlying strategies.
The Dera Engine is open infrastructure. Its logic is entirely on-chain, its integrations are governance-controlled, and its exchange rate is publicly verifiable at all times. Dera does not custody assets or manage capital on behalf of users.
1.1 Ecosystem Overview
| Component | Role |
|---|---|
| Dera Labs Limited | UK-registered parent entity overseeing the development of Dera Finance and the Dera Protocol. |
| Dera Finance | The organisation developing and maintaining the protocol infrastructure. |
| Dera Protocol | The decentralised application layer enabling automated yield generation across digital asset classes. |
| Dera Engine | The modular smart contract system responsible for yield sourcing, capital allocation, and risk management. |
| DERA | The first asset issued on the protocol. A yield-bearing, fully liquid token backed by USDC. |
2. The Yield Gap in Digital Assets
Across every major digital asset category, capital efficiency remains an unresolved constraint. On-chain capital overwhelmingly sits idle, held in assets whose design prioritises stability, accessibility, or speculation over return. The table below maps the structural limitation of each relevant asset class.
| Asset Class | Structural Limitation |
|---|---|
| Stablecoins | Engineered for price stability and broad acceptability. Their design prioritises peg reliability over capital efficiency, leaving holders with no mechanism to generate return. Hundreds of billions in on-chain value generate no yield for the participants who hold it. |
| Yield-Bearing Stablecoins | Most generate yield through off-chain mechanisms such as Treasury bill holdings or algorithmic stabilisation, introducing TradFi dependency or systemic peg risk. Yield is typically distributed as rebasing supply rather than accruing into token value, creating friction in DeFi contexts. Those that do accrue yield via exchange rate appreciation have their yield source fixed at the protocol level, meaning it cannot be augmented without replacing the underlying asset entirely. The Dera Engine layers additional on-chain DeFi yield on top of any existing base return. |
| Tokenised RWAs and ETFs | Tokenised equities, ETFs, and funds replicate traditional instrument exposure with the settlement and custody benefits of blockchain infrastructure. They do not improve on the yield characteristics of the underlying asset. Dividend income and coupon payments, where applicable, remain subject to the same distribution cadence and custody dependencies as their off-chain equivalents. |
| Tokenised Commodities | Gold, silver, oil, and other commodity-backed tokens are widely held but generate no intrinsic on-chain yield. The underlying commodity produces no yield by nature; the tokenised wrapper does not change this. |
| Cryptocurrencies | Native yield typically requires staking, delegation, liquidity provision, or active position management, each carrying its own risk profile and overhead. For capital holders seeking passive return, the yield available from crypto holdings is effectively inaccessible without active engagement. |
| CBDCs | Most CBDC designs apply holding limits or cap remuneration rates to prevent deposit migration from commercial banks. As CBDC infrastructure matures on public blockchain networks, a supplemental on-chain yield layer becomes a natural application of the Dera Engine model. |
3. The Dera Engine
The Dera Engine is the protocol's core execution layer. It is a modular smart contract system that continuously monitors, allocates, and rebalances capital across governance-approved DeFi integrations to optimise risk-adjusted yield. Every allocation decision is recorded on-chain and publicly verifiable.
Rather than requiring participants to source, evaluate, and manage individual DeFi positions, the Engine handles this continuously and at scale. Returns compound directly into the exchange rate of protocol-issued assets, reaching all holders simultaneously without any action required on their part.
3.1 Architecture
| Principle | Implementation |
|---|---|
| Configurable Underlying Asset | The underlying asset composition of a running engine can be adjusted through governance, allowing the protocol to adapt to market developments and adopt stronger base assets as they emerge, without requiring any action from existing holders. |
| Asset-Agnostic Deployment | A new engine instance can be deployed to create a yield-bearing version of any tokenised asset class. Any asset on a supported blockchain can in principle be enhanced with on-chain yield, without modifying existing protocol infrastructure. |
| Modular Architecture | Integrations with external protocols are implemented as isolated connector contracts. New yield sources can be added through governance without modifying core protocol logic. Connectors are upgradeable via UUPS proxy patterns, enabling targeted upgrades without full redeployment. |
| Dynamic Allocation | Capital is continuously monitored and rebalanced across active integrations to maximise risk-adjusted returns. Allocation weights are configurable by governance and tracked on-chain. |
| Adaptive Risk Management | Only battle-tested, independently audited protocols are eligible for integration. Individual connectors can be paused without affecting the broader system or restricting participant withdrawals, isolating risk at the pool level. |
| Omnichain Interoperability | The Engine issues tokens on the OFTv2 standard via LayerZero, enabling native deployment across all major EVM-compatible networks from a single engine instance, without bridges or wrapped tokens. |
| Permissionless Exits | Withdrawals are never pausable at the system level. Any participant may redeem their holdings for the underlying asset at any time, regardless of the status of any individual connector. The Safety Escrow provides a fallback redemption path if a connector becomes unavailable. This is enforced at the contract level, not as a policy. |
3.2 Strategy Selection
In the initial deployment phase, integration selection and capital allocation are managed by the Dera core team, composed of protocol engineers and DeFi analysts. All decisions are executed under multisig governance and are publicly verifiable on-chain. Governance control is intended to be progressively extended to token holders as the protocol matures.
3.3 Yield Sources
The Dera Engine generates yield across the following strategy categories. The active list of protocol integrations is maintained at docs.derafi.io/technical-documentation/user-flow and updated as allocations change.
- Liquidity provision and AMM fees from established decentralised exchanges
- Lending yield from governance-approved DeFi lending platforms
- Dynamic rebalancing and yield aggregation across active integrations
- Stablecoin incentive programmes from governance-approved platforms
Strategy selection is governed by a risk assessment framework that evaluates security track record, TVL depth and stability, smart contract audit coverage, and historical yield sustainability. No integration is permanent. All are subject to ongoing governance review.
4. DERA: Token Mechanics
DERA is the first asset issued on the Dera Protocol: a yield-bearing, fully liquid, permissionless stablecoin alternative backed by USDC, designed for direct integration across DeFi infrastructure. Unlike static stablecoins that generate no return for holders, DERA accrues value continuously while remaining fully deployable. Rather than distributing yield through supply changes, returns compound into TVL, increasing the redemption value of each token over time. Supply changes only when participants mint or redeem.
This exchange rate model is a deliberate design choice. Rebasing tokens, which expand supply to distribute yield, introduce accounting complications in AMM pools and lending protocols. By accruing yield into the exchange rate instead, DERA avoids these complications entirely and integrates natively with existing DeFi infrastructure.
4.1 Exchange Rate Mechanism
The value of each DERA token is determined by the following on-chain formula:
Exchange Rate = Total Value Locked (TVL) / Total DERA Supply
TVL is computed by summing the current value of assets held across all active connectors, sourced via Chainlink price feeds. As the Engine generates returns, TVL grows while supply remains constant, and the exchange rate increases proportionally. A full formal derivation, including minting, redemption, fee deduction, and yield accrual mechanics, is provided in the Technical Appendix.
The exchange rate reflects actual protocol performance. It may increase as strategies generate returns, remain flat during periods of low yield, or decline in the event of losses in underlying integrations. The system is built for transparency, not for the guarantee of returns. The Dera Engine retains a 10% performance fee on yield generated across active integrations. Yield accrues gross into TVL, and the fee is collected via a discrete withdrawPerformanceFee() call when predefined thresholds are reached. At the point of collection, TVL is reduced by the fee amount transferred to the fee recipient, and the exchange rate may step down by a corresponding margin. The exchange rate continues to accrue between fee collection events.
4.2 Minting and Redemption
Any participant may mint DERA by converting a whitelisted stablecoin at the prevailing exchange rate, or redeem DERA for the underlying asset at any time, without approval from any party. Redemption is permissionless and enforced at the smart contract level. This is a protocol guarantee verifiable on-chain at the DERA token contract (0xb1431da6d57646a166bb23e1f6fe92a134709d75), not a policy commitment.
A configurable withdrawal fee, currently set at 0% and capped at 0.1% by the protocol, may be applied at the point of redemption. All fee parameters are governed via the DeraAdmin contract and are publicly verifiable on-chain. When DERA is transferred, the recipient inherits the same redemption rights.
4.3 Underlying Asset Composition
DERA is currently backed by USDC, selected for its regulatory standing, on-chain liquidity depth, and broad DeFi protocol support. If a stronger or more optimal stablecoin composition emerges, the underlying asset can be adjusted through governance without requiring any action from existing holders. Current composition is verifiable on-chain at all times.
4.4 Token Standard and Interoperability
DERA is implemented on the ERC-20 standard and the OFTv2 (Omnichain Fungible Token v2) standard via LayerZero. This enables native cross-chain transfers across all major EVM-compatible networks without bridges, wrapped tokens, or value loss. Full compatibility with wallets, decentralised exchanges, DeFi protocols, and payment infrastructure is maintained through the ERC-20 standard.
4.5 Key Use Cases
AMM liquidity provision. Deploy DERA in liquidity pools instead of static stablecoins, earning AMM trading fees alongside continuous protocol-level yield accrual. Note that the pool market price of DERA and the Engine exchange rate are two distinct values. Any holder may redeem directly through the protocol at the prevailing on-chain exchange rate at any time, regardless of pool market conditions. See Token Dynamics for a full explanation.
DeFi collateral. Use DERA as collateral in lending protocols, combining yield accrual with capital efficiency. The exchange rate mechanism means collateral value appreciates over time rather than remaining static.
Institutional settlement. ERC-20 compatibility and permissionless redemption enable direct integration with existing payment and settlement infrastructure, without intermediaries or custody dependencies.
Cross-chain deployment. Move DERA natively across EVM-compatible networks via LayerZero OFTv2 for capital efficiency without bridge risk or wrapped token complexity.
Treasury reserve management. DAOs and institutional balance sheets can maintain full liquidity while generating on-chain yield on held capital, replacing idle stablecoin reserves with a productive equivalent.
5. Expanding the Yield Layer
The Dera Engine operates identically regardless of the underlying asset type. The asset classes below represent the logical expansion path for the protocol, ordered from nearest-term to longest-horizon. Each will be governed by the same principles as DERA: automatic yield generation, full liquidity preservation, permissionless control, and transparent on-chain execution. Development is subject to regulatory alignment and governance approval.
| Asset Class | Yield Application |
|---|---|
| Static and Yield-Bearing Stablecoins | Static stablecoins are converted into yield-bearing equivalents with no change to economic exposure. Yield-bearing stablecoins receive Engine-level DeFi yield on top of their existing base return, producing a compounded result not achievable through the underlying asset alone. |
| Tokenised Commodities | Yield generation on tokenised holdings such as gold, silver, and oil: asset classes that currently carry no intrinsic on-chain yield. |
| CBDCs | Supplemental on-chain yield on CBDC holdings as public blockchain infrastructure for central bank currencies matures, without altering their monetary properties. |
| Tokenised Equities / Stocks | Dividend reinvestment and DeFi exposure compounded into token value, transforming traditionally passive equity holdings into yield-generating positions. |
| Tokenised Government Bonds | Additional on-chain yield layered on top of existing coupon returns, without lock-up requirements or TradFi custody dependency. |
| Tokenised Corporate Debt and Structured Credit | Automated yield capture for structured credit products and securitised loan instruments. |
| Real-World Assets (Broader) | Any tokenised real-world asset not covered above: infrastructure, real estate, trade finance, and emerging asset classes as the tokenisation ecosystem develops. |
6. Technical Overview
The Dera Protocol is built on a non-custodial, modular smart contract architecture. Capital flows from participant wallets directly to external DeFi protocols via the Engine's connector system. No protocol component holds or controls user funds at any point. A detailed technical specification, including contract flow diagrams and user flow documentation, is available at docs.derafi.io/technical-documentation.
6.1 Capital Flow
The diagram below illustrates the full movement of capital through the protocol, from participant to external DeFi integrations and back.
Participant Wallet
| Convert USDC at prevailing exchange rate
v
Dera Engine
| Validate input and calculate allocation weights
| Distribute capital across connectors proportionally
v
Connector 1 Connector 2 Connector 3 ...
| | |
v v v
External DeFi Protocol Integrations
(lending pools, AMMs, incentive programmes)
| Yield accrues via LP token appreciation or rebase
v
TVL increases => Exchange Rate = TVL / Total DERA Supply
| Each DERA token redeemable for proportionally more USDC
| On redemption: burn DERA, withdraw proportional USDC
| (Safety Escrow as fallback if connector unavailable)
v
Participant Wallet
All steps execute on-chain. No manual intervention is required from the participant at any stage.
6.2 How It Works
The following describes the standard flow using DERA as the illustrative example. The same flow applies to any asset issued on the Dera Protocol.
- A participant converts USDC into DERA at the prevailing exchange rate via the Dera Engine's smart contract interface
- The Engine routes the capital through governance-approved connector contracts into active DeFi integrations
- Yield accumulates within those integrations, increasing the protocol's TVL
- The exchange rate adjusts upward to reflect TVL growth; each DERA token becomes redeemable for a proportionally greater amount of USDC
- At any time, the participant may redeem DERA for USDC at the current exchange rate, without approval from any party and regardless of the status of any individual connector
6.3 Protocol Contracts
The Dera Protocol is built on four primary contract components. Deployed contract addresses are maintained at docs.derafi.io/technical-documentation/user-flow.
DERA Token Contract. Governs minting, redemption, and exchange rate logic. Mint and burn functions are callable exclusively by the Engine contract. Deployed at 0xb1431da6d57646a166bb23e1f6fe92a134709d75.
Dera Engine. Manages capital allocation and connector orchestration. All admin-level actions are executed under multisig governance.\
Dera Safety Escrow. Emergency reserve layer that acts as a recovery route if a connector fails or becomes unresponsive. Controlled exclusively by the Engine contract.
Protocol Connectors. Isolated, upgradeable contracts managing capital flows to individual DeFi integrations.
7. Security and Trust Model
Security is a foundational design constraint of the Dera Protocol, not a feature layer. Every component of the system, from access control to contract upgradeability, was architected under the assumption that any single point of trust is a liability.
7.1 Audited and Battle-Tested
All core protocol smart contracts were independently audited by Hacken (commit hash 4b04fec66620b39bcb67ca0686af0a8a3ef60821). The audit covered security, code quality, and documentation, with 100% test coverage. The protocol has been extended significantly since the audit; all additions follow the same security architecture as the audited core. Full details are documented at docs.derafi.io/technical-documentation/security.
7.2 Non-Custodial by Architecture
Capital flows directly from participant wallets to external DeFi protocols via smart contract connectors. No team member or external party can access or redirect user funds at any point. Capital allocation decisions are currently executed by the core team under multisig governance, with all actions emitting structured on-chain events that are publicly verifiable. No unilateral action by any single team member is possible.
Withdrawals are never pausable. Any participant may exit at any time, regardless of the status of any individual connector, with the Safety Escrow providing a fallback redemption path in the event of connector failure. This is enforced at the contract level.
7.3 Access Control and Governance Security
The protocol implements strict, layered access control using OpenZeppelin V5 primitives. Only the Engine contract can mint or burn DERA tokens. All role changes and administrative actions emit structured on-chain events for full traceability. Ownership and role transfers follow a mandatory two-step process that prevents accidental or malicious privilege assignment.
All governance-level changes require multisig approval. Administrative role transfers are subject to a time-buffered process in compliance with MiCA Article 30 on operational resilience. The full scope of access controls is detailed in the technical documentation.
7.4 Additional Protections
Re-entrancy protection. All external user functions implement OpenZeppelin's nonReentrant modifier, preventing double-spend attacks.
Chainlink oracle integration. Token values are calculated via Chainlink price feeds, providing a manipulation-resistant source for TVL tracking.
Upgradeable connectors. Protocol connectors use UUPS proxy patterns, enabling security patches and feature additions without full redeployment.
Engine migration. The setNewEngine() function enables full engine logic upgrades while preserving all user balances and existing contract state.
Fund recovery. A recovery mechanism retrieves capital mistakenly transferred directly to Engine or connector contracts.
Immutable token logic. Core DERA token logic and user balances are immutable once deployed.
A full specification is available in the technical documentation.
7.5 Bug Bounty
Dera operates a community bug bounty programme. Valid vulnerability disclosures are reviewed and rewarded at the core team's discretion. Submissions should be directed to security@derafi.io.
8. Compliance and Regulatory Posture
Dera Finance is an infrastructure provider, not a financial institution or custodian. The Dera Protocol provides open, permissionless tooling through which participants interact with DeFi yield strategies directly. Dera does not manage capital on behalf of users, does not take custody of assets, and does not act as an intermediary in any transaction.
8.1 MiCA Alignment
All assets issued on the Dera Protocol are structured as Asset-Referenced Tokens (ARTs) under the EU's Markets in Crypto-Assets Regulation (MiCA). The protocol incorporates the following design elements in support of compliance readiness across all issued assets.
Transparent asset backing. All Dera assets are backed by publicly listed, verifiable underlying assets with on-chain composition verifiable at all times.
On-chain traceability. All protocol logic, capital flows, and administrative actions are publicly verifiable on-chain.
Controlled administrative functions. All changes are gated by multisig governance, with role transfers subject to time-buffered processes in compliance with MiCA Article 30.
Operational continuity. The Safety Escrow and pausable connector architecture ensure user fund accessibility is maintained under failure conditions.
Dera Finance is not currently licensed or formally approved under MiCA or any other regulatory framework. The protocol is structured with MiCA alignment as a foundational design principle. Dera Labs Limited is actively engaged in regulatory alignment efforts across relevant jurisdictions as frameworks mature.
8.2 Environmental Disclosure
In accordance with Article 6(13) and Annex I, Section 3(g) of Regulation (EU) 2023/1114 (MiCA), Dera Finance provides the following disclosure for all crypto-assets currently issued on the Dera Protocol.
All Dera assets are currently issued on the Ethereum blockchain, which employs a Proof-of-Stake (PoS) consensus mechanism. PoS does not rely on energy-intensive mining. Following Ethereum's transition to PoS, the network's estimated annual energy consumption is approximately 0.0026 TWh, with associated carbon emissions under 870 tonnes of CO2-equivalent per year, a reduction exceeding 99.95% compared to the prior Proof-of-Work model. The PoS model also eliminates the electronic waste associated with mining hardware.
The issuance and maintenance of Dera Protocol assets do not give rise to material adverse impacts on the climate or the environment. Future assets deployed on additional networks will be subject to separate environmental assessment at the time of issuance.
9. Risk Considerations
Participants should understand and accept the following risks before interacting with the protocol. This is not an exhaustive risk disclosure. For a full overview, refer to the Terms and Conditions.
9.1 Third-Party Protocol Risk
The Dera Engine integrates with external DeFi protocols to generate yield. These integrations carry inherent risks including smart contract vulnerabilities, stablecoin depeg events, liquidity pool insolvency, and governance failures in third-party systems. Dera does not audit or guarantee the security of integrated protocols. Participants are responsible for independently assessing their exposure to underlying integrations.
9.2 Smart Contract Risk
All core Dera contracts have undergone independent third-party audit. The protocol has since been extended with features not covered by the initial audit. No smart contract system is entirely free from the risk of undiscovered vulnerabilities. Participants should review the audit report and post-audit additions at docs.derafi.io/technical-documentation/security before committing capital.
9.3 Redemption and Backing Risk
DERA is redeemable for the underlying asset at any time at the prevailing exchange rate. Redemption value depends on the solvency of the protocol and the performance of active yield strategies. A withdrawal fee of up to 0.1% may apply at the point of redemption. In the event of significant losses in underlying integrations, the exchange rate may decline, reducing redemption value.
9.4 Regulatory Risk
The legal classification of Dera assets may evolve depending on jurisdictional developments. While Dera Finance structures its assets with MiCA alignment as a design principle, formal regulatory approval is pending. Changes in the regulatory environment may affect protocol availability in certain jurisdictions.
9.5 Concentration and Liquidity Risk
During the early deployment phase, limited integration breadth may amplify the impact of individual strategy underperformance. The Engine's rebalancing mechanisms and the Safety Escrow mitigate but do not eliminate this risk.
10. Conclusion
The Dera Protocol introduces a permissionless, asset-agnostic yield infrastructure layer: an open system that converts static capital into yield-generating assets without requiring active management, custodial relationships, or liquidity lock-ups.
DERA is the first asset built on this infrastructure, demonstrating the model with a fully liquid, permissionless, yield-bearing stablecoin alternative backed by USDC and integrated with Ethereum's deepest DeFi yield sources. The exchange rate mechanism, the non-custodial architecture, and the permissionless redemption guarantee are not features built on top of a product. They are the product.
The Dera Engine's asset-agnostic architecture is built to expand beyond DERA into a broader class of yield-generating digital assets: stablecoins, CBDCs, tokenised equities and stocks, commodities, government bonds, and structured credit instruments. Each will inherit the same core properties: automatic yield generation, permissionless redemption, full liquidity, and transparent on-chain execution.
The infrastructure is live. DERA is deployed on Ethereum mainnet. The protocol is open.
Resources
| Resource | Location |
|---|---|
| Documentation | docs.derafi.io |
| Technical Documentation | docs.derafi.io/technical-documentation |
| Security and Audit Report | docs.derafi.io/technical-documentation/security |
| Token Dynamics | docs.derafi.io/token-dynamics |
| Era Zero | docs.derafi.io/era-zero |
| Dune Dashboard | dune.com/dera_protocol/dashboard |
| Terms and Conditions | app.derafi.io/terms-of-use |
| Security Contact | security@derafi.io |
| GitHub | github.com/DeraFi |
| DERA Token Contract | 0xb1431da6d57646a166bb23e1f6fe92a134709d75 |
| USDC/DERA Pool on Uniswap V3 | 0x7b7644DDB24A3FB2dF9E9C787F1a029886f42ad4 |
Technical Appendix: Formal Protocol Specification
This appendix provides a formal specification of the Dera Protocol's core mechanics, derived from deployed contract behaviour. It is intended for developers, auditors, and institutional readers requiring precise definitions of state transitions, formula derivations, and edge case handling.
A.1 Notation and State Variables
| Symbol | Definition | Notes |
|---|---|---|
| S(t) | Total DERA supply at time t | ERC-20 totalSupply |
| TVL(t) | Total Value Locked at time t | Denominated in USDC |
| R(t) | Exchange rate at time t | USDC redemption value of one DERA token |
| D_i | USDC principal deposited into connector i | netUnderlyingAssetDeposits |
| Y_i(t) | Accrued yield in connector i at time t | currentYield |
| a_i | Allocation weight for connector i | Sum of all a_i = 1; each a_i >= 0 |
| f | Withdrawal service fee rate | 0 <= f <= 0.001 |
| phi_i | Performance fee percentage for connector i | Fraction of yield retained as protocol revenue; currently set at 0.10 (10%) across active connectors |
| n | Number of active connectors | 3 |
A.2 TVL Computation
The protocol tracks TVL by querying each active connector and summing asset values via Chainlink oracle. Two yield accrual mechanisms are supported depending on the integrated protocol.
Value-appreciating LP tokens (e.g. Fluid fTokens): the LP token price increases over time.
Value_i(t) = LP_balance_i(t) x LP_price_i(t)
Rebasing LP tokens (e.g. Aave aTokens): the LP token quantity increases while price remains constant at 1.
Value_i(t) = LP_balance_i(t) x 1
In both cases, yield accrual is reflected passively without any action from participants. TVL across all connectors:
TVL(t) = sum of Value_i(t) for i = 1 to n
A.3 Exchange Rate
The exchange rate is derived directly from TVL and total supply, computed on-chain at the time of each mint or redemption call:
R(t) = TVL(t) / S(t)
No static or time-averaged rate is used. The exchange rate is increasing under positive yield conditions between fee collection events, and may step down at each fee collection or decline if TVL declines due to losses in underlying integrations.
Boundary condition. If S(t) = 0, no exchange rate is defined and no redemption is possible. Minting against an empty pool initialises R at 1:1 with the underlying asset.
A.4 Minting
When a participant deposits an amount A of USDC via depositTokenAndMintDera, the Engine executes the following sequence:
-
Validates that USDC is a whitelisted token and A exceeds the minimum deposit threshold
-
Computes the current exchange rate R(t)
-
Calculates the quantity of DERA to mint:
DERA_minted = A / R(t)
- Allocates A across active connectors proportionally to their allocation weights:
Allocated_i = A x a_i
- Calls
mint()onDERA, increasing S(t) by DERA_minted, and emits aDERAMintevent
Post-mint, the exchange rate is unchanged: TVL increases by A and supply increases by A / R(t), preserving R(t) exactly.
A.5 Redemption
When a participant redeems an amount B of DERA via burnDeraWithdrawFunds, the Engine executes the following sequence:
-
Computes the current exchange rate R(t)
-
Computes the gross USDC value:
Gross_USDC = B x R(t)
3. Deducts the withdrawal service fee:
Net_USDC = Gross_USDC x (1 - f)
4. Withdraws Net_USDC from active connectors proportionally to current allocation weights
5. Calls burn() on DERA, decreasing S(t) by B
6. Transfers Net_USDC to the participant's wallet and emits a DERABurn event
The fee portion (Gross_USDC x f) is transferred to the configured fee recipient address.
Edge case. If a connector cannot fulfil its proportional withdrawal obligation, the Engine reroutes through DeraSafetyEscrow. The participant receives the full Net_USDC entitlement. The Safety Escrow is controlled exclusively by the Engine contract and cannot be accessed by any external party.
A.6 Yield Accrual
Yield accrues passively within each connector as LP token values or balances increase. The protocol does not mint new DERA tokens to distribute yield. Instead, yield increases TVL(t) while S(t) remains constant, mechanically increasing R(t) for all holders simultaneously.
Accrued yield in connector i:
Y_i(t) = Value_i(t) - D_i
Performance fee withdrawable from each connector:
Performance_fee_i = Y_i(t) x phi_i
This is callable only by the Engine contract via withdrawPerformanceFee() and transferred to the configured fee recipient.
A.7 Allocation and Rebalancing
Each connector holds an allocation weight a_i set by the protocol administrator. Weights must satisfy:
sum of a_i = 1 (i = 1 to n)
a_i >= 0 for all i
When funds are deposited, they are distributed according to current weights. When rebalancing is triggered, the Engine calls reallocateFunds(), withdrawing from over-weight connectors and depositing into under-weight connectors. All reallocation events emit FundsReallocated logs on-chain.
A.8 Access Control State Machine
| Role | Contract | Permissions |
|---|---|---|
ENGINE_ROLE | DERA | Mint and burn DERA tokens |
ADMIN_ROLE | DeraAdmin / DeraEngine | Pool management, fee configuration, connector pausing, token whitelisting, fund recovery |
FEE_MANAGER_ROLE | DeraAdmin | Initiate performance fee withdrawals to fee recipient |
DEFAULT_ADMIN_ROLE | DERA / DeraAdmin | Two-step transfer of admin roles, subject to time-buffer delay |
Role transfers require a two-step confirmation: beginDefaultAdminTransfer() followed by acceptDefaultAdminTransfer() from the receiving address. A transfer in progress may be cancelled via cancelDefaultAdminTransfer(). All role changes emit structured on-chain events.
A.9 Upgradeability Constraints
Immutable post-deployment:
- Core DERA token logic
- User DERA balances
USDC_TOKEN_ADDRESSDERA_SAFETY_ESCROW_ADDRESS
Adjustable through governance:
- Connector allocation weights
- Addition or removal of connectors
- Withdrawal service fee rate, bounded at f <= 0.001
- Whitelisted deposit tokens
- Fee recipient address
- Performance fee percentages and withdrawal intervals
Engine logic is replaceable via setNewEngine(), which transfers ENGINE_ROLE across all connectors, the DERA contract, and the Safety Escrow to a new engine address, enabling protocol upgrades while preserving all user balances and contract state.
© 2026 Dera Finance. All rights reserved. · docs.derafi.io