Security & Transparency

Last Updated: September 2026

Audit status

0xKeep has not been audited by a third-party security firm. We would rather tell you that up front than let you assume otherwise.

What we have done instead is below: the contract is small, has no admin functions, is verified on-chain, and is covered by an open test suite you can run yourself. Read it, run it, and decide.

What the contract cannot do

  • No owner, no admin role, no pause switch. The contract inherits only OpenZeppelin's ReentrancyGuard.
  • Not upgradeable. No proxy, no delegatecall, no selfdestruct.
  • Fees and the fee receiver are set once in the constructor and stored as immutable. Nobody can raise them later.
  • Only the lock owner can withdraw, and only after the unlock time. Vesting claims follow the on-chain schedule and nothing else.

Contract addresses

Same source code (V12) on every chain; only the fee values differ. Each link opens the verified source on Sourcify.

Base · 8453 · 0 ETH fees (used by the app)

0x048d1326B3b0531A5d043984F4e495285B07af4B

Arbitrum One · 42161 · 0.03 / 0.02 ETH

0xDC9bFb15C28486590Cbf58F3FEA9ADbEB9B0334c

Optimism · 10 · 0.03 / 0.02 ETH

0x1Ecf87D69c4a5c8D10ffb7D73e8ABB415043f866

Also on Base, not used by the app

0x49bF4Ded143402B2fD89d8d284e477Dfdc9fa02B (original 0.03 ETH deployment)
0x6D729a7bda1E9Da1c8e74351fd8C242316381Efd (identical 0 ETH copy, deployed twice by mistake)

Fee receiver (all chains)

0x28B8cafb1c95E375E349283D63919039eB17c229

Before you lock anything, check that the address your wallet is about to call matches one of these. Every lock and vesting certificate in the app also links back to its contract.

What we tested

91 automated tests in Hardhat, all public in the contract repository. Clone it and run npx hardhat test.

  • Lock and vesting flows: create, extend, transfer ownership, withdraw, claim.
  • Input limits: past dates, 100-year cap, 1-day minimum vesting, uint96 amount and uint32 time boundaries.
  • Vesting math: cliff edges, rounding dust, and full payout at the end of the schedule.
  • Reentrancy through an ERC777-style token callback.
  • Fee-on-transfer tokens: the lock records the amount actually received, so the vault stays solvent.
  • Non-standard ERC20s: tokens with 0 decimals, tokens whose decimals() reverts, tokens that return no boolean.
  • Fee handling: exact fee, overpayment refund, and a refund that fails.
  • Multi-user isolation: one user can never touch another user's lock.

We also ran an internal security review of V12. It found no critical, high, medium, or low severity issues and two informational notes. An internal review is not an independent audit, and we do not present it as one.

Known limitations

  • Rebasing tokens. If a token's balance shrinks inside the contract after you lock it (a negative rebase), the withdrawal for that lock will fail. Don't lock rebasing tokens.
  • Fee receiver. New locks send their fee to a fixed address. If that address ever refused ETH, new locks would fail. Existing locks and withdrawals do not depend on it. The receiver is a plain wallet, which always accepts ETH.
  • Immutability cuts both ways. No one can change the rules on you, and no one can patch the contract either. If a bug were found, the fix would be a new deployment, not an update.

Found something?

Message @0xkeep_official on X or open an issue on the GitHub repository. For anything that could put funds at risk, please use a private DM first.