Not every key has the same threat model. Not every key needs the same custody. The architecture distributes keys across three tiers by frequency of use and consequence of loss. Operational specifics live elsewhere — this document captures the shape, not the procedures.
This document is architectural. It names the tiers, the keys, the threat models, and the procedures at the level of "what kind of operation occurs." It does not name specific hardware models, specific OS configurations, specific physical locations, specific transfer mechanisms, or specific software builds for the cold tier.
Operational specifics live in a separate, private document under the operator's exclusive control. References to redacted material are marked with a hatched block and the label OPERATIONAL · PRIVATE.
This separation is the right discipline. Architectural documents that include operational specifics become attack surfaces. Architectural documents that omit them remain useful for planning while keeping adversaries blind to the actual implementation.
A single signing system can't serve every key the platform owns. The keys differ in frequency, consequence, and recoverability — the custody model has to differ too.
Paxiom will own multiple keypairs across its operational lifetime. The KYA primitive needs a signing key. The x402 settlement uses a wallet. The AO processes have admin keys. Eventually the LLC entity has master keys and the treasury has its own. Each of these has different operational characteristics — how often it signs, what it costs if it's lost, what it costs if it's stolen — and applying the same custody model to all of them is a mistake in both directions.
Treating every key as if it needed maximum security creates operational friction that breaks the platform — customers can't wait minutes for a manual signing ceremony on every transaction. Treating every key as if it needed operational availability creates exposure that breaks security — the LLC master key sitting on the production server next to the operational keys multiplies the consequence of any single compromise.
The three-tier architecture is the standard answer to this trade-off in serious key custody. Hot keys are available, automated, and survivable because they're scoped narrowly. Cold keys are protected, manual, and rare because compromise would be catastrophic. Warm keys sit in between for operations that recur but don't justify the latency of cold-tier ceremony.
The threats Paxiom's keys face are not theoretical. The agent commerce ecosystem is actively targeted. Lazarus Group and similar state actors extract substantial value from DeFi infrastructure. Sophisticated criminal organizations target service operators. Lookalike attacks impersonate legitimate platforms. Each of these is a distinct adversary with distinct capabilities.
The keys most likely to be attacked are the ones with the most reachable attack surface and the most concentrated value. The x402 settlement wallet holds incoming customer payments and is reachable through standard internet exposure. The KYA signing key is reachable through the same channels and its compromise would let an attacker impersonate the platform indefinitely. The cold-tier master and entity keys are unreachable through internet attack surface but are subject to physical and supply-chain compromise.
Defense in depth matters because each tier compromise must be survivable. Hot tier compromise drains the operational wallet and forces emergency key rotation but does not compromise the platform's identity (because KYA keys are warm-tier or higher). Warm tier compromise allows specific operations during the compromise window but is detected and recovered through cold-tier authority. Cold tier compromise is catastrophic — therefore the cold tier is engineered to be the hardest to compromise.
End-user wallet security. Customers who interact with Paxiom manage their own wallets. Paxiom never holds customer keys, never custodies customer funds beyond per-transaction settlement, and never displays seeds or private keys to anyone in any context.
Implementation specifics for the cold tier. The architectural sheet (E-203) describes what the cold tier is. The procedures (E-300, E-301) describe what flows through it. The specific hardware, OS, software stack, and physical environment are covered in a separate operational document under the operator's exclusive control.
The cryptographic substrate the platform builds against. Standard, audited, not novel.
secp256k1 for Ethereum-compatible operations (x402 settlement wallets, Ethereum identity attestations, anything that signs transactions on EVM chains).
Ed25519 for everything else (KYA platform identity, AO process ownership, generic message authentication). Smaller signatures, faster verification, fewer footguns than ECDSA.
Not used: RSA at any size. Brittle, large, slow, encourages bad implementations. No legitimate need for it in this architecture.
Mnemonic seed phrases for backup and recovery. Hierarchical deterministic derivation for cold-tier child keys. Standard derivation paths where applicable.
Implication: seed phrases are the actual secret. Their storage is the cold-tier custody problem. Compromise of a seed compromises every key derived from it.
Structured signing for any payload that touches Ethereum. EIP-191 personal_sign for human-readable messages. EIP-712 typed data for structured payloads. Both prevent replay attacks and signature malleability that plague raw signatures.
v1 stance: EIP-712 mandatory for any key that signs cross-context payloads. Keys scoped to a single domain may use simpler formats but must include domain separation in the payload.
SHA-256 for non-Ethereum contexts. Keccak-256 where Ethereum compatibility requires it. Both are standard, audited, and have widespread library support.
Not used: SHA-1 (broken), MD5 (broken), proprietary hashes of any kind, custom hash constructions.
libsodium for Ed25519 and general cryptographic primitives. Audited, conservative, hard to misuse.
Standard wallet libraries (ethers.js, ethereum/go-ethereum's signing, arweave-js for AR/AO, ArConnect-compatible signing patterns) for curve-specific work. No custom cryptographic implementations anywhere in the codebase.
NIST SP 800-57 for general key management lifecycle guidance. NIST FIPS 186-5 for digital signature standards. IETF RFCs for protocol-specific signing formats. These are the references when a procedure question doesn't have an obvious answer.
Note: NIST post-quantum guidance is relevant for Phase 5 (Orion, Rokokko) but not for Phase 1. Current keys are not post-quantum. Migration plan exists in the build map but is not a v1 concern.
Comprehensive list. Every key named, classified, and assigned to a tier. What gets generated, when, and why.
| Key ID | Name & Purpose | Curve | Tier | Use Frequency |
|---|---|---|---|---|
| K-001 | KYA Platform Identity Signs every service response. Public key published as the platform's verifiable identity. |
Ed25519 | Hot | Per-transaction (high) |
| K-002 | x402 Settlement Wallet Receives customer payments via the facilitator. Funds settled here are subsequently swept to treasury. |
secp256k1 | Hot | Per-transaction (high) |
| K-003 | Service Deployment Key Deploys and updates platform services. Holds CI/CD credentials and infrastructure access. |
Ed25519 | Warm | Per-deployment (low) |
| K-004 | AO Compliance Process Owner Admin of the AO compliance logger. Authorizes handler updates and process configuration changes. |
Ed25519 | Warm | Rare (process changes) |
| K-005 | AO Service Process Owners (per service) One per Phase 1 service. Each AO process has a unique owner, separated for blast-radius reasons. |
Ed25519 | Warm | Rare (per service) |
| K-006 | Treasury Wallet Holds platform earnings beyond operational reserves. Funds swept here from K-002 on a defined cadence. |
secp256k1 | Cold | Periodic sweep + disbursement |
| K-007 | LLC Entity Master Once the LLC is formed: parent of all entity-owned keys. Used for legal-document signing and ownership attestation. |
secp256k1 | Cold | Annual / structural events only |
| K-008 | KYA Master & Recovery Master key for the KYA primitive. Authorizes K-001 rotation. Used only for compromise response or planned key turnover. |
Ed25519 | Cold | Rare (rotation events) |
| K-009 | Hot-tier Recovery Backup recovery key for K-001 and K-002. Geographically separated from the cold-tier machine. |
Ed25519 | Cold | Emergency only |
Inventory grows as the platform expands. Phase 2 services add additional service-process owner keys. Phase 4 enterprise contracts may require additional B2B-specific signing keys. The architecture supports growth because each new key gets evaluated against the same tier criteria (frequency × consequence) and assigned accordingly.
Every key added gets entered in this inventory before generation. Generation procedures (E-300) require an inventory entry as a precondition.
No key in this inventory is reused for any purpose outside its named function. The KYA signing key never signs settlement transactions. The settlement wallet never signs identity attestations. The AO process owners never sign anything outside their respective processes.
Cross-purpose signing creates correlation attacks and complicates incident response. Each key has a single bounded purpose. New purposes get new keys.
Available continuously. Automated. Scoped narrowly so compromise is survivable.
Hot-tier keys live on the production server. They sign in real time as customer requests arrive. The KYA key signs every service response (potentially 10,000+ signatures per month at full Phase 1 volume). The x402 settlement wallet signs facilitator interactions on roughly the same volume.
Keys encrypted with a passphrase known only to the operator. Passphrase not stored on the production server in any form. Decryption happens at process start, key material lives in process memory only, never written back to disk.
On process restart, the operator provides the passphrase. This is a manual step. It means production server reboots require operator attention. That friction is acceptable because reboots are rare.
The hot tier is the most reachable, so it is engineered to be the least valuable per individual compromise.
Every hot-tier signature gets logged to AO/Arweave permanently. Anomaly detection runs on signature volume — sudden spikes or unusual patterns trigger operator alerts via the same notification surface the audit relay uses (M-203).
Rate limits at the application layer prevent runaway signing in the event of a logic bug or compromise. Configurable per-key, per-minute and per-hour caps. Exceeding the cap pauses signing and notifies the operator.
Detection triggers immediate operator notification. Operator initiates cold-tier rotation ceremony (E-302). New key published; old key revoked through KYA primitive update; settlement wallet replaced with successor; downstream systems alerted. Recovery time objective: hours, not days.
Attached when needed. Detached otherwise. Sits between hot's availability and cold's ceremony.
Warm-tier keys handle operations that recur but don't require per-transaction availability. Deployments. Process configuration changes. AO handler updates. These happen on the order of days, weeks, or occasions — not seconds.
Hardware wallet (Ledger, Trezor, or equivalent) attached to the operator's workstation when an operation is needed. Disconnected between operations. The hardware wallet's onboard security elements protect the private key from malware on the host machine.
Alternative for keys not supported by hardware wallets (some Ed25519 paths, AO-specific formats): encrypted key file stored on removable media kept separately from the workstation. Mounted only when needed, unmounted and stored securely afterward. Same operational discipline as the hardware wallet — present only during use, absent otherwise.
Warm-tier compromise is detected through unauthorized operations appearing in the platform's audit trail. Response: cold-tier ceremony generates a successor key, the compromised key is revoked from any systems that recognize it (AO process admin lists, deployment access lists, etc.), and the audit trail is reviewed for any operations executed during the compromise window.
Warm-tier compromise is more recoverable than hot-tier compromise because the key is not exposed to internet attack surface. Recovery time objective: a day or two, not hours.
Rarely used. Manually signed. Operationally inconvenient on purpose. The keys whose loss is catastrophic.
The cold tier is engineered to be the hardest target for the keys whose compromise is most consequential. Several structural choices define it.
The argument is structural. Modern hardware has a substantially larger attack surface than hardware from before the relevant vulnerability classes were introduced.
The trade-off is real: pre-modern hardware is less performant, less reliable, and harder to source replacements for. For a machine that signs rarely and runs minimal software, the trade-off is acceptable.
Signing requests enter the cold-tier machine through the defined transport. The daemon parses the request, verifies it against the machine's local policy (what keys are authorized, what payloads are acceptable, what limits apply), signs if authorized, returns the signature through the same transport.
Each request and signature is logged on the cold-tier machine permanently. The log is part of the cold-tier audit trail and is transferred out periodically through the same controlled transport.
Cold-tier compromise is the worst case. Detection requires noticing either physical compromise (the machine is missing or has been tampered with) or anomalous downstream signatures (operations attributed to cold-tier keys that the operator did not perform).
Response involves the recovery keys (K-009 and other recovery provisions) generating successor keys, emergency revocation of the compromised keys through whatever channels recognize them (LLC records, treasury succession, KYA master rotation), and a forensic review of the platform's history to identify any signatures the attacker may have made.
Cold-tier compromise is engineered to be the rarest event in the threat model. The platform survives a hot-tier compromise routinely and a warm-tier compromise with effort. A cold-tier compromise is a foundational event that requires multiple recovery steps and potentially affects the platform's identity continuity.
Generation procedures by tier. The how varies; the discipline doesn't — randomness is real, the procedure is documented, and the artifact gets inventoried before it gets used.
Generated on the production server during initial setup. Standard library calls (libsodium for Ed25519, ethers/web3 for secp256k1). Random source is the operating system's CSPRNG. Generated key material is immediately encrypted with the operator's passphrase before being written to disk. The unencrypted key never touches non-volatile storage.
After generation, the public key is published to the canonical locations (paxiom.org for K-001, on-chain interactions for K-002 once funded). The operator records the inventory entry. The procedure log captures the generation timestamp, the host, and the public key.
Generated on a hardware wallet during a deliberate setup ceremony. Operator initiates seed generation through the hardware wallet's onboard process. Recovery seed phrase recorded on appropriate medium and stored according to the operational document's procedures (separate location from the hardware wallet itself, geographic separation from cold-tier backup).
After generation, public address is recorded in the inventory and registered with whatever systems will recognize it (AO process admin lists, deployment infrastructure, etc.).
What this document does specify: the generation event creates an inventory entry before the key is used for any operation. The public key (or address) is recorded. The procedure log captures what was generated, when, and the public artifact. The private artifact never appears in any document, in any inventory, or in any system other than the cold-tier machine itself and its physical backup.
The shape of a cold-tier signing operation. Specific commands and mechanisms live in the private operational document; the architectural flow lives here.
Pre-transport review on the networked workstation. Physical confirmation on the cold-tier machine. Post-signing application step. Each is a separate decision point. The ceremony cannot complete without three affirmative operator actions.
This is the structural defense against ceremony-shortcut errors. A signing request that gets all three confirmations was reviewed three times. Errors that pass three reviews are extraordinary, not routine.
The mechanics of "transfer request to cold-tier machine" and "transfer signature back" are deliberately not specified here. The choice of transport mechanism is a security decision with multiple defensible answers depending on operator preferences and threat tolerance. That decision lives in the operational document.
What matters architecturally: the transport is narrow (carries one request and one signature, nothing else), operator-mediated (no automated bridge between machines), and producing visible artifacts (the operator can inspect what crosses).
Two procedures that share a structure. Rotation is the planned version; compromise response is the unplanned version under time pressure.
Hot-tier keys (K-001, K-002) rotate annually as standard hygiene. The procedure is documented, scheduled, and unhurried. New successor key generated. Public attestation signed by the cold-tier master authorizing the succession. New key brought into production while the old key remains active for a transition window. Old key revoked after the window expires. Audit trail records the transition.
Warm-tier keys rotate less frequently because their use frequency is lower. Annual review evaluates whether rotation is warranted; rotation occurs when warranted but is not automatic.
Cold-tier keys rotate rarely. Every rotation is a structural event that affects the platform's identity continuity. Master key rotation requires attestation that ties the new master to the old, preserving identity across the rotation event.
Detection mechanisms differ by tier. Hot-tier compromise is detected through anomaly detection on signature volume and patterns. Warm-tier compromise is detected through unauthorized operations appearing in audit trails. Cold-tier compromise is detected through physical inspection of the cold-tier machine and through downstream signatures the operator did not authorize.
Response time objectives reflect the consequence of each tier:
Every compromise response generates a forensic record. The record captures when the compromise was detected, what evidence supported the determination, what operations were authorized during the suspected compromise window, which were legitimate, and which (if any) were attributable to the attacker.
Forensic records are preserved permanently. They become reference material if subsequent incidents occur and they support any legal or regulatory process that might follow a serious compromise. The AO/Arweave audit trail makes this preservation structural rather than an additional operational burden.
Recovery keys (K-009 specifically and the recovery provisions for warm and hot tier keys generally) are the second-line defense. Their custody follows the same principles as cold-tier keys but with geographic separation from the primary cold-tier machine.
Specific failure modes and the planned response to each.
Attacker gains code execution on the production server, extracts K-001 and K-002 from process memory before the operator detects and rotates.
Mitigation: Bounded blast radius (K-002 holds operational balance only, swept regularly to K-006). KYA primitive revocable through cold-tier ceremony. Anomaly detection and rate limits reduce time-to-detection. Memory hygiene practices (no swap, no core dumps, mlock where possible) reduce extraction risk during compromise.
Production server reboots and the operator cannot supply the passphrase to decrypt hot-tier keys. Service is down until passphrase is recovered or keys are rotated.
Mitigation: Passphrase recorded in operator's personal records with appropriate physical security. Recovery keys (K-009) provide an alternative path that bypasses the original passphrase entirely if needed. Clear operational documentation so partner or successor can execute recovery if the operator is unavailable.
Physical hardware wallet is lost, destroyed, or stops working. Warm-tier keys cannot sign new operations until recovery is performed.
Mitigation: Recovery seed phrase preserved per the operational document. New hardware wallet provisioned, seed restored, operations resume. Recovery time depends on ability to acquire replacement hardware — typically days.
The cold-tier machine is stolen, tampered with, or otherwise physically compromised. Master keys may be exposed.
Mitigation: Physical security per operational document. Tamper-evident packaging where appropriate. Recovery keys (K-009) stored geographically separately from the cold-tier machine so a single physical event does not compromise both. Compromise response plan rehearsed periodically.
Bug in the cold-tier signing daemon allows an attacker who can submit requests through the transport to extract key material or sign arbitrary payloads.
Mitigation: Daemon scope is minimal — single program, audited code, narrow input format, strict policy enforcement. Daemon built from inspectable source. Updates are rare and follow the same controlled transport as signing requests. Multiple-eyes review of any daemon change before deployment.
Operator becomes incapacitated, deceased, or otherwise unavailable. Key custody depends on personal knowledge that does not survive. Platform cannot recover keys, cannot operate, and cannot be transferred to legitimate successors.
Mitigation: Succession planning lives in the operational document. Trusted person (partner, family member) has access to recovery procedures sealed appropriately. LLC formation when complete provides legal structure for succession. This risk is uncomfortable to plan for but mature operations require it.
Future cryptographic advances (quantum computing or unforeseen classical breakthroughs) compromise secp256k1, Ed25519, or the hash functions in use. Long-lived keys may need migration before retirement.
Mitigation: Phase 5 of the build map includes post-quantum migration. NIST guidance tracked. Architecture supports curve migration through the rotation procedures (E-302) — keys can be replaced with successors using different curves without losing identity continuity.
This set is the E-series — Electrical / Key & Identity Management. Companion to A-series (Phase 1) and M-series (audit relay tooling). Future sets reserved by the master plan: S-series (Structural / security audit findings, separate from this key-custody document), L-series (Landscape / public-facing surfaces), O-series (Operations runbook).
This document is architectural. Operational specifics — specific hardware configurations, software builds, physical locations, transfer mechanisms, exact procedures — live in a separate private document under the operator's exclusive control. The two documents are deliberately separated: this one is shareable with collaborators, advisors, or auditors; the operational document is not.
Where the architectural document needs to reference operational specifics, the reference is marked with the OPERATIONAL · PRIVATE hatched block. Anyone reading the architectural document can see what exists; the specifics are deliberately absent.
A-series Phase 1 Blueprint — KYA primitive (K-001) is specified at the architectural level there; this document specifies its custody. The two compose: A-series describes what gets signed, this document describes how the signing key is protected.
M-series Audit Relay Blueprint — the relay's signing of its own state changes uses keys consistent with this document's tier model.
Operator's Private Operational Document — captures the specifics this document deliberately omits. Lives only in the operator's controlled storage. Updates to this document do not require updates to the operational document and vice versa, except where the architectural shape changes.
Rev. A — 2026.04.29. Initial issue. Three tiers specified. Nine keys inventoried. Procedures for generation, signing, rotation, and compromise response. Risk register with seven entries. Operational specifics deliberately omitted.
Subsequent revisions issued as the platform expands. Rev. B expected when LLC formation completes (K-007 entered into active use). Rev. C expected when first Phase 1 service launches (K-005 fleet expands per service).
The keys outlast individual decisions about everything else. They will sign attestations that the platform's customers rely on years from now. They will authorize transfers that the platform's treasury depends on. They will identify the platform across whatever standard succession KYA goes through over the next several years.
That makes the architecture decisions in this document load-bearing in ways that the platform's other architectural decisions are not. Phase 1 services can be redesigned in Phase 2. The audit relay can be rewritten when its limitations show. Key architecture cannot be redesigned without losing identity continuity, breaking trust with downstream systems, and forcing every counterparty to accept a new attestation chain.
Build the engine first. The moats come later. The keys come first of all.