Technical Documentation

This section covers the smart contract architecture, capital flow mechanics, access control model, and security implementation of the Dera Protocol. It is written for developers, auditors, and technical integrators.

For a conceptual overview of the protocol, see the Whitepaper. For participation details, see Era Zero.

Introduction

The Dera Protocol is a permissionless, non-custodial yield infrastructure layer deployed on Ethereum mainnet. This page provides a technical overview of the protocol's smart contract architecture for developers, auditors, and integrators. For a full conceptual and economic overview, see the Whitepaper.

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)

DERA.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. DERA tokens are minted only when a user converts a whitelisted stablecoin into DERA via the Engine, and burned only when a user redeems. This preserves the direct relationship between circulating supply and protocol TVL.

DERA integrates LayerZero's OFTv2 (Omnichain Fungible Token Version 2) standard, enabling native cross-chain transfers across supported EVM networks without wrapped tokens or custodial bridges. This omnichain functionality is built on LayerZero's Ultra Light Node (ULN) architecture.

Cross-chain message delivery is secured through a two-actor verification model:

• Oracle: Provides block headers from the source chain
• Relayer: Supplies Merkle proofs and transaction payloads

Both actors must independently verify a message before it is finalised on the destination chain via lzReceive(), ensuring exactly-once delivery, ordered message execution, and protection against replay attacks.

Role-Based Access Control

DERA implements a strict permission model via a custom DeraRoles abstract contract, built on OpenZeppelin's AccessControlDefaultAdminRules. This enforces the following:

• 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(address newAdmin)
  • acceptDefaultAdminTransfer() — must be called by the receiving address
  • cancelDefaultAdminTransfer() — available to abort a pending transfer

All role changes emit structured on-chain events for full traceability. No unilateral administrative action is possible.

Minting and Burning Logic

The DERA contract enforces a tightly bound mint/burn gateway governed exclusively by the DeraEngine contract.

Minting: When a user converts a whitelisted stablecoin, DeraEngine:

• Validates the asset and amount
• Allocates capital to DeFi connectors proportionally to current allocation weights
• Calls mint() on DERA to issue DERA tokens to the user

Burning: When a user redeems, DeraEngine:

• Calls burn() on DERA to destroy the corresponding token amount
• Recovers funds from underlying pools via connectors
• Returns the underlying stablecoin to the user

These functions are not publicly accessible and cannot be triggered by users directly. This preserves the integrity of the token supply and ensures a direct relationship between protocol TVL and circulating DERA supply.

Key Features

Feature	Description
Omnichain Transfers	Fully OFTv2-compliant, enabling native token movement across EVM chains via LayerZero
Mint/Burn Discipline	Issuance and redemption are tied directly to real asset flows, governed solely by DeraEngine
Secure Access Control	OpenZeppelin AccessControlDefaultAdminRules with two-step admin transfer and scoped roles
Direct TVL Backing	Every DERA token in circulation is backed by protocol-deployed TVL across active DeFi integrations
ERC-20 Compatibility	Fully compatible with wallets, exchanges, DeFi protocols, and indexers
Modular Separation	Token logic is isolated from DeFi pool logic and engine operations, simplifying audits and upgrades
Cross-Chain Safety	ULN architecture prevents token duplication, ordering issues, and centralisation risks

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 burnDerAndWithdrawFunds.

Key responsibilities:

• Conversions in: Validates the submitted stablecoin, calculates proportional allocations across active pools, routes capital to connectors, and mints DERA to the user
• Redemptions: Burns DERA tokens, withdraws proportional liquidity from connectors, and returns the underlying stablecoin to the user

Security is enforced with OpenZeppelin's ReentrancyGuard on all external user functions. Role-restricted modifiers ensure only authorised entities can access admin-level logic.

Immutable state variables (via DeraAdmin):

• DERA: 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

Dynamic state includes protocol pool addresses, allocation weights, and TVL tracking. All state changes emit on-chain logs for full auditability.

DeraAdmin

DeraAdmin.sol defines the administrative interface for configuring the protocol. It is inherited by DeraEngine.sol and provides control over:

• Service Fees: Configurable withdrawal fee, capped at 0.1%
• Pool Management: Adding and removing pools, setting and updating allocation weights, triggering reallocation
• Fee Manager Role: Granting and revoking fee withdrawal permissions
• Performance Fees: Configuration and withdrawal initiation
• Fund Recovery: Retrieves tokens mistakenly transferred directly to Engine or connector contracts, including airdropped or spam tokens. Gated by ADMIN_ROLE and logged on-chain

All functions are restricted to ADMIN_ROLE. Key state changes emit events (ProtocolPoolAdded, FundsReallocated, etc.) for full traceability.

Protocol Connector Contracts

Protocol Connectors enable the Engine to interact with external DeFi protocols. Each connector implements the IDefiProtocolConnector interface and abstracts the integration logic for a specific protocol.

Each connector 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

Performance fee handling:

• Each connector defines a performanceFeePercentage variable representing the portion of yield available as protocol revenue
• withdrawPerformanceFee() is callable only by DeraEngine and transfers accrued fees to the configured fee recipient

Pausability

Each connector inherits OpenZeppelin's Pausable contract. Individual connectors can be paused without halting the broader system, enabling the protocol to:

• Suspend interactions with a specific pool during an exploit or anomalous yield behaviour in the connected protocol
• Perform scheduled maintenance or parameter updates in isolation

Connector pausing is access-controlled and emits Paused and Unpaused events. Withdrawals from the broader system are never pausable regardless of individual connector status.

Safety Escrow

DeraSafetyEscrow is a dedicated fallback contract ensuring continuous fund accessibility if a primary connector becomes unresponsive or fails.

• Emergency Withdrawals: If a connector cannot return funds, the Engine reroutes withdrawal operations through the Safety Escrow
• Controlled Access: Callable exclusively by DeraEngine
• Operational Continuity: Maintains MiCA-aligned system availability under stress conditions or third-party protocol failure

Contract Flow

This section covers how the Dera Protocol calculates token value, manages capital flows, and allocates yield through its on-chain smart contract system.

The system consists of DeraEngine, DERA, and a modular set of DeFi protocol connectors. These components work together to handle conversions, allocate capital, mint yield-bearing tokens, and process redemptions while tracking TVL and exchange rate on-chain.

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 = TVL / Total DERA Supply

Where:

• 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. A configurable withdrawal fee, initially set at 0% and capped at 0.1%, may be applied at redemption. All fee parameters are governed via DeraAdmin and are publicly verifiable on-chain.

Yield Accrual

The Dera Engine supports two LP token yield mechanisms depending on the integrated protocol:

Value-appreciating LP tokens (e.g. Fluid fTokens): the LP token itself increases in price over time.

Value_i(t) = LP_balance_i(t) x LP_price_i(t)

Rebasing LP tokens (e.g. Aave aTokens): the quantity of LP tokens held increases while price remains constant.

Value_i(t) = LP_balance_i(t) x 1

In both cases, yield accrual is reflected passively without any action from participants. As yield accrues, TVL increases while token supply remains unchanged between mints and redemptions, and the exchange rate adjusts upward for all holders simultaneously.

Capital Flow

User Wallet
  |
  | Convert whitelisted stablecoin (USDC)
  v
DeraEngine Contract
  |
  | Validate input, calculate allocation weights
  | Route capital to connectors proportionally
  v
Protocol Connectors (Aave, Fluid, Compound)
  |
  | Deploy capital into external DeFi protocol
  | Accrue yield via LP token appreciation or rebase
  v
TVL increases => Exchange Rate adjusts upward
  |
  | On redemption: burn DERA, withdraw proportional USDC
  | (Safety Escrow as fallback if connector unavailable)
  v
User Wallet

Minting

When a user calls depositTokenAndMintDera:

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 current weights
5. mint() called on DERA; DERAMint event emitted

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

Redemption

When a user calls burnDeraAndWithdrawFunds:

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

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

TVL Tracking

The Dera Protocol does not take custody of user assets. TVL represents capital routed into third-party protocols via connectors, not assets held by Dera. TVL is computed by querying each active connector and summing asset values via Chainlink price feeds.

Allocation Management

Pool allocation weights are set by the protocol administrator via DeraAdmin. All weights must sum to 100%. The Engine exposes the following allocation functions:

• addProtocolPool: Adds a new connector pool with zero initial allocation
• removePool: Withdraws capital and removes the pool
• setProtocolPoolAllocation: Assigns percentage weights across active pools
• Reallocation is achieved by updating weights and triggering proportional withdraw/deposit cycles

All allocation operations emit on-chain events and are restricted to ADMIN_ROLE.

User Flow

This section describes the end-to-end interaction flow for a participant converting into and out of DERA via the Dera Protocol smart contracts.

Step-by-Step Flow

1. Token Validation and 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: Based on current pool weights set by the admin, the submitted capital is divided proportionally across active connectors
3. Connector Execution: Capital is routed to respective connector contracts, which deploy it into external DeFi protocols
4. DERA Minted: Once capital is deployed, the equivalent value in DERA tokens is minted at the prevailing exchange rate and transferred to the user
5. Passive Yield Accrual: Yield accrues continuously as LP token values increase or rebase in the underlying protocols. The DERA exchange rate reflects this appreciation over time without any action from the holder
6. Redemption: When the user calls burnDeraAndWithdrawFunds, DERA tokens are burned and the equivalent USDC value is returned by withdrawing from the same connector paths in reverse

All interactions are secured by reentrancy guards and emit detailed events for compliance tracking and on-chain auditability.

Active Pool Allocations

The following connectors are currently active. Allocation percentages are configurable by the protocol administrator and subject to governance. Current allocations are verifiable on the Dera Dune Dashboard.

Protocol	Mechanism	Connector Contracts
Aave V3	Rebasing (aEthUSDC)	0x57E6247B6467395e268c734a649f7FeE4723b100 (Proxy)
		0x56D457073dC8e5Ff6F17d89a622f5eB627BFA66c (Impl.)
Compound V3	Rebasing (cUSDCv3)	0x6ffC905d449F8667AE73F52753d769ad486F8b95 (Proxy)
		0x2357ee234B1123310a6Cdd5aa38Dcf3ab8886Cd9 (Impl.)
Fluid	Value-appreciating (fUSDC)	0xD79D5CeA1b02E3fF40171268E377f6714794643A (Proxy)
		0x444F01Fc495F9Ce6B75fA7b1e8a49f0A95bCDCA4 (Impl.)

The DERA token contract is deployed at 0xb1431da6d57646a166Bb23E1F6fE92a134709d75.

Security

This section covers the Dera Protocol's security architecture, external audit, access control model, and upgradeability constraints.

Safety Mechanisms

Multisig

All admin-level actions are protected via a 3-signer multisig using hardware wallets. Two of three signatures are required to execute a transaction. Roles include technical lead, compliance, external security advisor, and operations. No unilateral action by any single team member is possible under any circumstances.

Safety Escrow

The DeraSafetyEscrow contract acts as an emergency withdrawal route if a primary connector fails or becomes unresponsive. It bypasses standard connector logic to prioritise capital recovery and user fund accessibility. Controlled exclusively by DeraEngine. Full architecture detail is covered in Minting and Burning Logic.

Pausable Connectors

Individual connectors can be paused without affecting the broader protocol. Used during exploits, anomalous behaviour, or maintenance events in connected third-party protocols. Isolates risk at the pool level while the broader system and all user redemptions remain unaffected. Full detail in Contract Flow.

Access Control

The protocol implements layered access control using OpenZeppelin V5 primitives across two patterns:

Ownable2Step (DeraEngine)

Ownership transfer requires two explicit steps:

1. Current owner calls transferOwnership(address newOwner)
2. New owner calls acceptOwnership()

This prevents accidental or malicious privilege assignment.

AccessControlDefaultAdminRules (DERA and DeraAdmin)

Scoped role permissions including ENGINE_ROLE and ADMIN_ROLE. Admin transfer follows a two-step process with an optional cancellation path. All role changes emit structured on-chain events.

Only DeraEngine can mint or burn DERA tokens. No other address holds this permission under any circumstances.

Re-entrancy Protection

All external user functions implement OpenZeppelin's nonReentrant modifier, preventing double-spend and re-entrancy attacks.

External Audit

Core protocol smart contracts were independently audited by Hacken (commit hash 4b04fec66620b39bcb67ca0686af0a8a3ef60821). The audit covered security, code quality, and documentation, with 100% test coverage. Two findings were identified, one medium and one low severity, both resolved prior to mainnet deployment. The protocol has been extended significantly since the audit; all additions are listed under Post-Audit Additions below.

Post-Audit Additions

The following significant additions were made after the initial audit, all following the same security architecture as the audited core:

• DeraSafetyEscrow contract
• Aave, Compound, and Fluid protocol connectors (replacing Beefy)
• Pausable connector mechanism
• Role-based access control
• Chainlink oracle integration for TVL calculation
• Fund recovery mechanism
• OFTv2 cross-chain integration via LayerZero
• USDC adopted as the primary underlying asset (replacing USDT)
• setNewEngine() for engine logic upgrades

Upgradeability

Immutable Elements

• Core DERA token logic once deployed
• User DERA balances
• USDC_TOKEN_ADDRESS
• DERA_SAFETY_ESCROW_ADDRESS

Adjustable via Governance

• Pool allocation weights
• Pool additions and removals
• Withdrawal service fee, capped at 0.1%
• Whitelisted deposit tokens
• Fee recipient address
• Performance fee percentages and withdrawal intervals
• Protocol connector logic via UUPS proxy upgrade

Engine Migration

setNewEngine() transfers ENGINE_ROLE across all connectors, the DERA contract, and the Safety Escrow to a new engine address. This enables full engine logic upgrades while preserving all user balances and existing contract state.

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.