Skip to main content
Caplane’s security comes from one place: the binding makes the token itself reject a tampered order, so there is no coordinator to trust. This page states what you trust, the invariants that hold, the attack surface, and the audit posture, honestly.

​
The trust model

You trust the audited broker, the adapter you signed into your order, and the settlement token’s EIP-3009 implementation (TUSDC on testnet, real USDC in production). You need not trust the relayer; the binding bounds it. There is no coordinator or facilitator in the path to trust at all.

​
The invariants

  • Checks-effects-interactions. Payout happens after the grant; the provider is paid only once the capability has provably granted.
  • nonReentrant. The external adapter call cannot re-enter the broker mid-settlement.
  • The binding. nonce = keccak256(abi.encode(order)); the token’s own signature check rejects any altered order field.
  • Atomic, or nothing. Grant and settlement share one transaction. If the grant reverts, the transfer is undone, the token nonce is not consumed, and no funds move.

​
The attack surface

RiskMitigation
A relayer manipulates the adapter, params, or amountnonce = orderHash, so the token’s own EIP-3009 check rejects it (the binding).
Reentrancy via an external adapternonReentrant plus checks-effects-interactions; payout after the grant.
A malicious adapter drains fundsThe consumer signs the adapter (explicit authorization), so they alone choose which code may grant against their payment. Reputation via ERC-8004; audited adapters for the live deployments.
Payment replayEIP-3009 invalidates the orderHash nonce after use, so a settled order cannot be resubmitted on its chain. Cross-chain replay is stopped by the per-chain EIP-712 domain separator (the signature does not verify on another chain); order.nonce keeps two distinct orders from colliding.
Relayer front-runningThe order binds payee and amount; a relayer can only earn the predefined feeBps. First to transmit wins the fee, a healthy open market.
No native EIP-3009 USDC on testnetShip TestUSDC with EIP-3009, controlled by the deployment.

​
What a malicious relayer cannot do

A relayer is msg.sender and nothing more. It cannot change the adapter, the params, the amount, the payee, or the fee; any change breaks the signature at the token. It cannot be paid without granting, because payout is after the grant in the same transaction. It cannot raise its fee above the signed feeBps. It gains nothing from a revert; it spent gas and no funds moved. Its only levers are to relay the order verbatim or decline it.

​
Audit posture

The contracts passed an internal adversarial audit before every deployment, with a green verdict, alongside the test suite (Foundry unit and stateful-invariant tests, line and branch coverage on the core contracts, Slither clean at fail-medium). This is not a claim of perfection; it is a claim of bounded risk under the invariants above. Out of scope: the off-chain usefulness of a granted capability, and any third-party adapter a provider writes (the consumer chooses which adapter to sign, so adapter trust is per-order, see the table above). The deployed contracts are verified on-chain, see Deployments.