Developers

Technical Documentation

Smart contract architecture, capital flow mechanics, access control model, and security implementation of the Dera Protocol — written for developers, auditors, and technical integrators.

Introduction

The Dera Protocol is a permissionless, non-custodial yield infrastructure layer deployed on Ethereum mainnet. The architecture consists of four primary contracts: the DERA token contract, the Dera Engine, the Safety Escrow, and the Protocol Connectors. These components work together to handle capital routing, yield generation, token issuance, and redemption while maintaining full on-chain auditability.

Smart Contract Architecture

DERA Token Contract (ERC-20 + OFTv2)

DERA1.sol is the protocol's native yield-bearing token contract. It implements the standard ERC-20 interface with a strict mint/burn mechanism exclusively callable by the DeraEngine contract. Tokens are minted only when a user converts a whitelisted stablecoin via the Engine, and burned only on redemption — preserving the direct relationship between circulating supply and protocol TVL. The token is deployed at 0xb1431da6d57646a166bb23e1f6fe92a134709d75.

DERA integrates LayerZero's OFTv2 standard for native cross-chain transfers without wrapped tokens or custodial bridges, built on LayerZero's Ultra Light Node (ULN) architecture. Cross-chain delivery is secured by a two-actor model — an Oracle providing block headers and a Relayer supplying Merkle proofs — both of which must independently verify a message before it is finalised via lzReceive().

Role-Based Access Control

DERA implements a strict permission model via a custom DeraRoles abstract contract built on OpenZeppelin's AccessControlDefaultAdminRules:

• ENGINE_ROLE: Held exclusively by the DeraEngine contract — the only role authorised to mint and burn DERA tokens.
• DEFAULT_ADMIN_ROLE: Transferable only via a mandatory two-step process — beginDefaultAdminTransfer(newAdmin), then acceptDefaultAdminTransfer() from the receiving address, with cancelDefaultAdminTransfer() available to abort.

Minting and Burning Logic

Minting. When a user converts a whitelisted stablecoin, DeraEngine validates the asset and amount, allocates capital to connectors proportionally to current weights, and calls mint() on DERA1.

Burning. On redemption, DeraEngine calls burn() on DERA1, recovers funds from underlying pools via connectors, and returns the underlying stablecoin. These functions are not publicly accessible and cannot be triggered by users directly.

Key Features

Dera Engine

DeraEngine.sol is the central contract through which users interact with the protocol. It inherits from DeraAdmin and exposes two user-facing functions: depositTokenAndMintDera and burnDeraWithdrawFunds. Security is enforced with OpenZeppelin's ReentrancyGuard on all external user functions. The current live engine is deployed at 0x275a898967b4f430f813582ad743cc285ea8b014.

Immutable state variables (via DeraAdmin):

• DERA1 — immutable address of the DERA token contract
• USDC_TOKEN_ADDRESS — immutable address of the accepted stablecoin
• DERA_SAFETY_ESCROW_ADDRESS — immutable address of the Safety Escrow contract

DeraAdmin

DeraAdmin.sol defines the administrative interface, inherited by DeraEngine.sol, providing control over service fees (capped at 1%), pool management, the fee-manager role, performance fees, and fund recovery. All functions are restricted to ADMIN_ROLE and emit events (ProtocolPoolAdded, FundsReallocated, etc.) for full traceability.

Protocol Connector Contracts

Protocol Connectors enable the Engine to interact with external DeFi protocols. Each implements the IDefiProtocolConnector interface and tracks two core state variables inherited from BaseDefiProtocolConnector:

• netUnderlyingAssetDeposits — total principal deposited into the underlying pool
• currentYield — continuously updated to reflect accrued interest based on pool token share value or rebase mechanism

Each connector defines a performanceFeePercentage (currently 10% across all active connectors), applied before yield accrues into the exchange rate. withdrawPerformanceFee() is callable only by DeraEngine. Each connector inherits OpenZeppelin's Pausable; individual connectors can be paused without halting the broader system, and withdrawals are never pausable regardless of connector status.

Safety Escrow

DeraSafetyEscrow is a dedicated fallback contract ensuring continuous fund accessibility if a primary connector becomes unresponsive. It is callable exclusively by DeraEngine and maintains MiCA-aligned system availability under stress conditions.

Contract Flow

Exchange Rate

The exchange rate of DERA is derived from the aggregate value of all assets deployed across active connectors, divided by total token supply:

Exchange Rate = Total Value Locked (TVL) / Total DERA Supply

• TVL = sum of all connector asset values, queried via Chainlink price feeds
• Total DERA Supply = ERC-20 total supply as tracked on-chain

The exchange rate is computed on-chain at the time of each mint or redemption call. No spread mechanism is implemented. The live value is readable on-chain via the Engine's getExchangeValue() and is surfaced on the Dera homepage.

Yield Accrual

The Engine supports two LP token yield mechanisms:

• Value-appreciating LP tokens (e.g. Fluid fTokens): Value_i(t) = LP_balance_i(t) × LP_price_i(t)
• Rebasing LP tokens (e.g. Aave aTokens): Value_i(t) = LP_balance_i(t) × 1

In both cases, yield accrual is reflected passively. As TVL increases while supply remains constant, the exchange rate adjusts upward for all holders simultaneously.

Capital Flow

Participant Wallet ──▶ Dera Engine
   (convert USDC at prevailing exchange rate)
        │  validate input, calculate allocation weights
        ▼
   Distribute capital
   ├─ α₁ ─▶ Connector: Aave      (rebasing aTokens)
   ├─ α₂ ─▶ Connector: Fluid     (value-appreciating fTokens)
   └─ α₃ ─▶ Connector: Compound  (cTokens)
                    │
                    ▼
         External DeFi Protocols
                    │ yield accrues passively
                    ▼
   TVL increases ⇒ Exchange Rate = TVL / Total DERA Supply
                    │ DERA minted at prevailing rate
                    ▼
   Redemption: burn DERA ─▶ withdraw proportional USDC ─▶ Participant
   (Safety Escrow fallback if a connector is unavailable)

Minting

1. Engine validates that USDC is whitelisted and the amount exceeds the minimum threshold.
2. Engine computes the current exchange rate.
3. DERA minted = deposit amount / exchange rate.
4. Capital allocated across connectors proportionally to weights.
5. mint() called on DERA1; DERAMint event emitted.

Post-mint, the exchange rate is unchanged: TVL and supply increase proportionally.

Redemption

1. Engine computes the current exchange rate.
2. Gross USDC = DERA amount × exchange rate.
3. Net USDC = Gross USDC × (1 − fee).
4. Funds withdrawn from connectors proportionally.
5. burn() called on DERA1; supply decreases.
6. Net USDC transferred to user; DERABurn event emitted.

If a connector cannot fulfil its withdrawal obligation, the Engine reroutes through DeraSafetyEscrow and the user receives their full entitlement.

TVL Tracking & Allocation Management

The Dera Protocol does not take custody of user assets — TVL represents capital routed into third-party protocols via connectors. Pool allocation weights are set by the administrator via DeraAdmin and must sum to 100%. The Engine exposes addProtocolPool, removePool, and setProtocolPoolAllocation; reallocation updates weights and triggers proportional withdraw/deposit cycles. All operations emit on-chain events and are restricted to ADMIN_ROLE.

Active Pool Allocations

The following connectors are currently active. Allocation percentages are configurable by the protocol administrator and subject to governance; current live allocations are verifiable on the Dera Dune dashboard.

Allocations are configurable by governance and change over time; the values above reflect the current on-chain state. The Safety Escrow is deployed at 0x6b5e…af15.

User Flow

1. Token Validation & Engine Approval: the Engine verifies the submitted token is whitelisted and that the user has approved the Engine to move their tokens.
2. Allocation Calculation: capital is divided proportionally across active connectors based on current weights.
3. Connector Execution: capital is routed to connector contracts, which deploy it into external DeFi protocols.
4. DERA Minted: the equivalent value in DERA is minted at the prevailing exchange rate and transferred to the user.
5. Passive Yield Accrual: yield accrues as LP token values increase or rebase; the exchange rate reflects this over time.
6. Redemption: burnDeraWithdrawFunds burns DERA and returns USDC by withdrawing from the same connector paths in reverse.

Resources