Security
Who controls the Access0x1 payment system on Base, Unichain, Arc and Ethereum, how money moves through it, and what we have run against it. The chain facts were read on 2026-10-23, and each one says how you can read it too.
Who controls it
- One shared wallet (a Safe) owns all 11 parts of the system on Base, Unichain, Arc and Ethereum. It is the same address on every network: 0xF025EC0bB828dbFD896c22142a323dD8606F9A91.
- It needs 2 approvals out of 3 owners for anything it does. No one person can act alone. On 2026-10-23 we asked the Safe on each of the 4 networks: the threshold was 2, the owner count was 3, and all 11 parts named the Safe as their owner. We do not list the owners’ addresses here.
- Each part is an upgradeable proxy. The address stays the same and the code behind it can be replaced, and only the owner can replace it. That owner is the Safe, so an upgrade needs the same 2 approvals.
- There is no timelock. Once the Safe approves an upgrade it takes effect in that transaction, with no waiting period.
- The code behind each proxy has its set-up step locked, so nobody can take ownership of that code directly. On Basescan, the owner of each implementation reads as the zero address.
| Network | Payment router | Safe |
|---|---|---|
| Base | Open on Basescan | Open on Basescan |
| Unichain | Open on Uniscan | Open on Uniscan |
| Arc | Open on the Arc explorer | Open on the Arc explorer |
| Ethereum | Open on Etherscan | Open on Etherscan |
To read it yourself, call getThreshold() and getOwners() on the Safe and owner() on the router with any Ethereum tool and a public RPC (on Base: https://mainnet.base.org). Every address is also on the mainnet page.
How the money moves
- One transaction. The router pulls the payment from the customer and pays it out in the same step: your share to you, our fee to our treasury, and any surcharge you set to your fee address.
- The split adds back up exactly. Fee plus what you receive equals the amount the customer paid, with nothing left over. The router holds no token balance afterwards. The only thing it can ever hold is a native-coin payout that could not be delivered, which is kept for its recipient to claim.
- Our default fee is 1% of a payment with a $0.30 minimum, as read from the router on 2026-10-23. The percentage part of any fee is capped at 10%, and the router never takes more than the amount paid.
- Non-custodial. A payment is pulled from the customer and paid out in the same transaction: the merchant’s share to the merchant, the fee to the treasury. The router holds no balance afterwards.
- Checks, effects, then interactions, with a reentrancy guard on every function that moves tokens. The merchant’s payout and fee destination are read before the token pull, so a hostile token cannot redirect them mid-payment.
- Prices come from Chainlink feeds read through a staleness check. An answer older than its window is rejected, and USDC/USD has its own longer window to match its 24 hour heartbeat.
- On Base the sequencer uptime feed is checked: pricing is refused while the sequencer is down or has just restarted.
- Refunds are never blocked. The owner’s pause switch halts new payments only; claiming a refund or a queued payout stays open while the router is paused.
The source is verified on the explorer for every part, so these points can be read in the code that is running.
How the code is tested
Our contracts repository is private, so the counts below are ours, not something you can re-run. We counted them by script on 2026-10-23. A count shows how much exists, not that everything passed or that nothing is missing.
- 2,185 test functions in 158 test files, counted on 2026-10-23.
- Invariant suites: 18 files with 97 invariant functions. The router’s own set checks conservation of native and token value, platform cut reaches the treasury, zero custody, merchant isolation, fee cap.
- Fuzz suites: 13 files, and 225 fuzz test functions across the test folder.
- Symbolic proofs (Halmos): 6 proofs in the repository. They cover the fee split conserving value and never creating it, the fee rule never charging more than the amount paid, and a session budget never being exceeded. Our dated report of 2026-10-19 records 4 of 4 proofs passing at that time.
- Mutation testing: a tool plants deliberate faults in the money code and checks that the tests notice. Our report of 2026-10-19 covers 5 money-moving contracts and 326 valid faults: the tests caught 308 at first (94.5%), and 321 (98.5%) after we added tests for the gaps it showed. The remaining 5 we judged to change nothing. A later report of 2026-10-20 on the fee-table code records 118 of 119 caught. This was a sample of faults, not every possible one.
- Static analysis: Slither and Aderyn run as part of our security command (
make audit), next to test coverage and a contract-size check. The commandsmake halmosandmake mutationrun the other two. Their results are lists we read through and triage, not a pass mark.
All of this is our own work. We make no claim that the contracts are free of bugs.
Report a problem
Write to hello@access0x1.com, or message us on Telegram. Please do not post the details publicly until we have answered. We do not offer rewards for reports.