Sample report
Access control due diligence report
Who can touch the system: every address and account with power, what it can do, and the one row that matters most.
Download the original PDFIn short
- Five on-chain roles and four off-chain accounts, with what each can and cannot do.
- No role, including Owner, can transfer user balances directly. Everything else is a question of degree; that one is categorical.
- Four hygiene checks passed, two remain open and are published as open.
This is an illustrative deliverable, not a record of a real engagement. The subject, the Lumenswap Protocol, is fictional, and every address, email and name below is an invented example.
On-chain identity register
Every address with power, what kind of key it is, and the role it holds. A retired deployer is listed too, because a key that used to have power is a question until someone shows it does not.
| Holder | Address | Type | Role |
|---|---|---|---|
| Founders' safe | 0x3F5c...9A21 | 3-of-5 Safe multisig | Owner |
| Ops safe | 0x81dD...4C07 | 2-of-3 Safe multisig | Pauser, Oracle admin |
| Timelock | 0xA940...E63B | Contract, 48h delay | Executor of Owner actions |
| Governance | 0x5B12...77F0 | Token voting + timelock | Fee manager |
| Deployer (retired) | 0xC7e8...0D55 | EOA, powers renounced | None since launch |
What each role can perform
Capabilities against roles, so the question stops being who is trusted and becomes what each one could do on their worst day.
| Capability | Owner | Pauser | Fee mgr | Oracle adm |
|---|---|---|---|---|
| Upgrade contracts (via 48h timelock) | Yes | — | — | — |
| Pause swaps | Yes | Yes | — | — |
| Halt withdrawals (max 72h on-chain cap) | Yes | Yes | — | — |
| Change fee split (via 48h timelock) | — | — | Yes | — |
| Rotate price feeds (24h timelock) | — | — | — | Yes |
| Move user funds directly | — | — | — | — |
The last row is the most important line in this report
No role, including Owner, can transfer user balances directly.
Everything above it is a question of degree: how long a pause can last, how much notice an upgrade gives, who has to agree. That row is categorical, and it is the one a depositor would ask about first if they knew to ask.
Off-chain access register
Chain permissions are only half the picture. An attacker who cannot move funds on-chain may still be able to pause the product, push a price, or propose an upgrade from a laptop.
| Account | System | Can perform | MFA |
|---|---|---|---|
| ops@lumenswap.example | Admin dashboard | View metrics, trigger pause via Ops safe | Hardware key |
| oracle-bot@lumenswap.example | Feed publisher API | Push prices within deviation bounds | API key, rotated monthly |
| dev-team@lumenswap.example | CI and deploy repo | Propose upgrades; cannot execute | Hardware key |
| support@lumenswap.example | Helpdesk | Read tickets only; no chain access | TOTP |
Hygiene checklist
Four passed, two left open. The open ones are published here rather than held back — an item nobody is told about is an item nobody chases.
| Check | Status |
|---|---|
| Every privileged role behind a multisig | Pass (fixed during engagement) |
| Upgrades cannot bypass the timelock | Pass (proxy admin moved to timelock) |
| Withdrawal halt is time-bounded on-chain | Pass (72h cap added) |
| Deployer key powers renounced | Pass |
| Signer list published and current | Open, publish with launch |
| Quarterly key-loss rehearsal scheduled | Open |
Questions
Why does a retired key still appear?
Because renouncing power is a claim until it is checked. Listing the address and stating that its powers are renounced is what lets a reader verify it rather than take it on trust.
Is a 48-hour timelock enough?
It is enough to be noticed, which is the point of one. A timelock does not stop a hostile change; it gives everyone watching time to react before it lands, and that only works if someone is watching.
Who commissions this?
Usually an investor or a partner, before capital or an integration moves. The report answers what the other side can still do after the deal, which is a different question from whether their code is sound.
The work behind this
Investor due diligence
Independent technical and regulatory review of a product before your capital moves.
Wallet and custody audit
Multisig, smart accounts, key management and the signing path, reviewed end to end.
Partnership and integration analysis
What their contracts can do to yours, assessed before the integration ships.
Related reading
Guide
Access control and upgrade paths
Where the largest single losses sit, and the class least likely to be a bug. Most of it is the system working as designed, for the wrong person.
Guide
Web3 penetration testing
The contract is the most reviewed part of a crypto product and the smallest part of its attack surface. What a penetration test covers, and why the paths it finds rarely touch the chain.
Sample report
Business logic audit report
Does the product do what the pitch says? Three gaps between the documented model and the code, and what each one costs.