A valid credential, plus active on-chain authorization, plus every policy constraint satisfied, gives permission for one exact state transition.
§1Three authority modes#
| Mode | Who signs | Can do | Keys |
|---|---|---|---|
| DIRECT | The single key that derives the address | Anything, like a conventional account | Ed25519 |
| ROOT | Exactly a threshold of up to 8 root keys | Anything, including every authorization change | Ed25519 |
| SESSION | One session key under one grant | Only what the grant's policy allows | Ed25519 or P-256 |
A DIRECT account switches to ROOT mode irreversibly and keeps its address. Contract accounts have no signing authority of their own.
§2Four separate decisions#
§3Session grants and policies#
A grant is an immutable on-chain record that binds one session public key to one policy, a validity interval in block heights, a private nonce lane, and usage counters. A policy is a conjunction of built-in rules: every enabled rule applies, and none can call contract code, read a clock or reach an external service.
| Policy part | Constrains |
|---|---|
| Fee policy, required | Maximum gas, maximum price, maximum fee per transaction, lifetime fee limit, optional token bucket |
| Transfers | Recipients (a Merkle set), amounts, rate |
| Contract calls | Contracts, method selectors, ABI-head argument constraints, value |
| Contract creation | Allowed creation rules |
| Stake, unstake, delegate, claim | Validators and amounts |
| Attempts | Every authorized attempt counts, including failures and cancellations |
§4Ordering and revocation#
Every valid block places all control transactions before all user transactions. An included revocation, revoke-all or root rotation therefore takes effect before any session action in the same block, and a new grant cannot act in the block that creates it.
Revocation takes effect at inclusion and finality. The protocol cannot force a proposer to include it, so wallets broadcast revocations on several paths and show them as pending until finalized. Cancelling a session is not revoking it.
§5Consensus limits#
| Limit | Value |
|---|---|
| Root keys per account | 8 |
| Active grants per account | 64 |
| Session lifetime | 432,000 blocks, about 10 days at the 2 s target |
| Policy size | 16,384 bytes |
| Call rules / creation rules | 64 / 32 |
| Recipients per rule | 128 |
| Argument constraints per call rule | 32 |
| Authorization witness | 1,098 bytes |
| Authorization writes per transaction / per block | 16 / 4,096 |
A transaction over any limit is invalid, not merely out of gas. Authorization gas is charged per attempted signature, trie operation, policy rule, constraint and inspected byte, before expensive work starts. These constants are candidates until measured on the minimum supported validator hardware.
§6Deposits and the security reserve#
- Grant deposit: the larger of 1 RSC and 0.0001 RSC per stored byte, locked in the grant. An explicit revocation refunds all of it. Anyone may clean up an expired grant and earn 2%; the owner receives the other 98%.
- Security reserve: while any grant is active, sessions must leave at least the reserve untouched (minimum 0.1 RSC). Only ROOT can spend it, so the owner can always afford an emergency revocation.
§7P-256 passkey sessions#
Session grants accept P-256 keys (scheme 0x02): 64-byte X‖Y public keys and raw 64-byte r‖s signatures over the unchanged session digest. Browser passkeys and secure enclaves can therefore hold session keys. The chain verifies raw ECDSA only; wallets must validate the WebAuthn ceremony themselves. DIRECT, ROOT, validator and network keys remain Ed25519.
§8Guardian recovery#
A ROOT account may enroll up to three guardians with a threshold. When guardians reach quorum on a replacement Ed25519 root key, the replacement is frozen and two clocks start: 100,800 blocks and 604,800 seconds, which is seven days. Finalization is allowed only after both. Faster slots do not shorten the seven days.
- Finalization replaces authority atomically, invalidates all sessions, and keeps the address, balances, stake, names and deposits.
- Guardians never gain spending authority before finalization. A guardian quorum can take over an enrolled account whose owner fails to cancel, so owners must watch recovery state and keep enough funds to cancel.
- A lost root key cannot be rescued without prior enrollment. Sessions cannot configure, vote, cancel or finalize recovery.
§9Sponsored transactions#
A separate DIRECT account can pay gas for a DIRECT or ROOT sender. The sponsor signs with its own nonce and its own domain, RESILIENCE_SPONSOR_AUTH_V1, and funds the maximum gas; the sender still authorizes the action and funds any value it moves. Sessions cannot be sponsored, self-sponsorship is rejected, and sponsorship pays in RSC only. It is not an ERC-4337 entry point.
§10Names#
Names end in .rsc and are 1 to 63 lowercase ASCII letters, digits and interior hyphens. Registration uses commit and reveal, so a name is never published before its owner has committed to it.
| Label length | Registration burn |
|---|---|
| 1 character | 500 RSC |
| 2 characters | 200 RSC |
| 3 characters | 100 RSC |
| 4 characters | 50 RSC |
| 5 to 9 characters | 10 RSC |
| 10 or more | 5 RSC |
Renewal costs half the registration burn, and a commit burns 0.1 RSC. The reveal delay is 3 blocks, a commit times out after 43,200 blocks, a registration lasts 5,256,000 blocks (about 122 days at the 2 s target), and the grace period is 438,000 blocks. Expired names stop resolving. Policies should pin a resolved address, never a name, so a later name change cannot widen authority.
Sources: Session Authorization Protocol 0.2.0 and its V1 decision record; pkg/sessionauth, pkg/nameservice, internal/state/transition_v2.go, internal/state/recovery.go; session-authorization threat model 0.2.0.
Cite this page
@misc{resilience-protocol-accounts,
title = {{Accounts and authorization}},
author = {{Resilience Network}},
year = {2026},
note = {Reference implementation c3acec4, protocol manifest r28},
url = {https://resiliencenetwork.xyz/protocol/accounts/}
}