How the contracts are reviewed
No external audit yet
This page describes the security review that runs on every change to the smart contracts, and it is deliberate about what it does not claim: no external firm has audited these contracts. What follows is the internal discipline, published so that a Partner evaluating this platform can judge the method instead of taking a word for it. An external audit is a production gate and it has not happened.
The industry method, and which part of it this is
An audit engagement is six steps: the scope is pinned to one commit, an automated pass runs static analysis and the test suite, security researchers read the code against the specification, findings are reported by severity, the protocol team fixes, and the same team verifies the fixes.
The local pipeline is steps two and three, run on every change rather than once per engagement. What it cannot be is step four onward — an independent party looking at the code with no stake in the answer.
Firms in this field come in two shapes, and both are relevant to a Partner asking who could audit this: firm-led engagements with named engineers signing a report (Cyfrin, OpenZeppelin, Trail of Bits, ChainSecurity, Certora), and researcher networks that assemble a team per codebase or open the code to a competition (Sherlock, Spearbit, Code4rena). For a platform built on account abstraction — ERC-4337 and EIP-7702 — the relevant specialisation is exactly that.
The checklist the review is read against
The tools are the fast half. The slow half is a person asking, of each contract, the questions
auditors have learned to ask, and for that this review uses Solodit's aggregated audit
checklist — 370 questions that Cyfrin built from published audit reports
and from thirteen auditors' own lists, and publishes at
solodit.cyfrin.io/checklist and in
Cyfrin/audit-checklist.
The checklist is theirs and stays theirs — this is a pointer to it and an account of how it is used here, not a copy of it. A copy of the file is vendored inside the contracts repository so a review never depends on a network call, and every question is read from the source above.
362 of the 370 apply to these contracts. What is out of scope is the Merkle-tree category, which needs a Merkle tree, and three cross-chain questions about messaging, bridged assets and zkSync Era.
| Category | Questions | What it is read against here |
|---|---|---|
| Basics | 135 | access control, initialization, arithmetic, events, upgradeability |
| Defi | 63 | the deployment's own swap counterparty: pricing, reserves, slippage |
| Integrations | 56 | ERC-4337 EntryPoint and paymaster conformance |
| Attacker's Mindset | 25 | denial of service, front-running, griefing |
| Token | 24 | every ERC-20 the transfer and swap modules move |
| Heuristics | 17 | the reading-order questions that apply to any codebase |
| External Call | 14 | the account's module delegatecall, and both modules |
| Multi-chain | 13 | the same contracts run on Arbitrum and on Base: opcodes, PUSH0, timestamps, decimals |
| Centralization Risk | 7 | root authority, operational validator, paymaster owner, pool owner |
| Low Level | 5 | the assembly in the proxy, the storage library and the ECDSA library |
| Signature | 5 | EIP-712 domains, ECDSA recovery, replay and nonces |
| Timelock | 1 | the root-recovery delay |
The tools
| Tool | What it looks for |
|---|---|
| Slither | 93 detectors across the call graph: reentrancy, access control, unchecked returns |
| Aderyn | Cyfrin's static analyser, reporting by severity class |
| Semgrep | pattern rules, mostly gas and shape |
| Foundry | unit, revert, boundary, fuzz and invariant tests, plus branch coverage |
Severity, and what a finding record contains
| Low likelihood | Medium likelihood | High likelihood | |
|---|---|---|---|
| High impact | Medium | High | Critical |
| Medium impact | Low | Medium | High |
| Low impact | Informational | Low | Medium |
The part worth stating plainly: a tool finding is not a finding until someone shows the path. A static analyser reports patterns, and a pattern can be the design working. So every run records a verdict of its own next to the tool's — confirmed, refuted with the reason it does not hold, or accepted with what makes it acceptable — and each run's raw tool output is kept next to that verdict, because a conclusion without the evidence it came from is a claim.
Two examples of what that separation is for, from the run of 2026-08-16. An analyser reported
ecrecover signature malleability: refuted, because the library rejects s above the half order,
rejects any v outside {27, 28}, rejects a wrong length and rejects the zero address. The same
run reported reentrancy in the swap pool: refuted, because the external calls are view and the
compiler emits STATICCALL, so a reentrant state change reverts inside the callee.
And the reverse — what the tools did not report and a person reading the checklist did. Three findings were confirmed that run and all three are fixed: a paymaster sponsorship cap that bounded one operation instead of the bundle it arrived in, a one-step ownership transfer on the same contract, and an implementation contract left uninitialized. The first was proved with a test against the real ERC-4337 EntryPoint before it was fixed, and that test now proves the bound.
What this review does not cover
An external audit; EIP-7702 authorization conformance against a live client; EntryPoint, bundler and paymaster conformance against a real bundler; a storage-layout diff across an upgrade; the signer integration; and verification of deployed bytecode against this source. Each of those is a production gate, and a Partner is entitled to ask for the evidence of each one before relying on this platform with real funds.