Security & Audits
The 1delta composer contracts are audited by external security firms and the production deployments are immutable. This page lists the audits, what each one covered, and what remains a residual risk for integrators.
Audits
| Auditor | Scope | Date | Report |
|---|---|---|---|
| Certora | Compound V2 / V3 integration and shared composer surface | December 2025 | Final report (PDF) |
Certora — Compound integration, December 2025
A manual code review of the 1delta Compound integration, carried out between
December 10 and December 17, 2025 and prepared for the 1delta DAO and
Compound. The review targeted commit bea581f of
1delta-DAO/contracts-delegation.
What it covers
The audit is Compound-focused, but the scope reaches beyond the Compound adapters into the shared composer machinery every operation passes through:
| Contract | Role |
|---|---|
composer/BaseComposer.sol | Entry point and operation dispatch loop — see Entry Point |
composer/lending/CompoundV3Lending.sol | Compound V3 deposit / withdraw / borrow / repay |
composer/lending/CompoundV2Lending.sol | Compound V2-style (Venus) lending |
composer/lending/UniversalLending.sol | Lender-ID router that dispatches to every lending adapter |
composer/swappers/BaseSwapper.sol | Swap path and split decoding shared by all routes |
shared/permit/PermitUtils.sol | Permit / Permit2 handling |
composer/chains/ethereum/flashSwap/callbacks/BalancerV3Callback.sol | Balancer V3 flash-loan callback on Ethereum |
Not covered: the bridging adapters, the non-Compound lending adapters themselves (Aave, Morpho, Silo — beyond the shared router), and the chain-specific callback contracts other than Balancer V3 on Ethereum.
Findings
Ten findings, none critical or high severity.
| Severity | Discovered | Confirmed | Fixed |
|---|---|---|---|
| Critical | 0 | – | – |
| High | 0 | – | – |
| Medium | 2 | 2 | 1 |
| Low | 2 | 2 | 1 |
| Informational | 5 | 5 | 4 |
| Total | 10 | 10 | 6 |
| ID | Title | Severity | Status |
|---|---|---|---|
| M-01 | Permit operations vulnerable to frontrunning griefing attack | Medium | Fixed |
| M-02 | External protocol upgrade could drain approvals | Medium | Acknowledged |
| L-01 | Ignores vToken boolean return; uses unsafe transfers | Low | Fixed |
| L-02 | Oversized splits not rejected | Low | Fixed |
| I-01 | Missing lender ID validation in UniversalLending router | Informational | Fixed |
| I-02 | Amount masking inconsistency in withdraw function | Informational | Fixed |
| I-03 | Uses garbage when staticcall fails | Informational | Acknowledged |
| I-04 | CompoundV2Lending is Venus-only due to borrowBehalf | Informational | Fixed |
| I-05 | Misleading comment in assembly operation parsing | Informational | Fixed |
Two findings are acknowledged rather than fixed: M-02 and I-03. Read the PDF for the full description, recommendation and response on each.
(The report's own summary table tallies one fewer Low as fixed than its detailed findings section, which marks both L-01 and L-02 fixed. The per-finding statuses above are the ones taken from the detailed section.)
What integrators should take from it
Approvals are the shared attack surface (M-02, acknowledged). The composer calls into external lending protocols and DEXes. If one of those protocols' governance were compromised and its contracts upgraded, it could call back into the composer and spend approvals that users left standing. There is limited on-chain mitigation for this — the security of the whole is the intersection of every integrated protocol's governance security. The practical defence is to avoid persistent, unbounded approvals: prefer Permit2 with short deadlines, or approve per transaction.
Permit failures no longer brick a composition (M-01, fixed). Permit calls
are wrapped so that a frontrun permit — an MEV bot replaying the signature from
the mempool to burn the nonce — does not revert the whole deltaCompose() call.
If the allowance is genuinely missing the later operation still reverts, as it
must.
CompoundV2Lending is Venus-flavoured (I-04). It uses borrowBehalf,
mintBehalf and redeemBehalf, which exist on Venus vTokens but not on vanilla
Compound V2 cTokens. The contract keeps its name; the Venus-specific parts are
confined to those three sub-functions and are marked in the source.
Immutable deployments
The composer contracts are immutable. Each deployment is a transparent proxy
whose upgrade admin has been renounced — the ProxyAdmin owner is set to
address(0) — so the logic behind a composer address can never be upgraded,
paused or replaced. The audited code is the code that runs, and it stays that
way.
This also means there is no admin key to compromise and no upgrade path to front-run, at the cost of no ability to patch: a new deployment at a new address is the only way to ship a change.
Freezing happens at the end of a chain's rollout, not at deployment. A composer is first deployed upgradeable, iterated during the initial rollout, then frozen by renouncing the admin. A recently added chain may still be upgradeable until that happens. The Contract Addresses page lists the frozen deployments.
The Call Forwarder is likewise a fixed deployment at the same address on every chain. It holds no funds and no approvals between transactions — it exists so that arbitrary external calls never execute in the composer's own context, where they could reach user approvals or Permit2.
Reporting a vulnerability
Report suspected vulnerabilities privately to the team rather than opening a public issue on github.com/1delta-DAO.