Custody Architecture
How non-custodial works here: what we can never do, what you can verify yourself, and what each compromise scenario actually costs.
Most platforms ask you to trust them. This page exists so you do not have to. Every claim below is checkable against a public blockchain, enforced by mathematics, or verifiable by code you run yourself.
The custody model in one sentence
We hold no key that can move your customers' funds, and neither does any third party we rely on. Every send requires a fresh signature from your Primary Signing Key, over bytes your own verifier has already checked, and no such key exists on our side to steal, subpoena, or misuse.
Where the keys actually live
Customer wallet addresses are derived through NEAR Chain Signatures, a decentralized MPC signing network. This is the part worth understanding, because it is what makes non-custodial a fact rather than a promise.
- No single machine anywhere holds a customer wallet's private key. Not ours, not yours, not any third party's. The key exists only as shares across the network's independent operators, and a signature is produced only when the network's threshold cooperates.
- The network signs only what your key authorizes. A signature request must arrive inside a message signed by your registered Primary Signing Key, for your identity. We cannot ask it to sign for you.
- The signer is a public, audited smart contract:
v1.signeron NEAR mainnet. Its code, its root public keys, and every signature it has ever produced are on a public chain. Your security team can inspect all of it without asking anyone's permission.
Your customers' funds never touch NEAR. Wallets live on the chains in Coverage. NEAR is purely the key-management layer underneath, the role a hardware security module plays in a traditional architecture, except that nobody owns it.
We verify the network before every use. Our systems pin the signer contract's version, code hash, root public keys, and fee parameters, and re-verify them against the live chain before any signature is requested. If anything has changed, including a lowered fee, signing halts until the pins are revalidated by a reviewed deploy. Values are never adopted from the live network.
Your two keys, and the division of authority
| Key | Temperature | Authority |
|---|---|---|
| Primary Signing Key | Hot, your KMS or HSM | Authorizes sends. Rotatable at any time, and addresses never change |
| Recovery Key | Cold, offline | Is your identity. Every wallet address derives from it. Installs or replaces the Primary Signing Key |
We store only the public halves. There is no key escrow, no break-glass access on our side, and no third key.
The threat model, honestly
| If this is compromised | The attacker can | The attacker cannot |
|---|---|---|
Your Api-Key | Read data, create operations | Move funds. Operations wait for your signature |
| Our database | Read records | Move funds. No private key material exists in it |
| Our infrastructure signers | Spend our fee-payment balances | Touch customer funds. Our keys hold zero authority over them |
| Our entire platform | Present you malicious payloads | Get them signed. Your verifier refuses before your key is touched |
| Your Primary Signing Key | Authorize sends from your wallets | Change which key is the identity. The Recovery Key revokes and replaces it |
| Your Recovery Key | Everything | This is the catastrophic case. Keep it offline, backed up, and out of the hot path |
The fourth row is the one that distinguishes this architecture. Read it again: even if every system we run is hostile, a signature only happens after your independent verification passes.
Verify, then sign, never the reverse
Every operation we prepare arrives with the complete inputs to rebuild it
from scratch using values you already trust: your own registered keys,
the wallet address and signing_reference you stored at creation, and
constants published on this site rather than taken from our response. Your
verifier reconstructs the exact bytes, requires them to match ours byte for
byte, and only then hands your KMS the digest.
This is stronger than reviewing a human-readable summary. A summary can lie about the bytes. A byte-for-byte reconstruction cannot be lied to. The full procedure is in the Signing Guide.
The verifier is not optional ceremony. It exists to be correct when we are compromised. Skipping it because the request came from us gives up the exact guarantee this architecture provides.
The worst case: what if Rasto disappears?
Your funds do not depend on our existence. This is checkable, not rhetorical.
- Your identity is an ordinary account on a public chain, controlled by your Recovery Key, held only by you.
- Each wallet's derivation path is published to you at creation as
signing_reference, and never changes. - The MPC signer contract is public. With your identity, your keys, and the published references, signatures over your customers' funds can be produced without any Rasto system participating. The network does not know we exist.
We intend to be the convenient way to use these wallets, not a required one.
What our own keys do
Rasto operates infrastructure wallets: fee payers and a transaction relayer. Their entire authority is paying network fees. They cannot move a customer token, they are funded and monitored separately per role, and every spend is recorded for reconciliation. The separation is structural: the code paths that sign for our wallets are incapable of naming a customer wallet.
Balances are the chain, not our bookkeeping
Wallet balances are read from the chain at request time, never from a ledger we maintain. A customer funded by a direct on-chain send is spendable immediately, and our records cannot diverge from reality, because the chain is the record. The same honesty applies to history: what happened on chain is what the API reports.
Operational discipline you can hold us to
- Authorizations expire in 30 seconds. They pin live chain state, so a stale one dies rather than being signed. Nothing we prepare is signable later.
- Every partner-visible mutation is audited: who, what, when, from
where. You read it in the dashboard, on a surface your
Api-Keydeliberately cannot reach, so a leaked key cannot read the trail of what it did. - Idempotency everywhere. A retried request cannot move money twice. Replay protection is layered from HTTP keys down to chain nonces.
- Nothing from behind the API substitutes for our own vocabulary. When something fails you hear a documented code with a documented action, not a third party's internals.