For developers

§1Five things to know first#

1. Ethereum wallets cannot sign Resilience transactions. eth_sendRawTransaction accepts the chain's own V2 envelope, not Ethereum's RLP transactions. Use the TypeScript SDK (private and unpublished for now) or the command-line client.
2. Bind every signature to the chain. Configure the expected chain ID, genesis and capability in your application. Never learn them from the RPC endpoint you are talking to.
3. A simulation is advice. State, nonces, fees, grants and activation can all change before inclusion.
4. An ambiguous submission is not a failure. If a submit times out, keep the canonical bytes and the transaction ID and look that ID up. Never re-sign a replacement blindly.
5. Pending transactions are public. Use slippage bounds and deadline heights on market-sensitive actions, and never put secrets in calldata.

§2JSON-RPC#

JSON-RPC 2.0 over HTTP and WebSocket. A batch holds 1 to 32 calls, and a request or message is at most 2 MiB. A request without an id is a notification: it executes and gets no response. Successful responses always include result, even when it is null. Transaction lookups cover the node's recent window of up to 1,000 blocks, so null does not prove a transaction never existed.

The 18 eth_ methods each have an rsc_ alias served by the same handler: 67 registered methods in total, plus the subscribe and unsubscribe transport methods. Subscriptions are newHeads, newPendingTransactions, logs and syncing, up to 64 per connection. Notifications to a slow consumer can be dropped, so reconcile with reads after reconnecting.

curl -s http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"rsc_chainId","params":[],"id":1}'

§3TypeScript SDK#

A standalone TypeScript SDK covers the transparent account and session flow. Its repository is private and it is not published to npm yet.

• Canonical transaction, session and grant codecs and typed hashes, checked against pinned chain vectors.
• A bounded HTTP JSON-RPC transport with typed chain, authorization, fee and simulation reads.
• Raw Ed25519 and P-256 signers. You supply key custody; the SDK never stores private keys.
• A lifecycle API for DIRECT activation, ROOT grants, both session key schemes and revocation, with one-attempt submission that reports accepted, rejected, not sent or unknown.
• WebAuthn representation parsers for passkey sessions.

Out of scope today: a shielded wallet and the sponsorship lifecycle. Separate release gates remain for registry publication and licensing, production relying-party durability, other browser engines and physical devices, and independent security review.

§4Command-line tools#

§5Building from source#

For collaborators with access. The build needs Go at the version pinned in go.mod, Rust 1.88.0, a C toolchain and Python 3.11 or newer.

make build
./build/resilienced --help
./build/resilience-cli --help

make build builds the native cryptography and all binaries. A build with CGO_ENABLED=0 cannot process shielded activity and must never be used as evidence for it. The local development guide starts a four-validator network; a single daemon without a matching validator set does not produce blocks.

§6Showing authority to users#

Before a user approves a session grant, show the application, the session key's fingerprint and scheme, the allowed actions, recipients and method selectors, the validity heights, spending and fee limits, attempt limits, and any contract or proxy risk. Derive that display from the same bytes that produce the policy hash, so what the user reads is what they sign.

Keep session secrets apart from root secrets, and never send a private key to an RPC endpoint. A local "disconnect" button revokes nothing; only a finalized revocation does.