Part IV — How can software request cryptographic capability without holding authority?
Reference implementation: cognokratos/arktos-wallet (Άρκτος), branch main, pinned in Source revisions.
Stack: Rust (Axum, Tokio), SQLCipher, MCP over streamable HTTP. Rust toolchain pinned to 1.97.1.
Give agents capabilities, never secrets.
Part IV is not a course in blockchain basics. It is about safely exposing cryptographic capabilities to software agents. The domain is a hierarchical deterministic wallet because it makes the stakes concrete: whoever holds the recovery phrase holds the funds.
What the system is, precisely
One Rust process serves:
- a stateless MCP endpoint at
/mcp(protocol2026-07-28), authenticated by a per-client API key in theX-API-KEYheader and looked up by HMAC; - an admin REST API for issuing, rotating and revoking those keys;
- liveness and readiness probes.
The API key is configured in the agent's MCP client. The model never sees it, but whoever holds it acts as that wallet owner, so it is a credential of the trusted runtime.
The MCP tool surface is exactly four tools:
| Tool | Effect |
|---|---|
ping | returns "pong" |
create_wallet | generates a 12-word BIP39 recovery phrase, encrypts it and stores it under the caller's key |
get_bitcoin_address | derives (and records on first use) a BIP86 Taproot address |
get_ethereum_address | derives (and records on first use) a BIP44, EIP-55-checksummed address |
A test pins that list. Other tests check that no result contains a seed, phrase or private key.
Arktos does not sign transactions, sign messages, broadcast, read balances or talk to any blockchain node. Its MCP and HTTP APIs export no private keys, seeds or recovery phrases. No tool gives an agent the ability to move value. Wherever the lessons discuss signing, it is labelled future design.
Custody: who can see a secret
The lessons are careful here, and so is this book:
- The model never receives secret material through any tool.
- The service decrypts a recovery phrase briefly, in process memory, to derive an account. Private keys exist for the duration of one derivation and are neither persisted nor returned.
- The operator holds
MASTER_KEYandDATABASE_KEY, and has deliberate tooling (make decrypt,src/bin/secret.rs) that can decrypt and print a stored phrase. If the wallet owner runs the instance, there is no third-party custodian. If someone operates it on another's behalf, that operator has effective custody.
"Self-hosted" describes who runs the software. It does not mean "non-custodial" from every participant's point of view.
How this part is organised
- The learning path, including the authority-flow diagram and the lab setup.
- Lessons C1–C8: authority, key hierarchies and HKDF domain separation, versioned authenticated encryption, secret lifetimes and zeroisation, standards-based derivation, identity bound to capability, least-capability tools, and recovery.
- Follow one secret: where a secret exists, for how long, and who can see it.
- Case studies and Challenges. The first challenge is to design safe transaction signing, which Arktos does not implement.
- Reference: API contracts and data models.
Running the labs
Lessons C1–C5 need only rustup (the toolchain installs itself), a C compiler,
make and perl. The first build compiles SQLCipher and OpenSSL, so it is
slow. From C3 onwards some labs run a throwaway local server on port 8080 and
also need curl, python3 and the sqlcipher command-line tool. Use lab keys
in a scratch directory and never a database that holds real wallets. Lesson C2's
"break it" step edits source code, so work in a throwaway clone. See
Setting up each track.
Prerequisite. Part I stage 3 (MCP as a capability boundary) and stage 8 (identity). The learning path's table lists every concept it borrows and from which part.