Control Rail overview
Control Rail is an institutional pre-execution control layer that adds compliance and policy control on top of non-custodial wallets. Instead of leaving policy in app or server logs, it verifies approvals and quorum conditions on-chain.
On EVM, account-abstraction smart-account validation enforces the logic; on chains with native multisig, quorum verification does. A chain adapter maps the same condition to each network's enforcement primitive.
What it solves
Running digital assets at an institution takes two things at once: control that cannot be bypassed and proof that it was followed. Server-side policy and after-the-fact logs cannot stop a transaction, and a single signature makes policy compliance hard to verify from the outside.
- Control that cannot be bypassed — every transaction must pass institutional policy and quorum before it executes.
- Evidence before execution — approvals, holds, rejections, and outcomes remain as an auditable trail.
- Non-custodial — user keys stay on the device; ControlRail never holds them.
Role boundaries
Who is responsible for what is clearly separated. ANAM145 operates the infrastructure but does not make the institution's business-policy decisions for it.
| Party | Role |
|---|---|
| Institution | Defines policy — limits, allowlists, permitted assets, exceptions — and approves or rejects at /sign. |
| ANAM145 | Verifies that approval signatures come from registered signers, orchestrates the KYT, quorum, and broadcast flow, and records the whole process. |
| Chain / account | Enforces the final execution condition. On EVM this is smart-account validation; on native-multisig chains it is quorum verification. |
Transaction flow
It starts at a user intent and ends at chain execution. The gateway handles orchestration; final enforcement belongs to the chain adapter and the account or protocol.
User → gateway
POST /submit · token · txId · userSignature
Verify token
verifyToken resolves the tenant, user, and wallet.
Call institution /sign
Sends operation, address, and tx; receives an institutionSignature or a reject.
KYT evaluation
If KYT is on, risky wallets and counterparties are screened up front.
ANAM145 signature
The infrastructure signer joins only requests that pass policy and risk.
Verify & combine
Checks that signatures are valid for the registered public keys and that quorum is met.
Broadcast
The chain adapter submits only approved transactions to the network.
Final enforcement
Quorum or smart-account validation is enforced at the chain level.
Return result
Returns and records status, hash, and reject reason in the same flow.
Signer presets · recovery
A wallet is made up of user, institution, and ANAM145 signers. The actual weights and recovery policy are set per chain implementation and institutional policy.
| Preset | Normal transaction | Recovery |
|---|---|---|
| Strict | Requires user, institution, and infrastructure approval | Restricted per institutional policy |
| Recoverable | Same pre-execution approval | Key rotation with institution + infrastructure approval |
Data boundaries
Key material never leaves for the server. The SDK creates keys and signs on the device; only public keys and signatures go to the server.
| Operation | On the client | To the server | Never leaves |
|---|---|---|---|
| Wallet creation | Generate user key | Public key | Private key · mnemonic |
| Transaction | Review tx, then sign | Signature | Private key |
| Recovery | Generate new key | New public key | Old & new private keys |