Skip to main content

​
Routes

  • Per-intent rewards. Vaults hold rewards separately, but share contract implementations and depend on the selected prover and token contracts. See Vaults and resource locks.
  • Proof-based settlement. The source Portal reads the intent’s configured prover before withdrawing the reward. Review that prover’s verification and configuration; implementing the interface is not a security guarantee. See Provers.
  • Separate execution. Destination calls run through the Executor. A reverted call rolls back that destination transaction, while source funding and refunds follow their own lifecycle. See Executor.
  • Quote signatures. Verify a v1 quote against the published quoteSigner and check its amounts, recipients, and execution instructions before funding. A valid signature authenticates the signed quote fields; it does not establish every downstream call’s business outcome. See Quote verification.
Match the contract source and ABI to the actual deployment. A non-upgradable contract or a published audit does not eliminate contract, token, or integration risk.

​
Sauce

  • Owner-authorized cooks. An EVM Pot runs a cook sent by its owner, and refuses anyone else with NotOwner(). An EVM Pot created with the current release also runs a cook its owner signed and another account submits (cookSigned); the owner cancels unused signatures with invalidateNonces. The owner is fixed when the Pot is created. Anyone may deploy your Pot or send it tokens; neither gives them control of it.
  • Transaction rollback. An unhandled failure reverts the cook’s changes. On EVM chains, a caught failure rolls back its try block before the handler runs. Earlier approvals are outside that rollback, and an unused approval from a successful cook can remain: approve only what the next call needs. See Errors and reverts.
  • Fixed Pot code (EVM). An EVM Pot’s code never changes once it is deployed. The Kitchen, which creates Pots, is an upgradeable proxy; its owner sets the fee every cook pays and the Router that new Pots start on.
  • An upgradeable Kitchen on Solana. The Solana Kitchen requires the Pot’s owner to sign each cook and signs for the Pot. Its upgrade authority can replace that program, and must be trusted with what every Pot holds. The engine has no upgrade authority, which does not make the Kitchen immutable. See Trust on Solana.
  • Engine and Kitchen pairing (EVM). An engine runs only a Pot that its paired Kitchen created. No SDK operation moves a balance between Pots.
  • Checked token writes. A program’s token writes follow OpenZeppelin’s SafeERC20 rules. A raw ABI call you write yourself is not checked that way.
  • Unread call results (EVM). A bound contract call whose result the program never reads is not decoded or checked: an empty or malformed reply, or a call to an address with no code, passes. Read the result, check ctx.isContract(address) where the target must have code, and use the SDK’s token writes for tokens.
  • What Sauce cannot check. It runs the program you wrote. Simulate it before you sign, and give every swap a minimum output inside the program: the price can move before the cook is included.
See Security considerations and Deployments.

​
Audit reports

Consult the Cantina portfolio for published reviews and any listed bounty program. Match each report’s scope and reviewed commit to the component and release you use.

​
API keys

Keep API keys on your server and send them in the x-api-key header. Do not embed them in client applications, URLs, or logs. See Get set up.

​
Reporting an issue

Report security issues privately to contact@eco.com. For a repository with its own security policy, follow that policy; Permit3 accepts private vulnerability reports.