Security — routr

Trust model

routr holds two kinds of value: each pool's reserves, and what it owes to accounts (swap output in flight, fee shares not yet pushed). In the current code, reserves move only through swaps against the pool, and amounts owed move only to the account they are owed to. There is no method that transfers a pool's reserves elsewhere, no pause, no trader allowlist and no emergency withdrawal. Output is recorded as pending before its transfer leaves; if the transfer fails and its callback completes, the amount is recorded as owed for a later push.

The trade-off is deliberate: the planned keyless mainnet deployment has no admin pause method, including for us; swaps still depend on storage credit and pool state. The trading path does not scan all pools, and each trade updates only its own pool's reserves. Pools share the contract account, and pools of one platform share its storage credit.

What the owner can and cannot do

	Owner
Change the protocol's share of new pools' fees	yes, up to 30% of the pool fee, never above
Change the protocol's fee recipient	yes, for new pools
Change an existing pool's fee or split	no: terms are frozen at creation
Move pool reserves or user balances	no: no such function exists
Pause trading, block a trader or a token	no: no such function exists
Register, change or delete someone's platform	no: only the platform's own owner changes it, and a platform cannot be deleted

Keys and upgrades

On testnet the contract account keeps a key so it can be redeployed while the interface settles. The mainnet plan: after deploying the reviewed build to routr.near, remove every access key from that account so its code cannot be replaced, and show here how to verify that. The protocol owner is a separate account whose only power is the call above. A future version would be a new deployment that new pools can choose, while existing pools keep trading on the code they were created under.

Reproducible builds

The contracts are built in CI inside a pinned container (cargo-near reproducible build). Current routr build: code hash 8BKXgNYV8Qzr3HJZuNqS2Vee1zP28nax9rFDhW3iSuNC, 301,886 bytes, commit f277aba. The build deployed to mainnet will be the reviewed artifact, and its hash will replace this one. To check a deployment:

curl -s https://rpc.mainnet.near.org -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"query","params":{"request_type":"view_account","finality":"final","account_id":"routr.near"}}' \
  | jq -r .result.code_hash

The testnet account runs development builds and will not match a release hash.

Reviews

Each change to the contract went through internal adversarial review rounds, run with an AI code reviewer, focused on liabilities, storage griefing, pool-key squatting, arithmetic bounds and callback failure; findings were fixed and rechecked. No external security review has been completed yet. It is the gate to mainnet, and its report will be linked here.

Report a problem

Email security@routr.trade with the contract, the call and what you observed. Please do not post exploitable details publicly before we reply.

What routr can and cannot do.