Skip to main content

Security and Conclusion

Safety/security:​

Dera's core smart contracts are built for non-custodial fund control, upgradability, and formal access limitation. Security mechanisms are layered for redundancy and regulatory resilience.

Safety mechanisms​

Multisig (how many signers, hardware wallets, etc)​

  • All admin-level actions are protected via multisig.

  • Suggested config: 3-of-5 signers using hardware wallets.

  • Roles include technical lead, compliance, external security advisor, and ops head.

Dera Safety Escrow (only very briefly, as already covered in architecture)**​

  • Acts as an emergency withdrawal route if a primary connector fails or becomes unresponsive.

  • Bypasses standard logic to prioritize capital recovery and user fund safety.

  • Controlled exclusively by the DeraEngine contract to maintain security boundaries.

  • Ensures compliance with MiCA operational continuity requirements.

  • Already covered in detail under Smart Contract Architecture.

Pausable connectors (only very briefly as already covered in fund management)​

  • Enables the admin to pause specific connectors without affecting the entire protocol.

  • Used during DeFi exploits, anomalous behavior, or maintenance events.

  • Helps isolate risk to individual pools, maintaining the overall system's stability.

  • Reinforces modular security and operational resilience.

  • Functional behavior was previously explained under fund management.

Access Control (Who Can Do What)​

Dera's smart contracts implement strict, modular access control using OpenZeppelin V5 primitives, specifically:

  • Ownable2Step for DeraEngine

  • AccessControlDefaultAdminRules for DERA1 and DeraAdmin

These patterns enforce granular role assignments and secure administrative handoffs.

            🔐 Ownable2Step (DeraEngine)

DeraEngine uses OpenZeppelin's Ownable2Step, a hardened ownership transfer mechanism that avoids accidental or malicious privilege loss. Ownership transfer occurs in two steps:

1. The current owner calls `transferOwnership(address newOwner)

`

2. The newOwner must explicitly call `acceptOwnership()

`

This ensures that:

  • Ownership is never unintentionally assigned to an invalid or non-responsive address

  • Transfer of authority is always intentional and verifiable

  • MiCA compliance is reinforced by auditable, traceable admin actions

#### 🛡️ AccessControl (DERA and DeraAdmin)

  • DERA1 and DeraAdmin implement AccessControlDefaultAdminRules, which allow:

    * Scoped role permissions (e.g., ENGINE_ROLE, ADMIN_ROLE)

    * A secure single-admin model for DEFAULT_ADMIN_ROLE

    * A two-step admin transfer process similar to Ownable2Step (beginDefaultAdminTransfer() → acceptDefaultAdminTransfer())

Only designated roles can alter contract state or invoke sensitive functions. All role changes and administrative actions emit structured events, providing on-chain traceability and supporting MiCA-aligned operational security.

OpenZeppelin re-entrancy guard​

  • All external user functions (deposit, withdraw) implement nonReentrant modifier to prevent double-spending attacks.

External audit​

What is being audited and by who (with hashes)​

            In May 2024, Dera's core smart contracts as well as protocol connector contracts were audited by Hacken (commit hash 4b04fec66620b39bcb67ca0686af0a8a3ef60821). The results of the audit included two findings, one medium and one low severity. Both findings have since been resolved. The audit summary security, code quality and documentation quality scores of 10/10, with 100% test coverage.

A link to the audit can be found at: https://drive.google.com/drive/u/1/home?ths=true

What has been updated since the audit​

            There have been numerous performance and security improvements to all smart contracts since the Hacken audit, including most notably the addition of the DeraSafetyEscrow contract, which acts as a safety mechanism to store users' funds in the event of an emergency.

            Another significant addition is the inclusion of three new protocol connectors, namely Aave, Compound and Fluid. These protocols replaced Beefy due to issues faced with Beefy's API when integrating with Dera. All three of the protocols that Dera currently integrates with are established, trustworthy sources, which reinforces security and the safety of users' funds.

            Other major changes include the addition of a pausing mechanism to the connectors, which allows Dera to temporarily pause deposits on a connector-by-connector basis in the unlikely event of a protocol being compromised. Withdrawals are not pausable, meaning that users can always withdraw their funds should this happen.

            Role-based access control has also been added since the audit, which prevents unauthorized accounts from performing certain admin tasks, including the addition/removal of pools, reallocation of funds, fee percentage and withdrawal interval times, and more. A recovery mechanism has been put in place to rescue funds that may be mistakenly transferred to the DeraEngine or protocol connector contracts. The use of a Chainlink oracle to calculate token values in USD provides a reliable source to track the TVL.

            In terms of continuous development, the protocol connectors are upgradeable should any bugs need fixing or so that new features can be added. Additionally, the setNewEngine() function allows for the transfer of ownership of all connectors, the DERA token and safety escrow contract to a new engine, which also makes it possible to update engine logic.

            The DERA token contract has also been outfitted with role-based access control since the audit, which permits only the engine contract the ability to mint/tokens on deposit/withdrawal. No other account (EOA or contract) has the ability to do this, and these functions are only ever called when a deposit/withdrawal is made by a user via DeraEngine, meaning that only active Dera users have control over the total supply. DERA now also inherits the OFT contract and its associated features.

            The replacement of USDT (Tether USD) with USDC since the audit is another important update, which was primarily a legal decision for regulatory compliance. Despite the difference in gross market cap between the two stablecoins, USDC is still supported by most deFi protocols and is widely considered one of the more reliable and potentially profitable currencies.

            All of these updates to core and connector contracts have addressed potential issues raised in the audit, and have added an extra layer of security to safeguard against other undiscovered attack vectors.

            Dera's initial contracts deployed to mainnet, which contain all of these features, can be found in the codebase on the branch: https://github.com/Digital-Era-Foundation/smart-contracts/tree/fix/rename-dera-token-contract

Replacability/upgradability (what we as a company can adjust in the smart contracts):​

Dera follows OpenZeppelin upgradeability standards and proxy patterns (UUPS-compatible).

What we can not adjust​

#### Immutable Elements

  • Core token logic (DERA1) once deployed

  • User balances and past mints

What can we adjust and why​

#### Adjustable Elements

  • Pool allocation percentages

  • Pool additions/removals

  • Withdrawal service fee (capped at 1%)

  • Whitelisted tokens

Overall overview of upgradability standards/pattern (open zeppelin), role transfer, etc​

#### Upgradable Patterns

  • Upgrade protocol connectors proxy contracts (UUPS)

  • Protocol connector and DERA1 ENGINE_ROLE roles can be transferred with transferEngineRole when deploying a new engine

"Unusual changes": Whitelisting tokens, changes in contract logic,​

"Unusual Changes" (Exceptional Governance Events)​

  • Whitelisting new collateral tokens

  • Deploying a new Dera Engine and transferring protocol connectors' role admin (essentially upgrading the engine)

  • Protocol connector pausing

  • Performance fee withdrawal interval

  • Assigning a new fee recipient

  • Assigning/removing fee managers (accounts that can trigger fee withdrawals to the fee recipient)

All changes are gated by multi-sig and time-delayed governance to comply with MiCA Article 30 (Operational resilience).

Conclusion​

Dera Protocol represents a modular, compliant, and developer-friendly leap forward in how yield-generating  digital assets are managed on-chain. It combines the capital efficiency of automated DeFi strategies with the safety of strict access controls, LayerZero-powered omnichain functionality, and MiCA-aligned transparency mechanisms.

From the underlying architecture---built on OpenZeppelin V5 and OFTv2---to the integration of Chainlink oracles, reentrancy protection, and pausable connectors, every component is designed to ensure that user funds remain non-custodial, verifiable, and securely allocated across trusted third-party pools like Aave and Fluid. Token issuance and redemption follow a strict mint/burn model governed by engine-level controls, and administrative operations are hardened through multi-sig, time-delayed upgrades, and two-step ownership/role transfers.

For developers, the system is fully modular, upgradable, and extensible. For users, it provides seamless yield generation and cross-chain liquidity with full traceability. And for regulators, it reflects the best practices in smart contract governance, fund segregation, and auditability---meeting MiCA's standards head-on.

Ready to explore, integrate, or contribute?

Dive into the Dera GitBook or reach out to the team for a technical deep dive, audit report access, or partnership opportunities.***

Build yield-bearing infrastructure that's transparent, compliant, and future-ready---with Dera.