Cobault - Blockchain Architecture Assessment - Cobault

1.1 Observed Controls and Architectural Choices

The following is a record of controls and architectural decisions observed in the review that represent sound security practice. These are recorded here because a threat model should be an accurate picture of a system's security posture, not only a list of its weaknesses.

Vault and signing architecture

Non-custodial, per-transaction vault model. Each customer transaction is protected by its own independent vault. There is no pooling of funds, no shared signing authority across customers, and no rehypothecation. The design eliminates the class of failures — such as fractional reserve or mass-counterparty exposure — common in custodial models. [Architecture Deck, p.1]

Orchestrator holds no vault signing key. TechCo coordinates the entire system but is not a vault signer. The watcher, which builds and broadcasts transactions, holds the ProductCo key only through the productco-signer mediating service — it cannot call KMS directly. Admin controls can pause, cap, or halt operations but cannot grant new signing authority. This is a sound separation of coordination from custody. [Architecture Deck, p.6; Inventory, §5.1–5.2]

Customer timelock recovery is service-independent. After block height M, the customer can recover vault funds using only their own U_refund key, without any cooperation from Cobault, ProductCo, or the Verifier. This is enforced at the Bitcoin protocol level and holds even against a hostile Verifier (test case T34) or extended platform outage. [Architecture Deck, p.4; Inventory, §1.6]

SIGHASH_ALL enforcement. Both the ProductCo signer and the Verifier require SIGHASH_ALL on vault inputs, ensuring that any signature covers the full transaction — no output can be substituted after signing. [Inventory, §1.3; Client response Q3, verifier/services/verifier/src/lib.rs:1537]

Verifier independent settlement validation. Before signing any withdrawal, the Verifier independently fetches the Deribit settlement price, recomputes the customer/platform split from the immutable registered contract, and rejects any PSBT whose outputs deviate from that calculation. It also independently checks the chain tip and wall-clock time. No component of this validation is supplied by the orchestrator — it is derived entirely from the Verifier's own data sources. [Architecture Deck, p.5; Client response Q1, verifier/services/verifier/src/lib.rs:1112–1233]

All signing phases require Verifier countersignature. Confirmed by code review: phase_requires_verifier_sig returns true for all four defined signing phases with no fallback false case. The ProductCo signer verifies the Verifier's ECDSA signature against its own independently recomputed BIP-143 digest before using KMS. There is no currently orchestrated spend path that bypasses the Verifier. [Client response Q3, productco-signer/services/productco-signer/src/intent_validation.rs:473–516]

Content-addressed, append-only contract store. Vault contracts are stored content-addressed by canonical hash and are immutable after activation. Settlement records, refund signatures, price pins, and KMS key references are append-only, enforced by database triggers. These records are signed by the Verifier's Ed25519 identity key and can be independently verified. [Architecture Deck, p.13; Inventory, §4.2; verifier/services/verifier/migrations/0001_schema.sql:31,56,122,142,161]

Cryptographic implementation

Deterministic signing with audited libraries. Browser PSBT signing uses @scure/btc-signer v1.8.1, built on @noble/curves v1.9.7, which implements RFC 6979 HMAC-DRBG deterministic nonce generation.⁶ Seed generation uses @scure/bip39with crypto.getRandomValues, which throws if no secure random source is available. The signing path is covered by test vectors asserting deterministic output. [Client response Q6, user-app/web/key-agent/package-lock.json:473–490]

Canonical JSON with golden tests. All consequential messages use a deterministic serialisation defined in cobault-shared/canonical-json, with golden tests to ensure the same bytes are produced across all implementations and versions. This ensures that what is hashed is what is signed. [Architecture Deck, p.8]

Ed25519 service-to-service authentication with replay protection. All inter-service requests are authenticated using Ed25519 signatures over (timestamp, nonce, method, path/query, SHA-256 body hash). Nonces are consumed only after signature verification, and the in-memory nonce cache prevents replay. [Architecture Deck, p.2; cobault-shared/crates/cobault-auth/src/lib.rs:296,419]

Verifier identity rooted in a Nitro Enclave. The Verifier's Ed25519 identity key lives in an AWS Nitro Enclave. Decryption of the identity state is conditioned on the enclave's PCR0 attestation measurement via kms:RecipientAttestation:ImageSha384 — the key cannot be decrypted outside a verified enclave image. [Architecture Deck, p.7; cobault-verifier-keys-infra/infra/enclave.yaml:611,662,666]

Key isolation with sign-only KMS roles. ProductCo and Verifier vault keys are held in dedicated AWS accounts (ProductCo-KI and VerifierKeys-KI) separate from their operating workloads. KMS roles are restricted to kms:Sign and kms:GetPublicKey, with explicit IAM denies on decrypt, re-encrypt, export, key deletion, disable, policy mutation, and out-of-boundary signing. ABAC tag policies prevent consumer roles from modifying the cobault:keystore tag that gates key access. [Architecture Deck, p.7; cobault-productco-infra/infra/iam.yaml:116,204,216,233]

Infrastructure and operational controls

EKS Fargate for signer workloads. The ProductCo signer and Verifier API pods run on EKS Fargate, which has no EC2 instance metadata endpoint. This eliminates the IMDS credential-theft attack class for the primary signer workloads. [Client response Q4, cobault-productco-infra/infra/fargate-profile.yaml:38–52; cobault-verifier-infra/infra/fargate-profile.yaml:42–55]

IMDSv2 enforced on the enclave parent host. The only EC2 host in the signing path — the Verifier Nitro Enclave parent instance — is configured with HttpTokens: required and HttpPutResponseHopLimit: 2. The hop limit of 2 is correct for this deployment (the enclave supervisor runs in a container, which requires one additional hop). [Client response Q4, cobault-verifier-infra/infra/enclave.yaml:561–564]

kms:Sign captured by CloudTrail management events. AWS KMS cryptographic API calls, including kms:Sign, are captured by CloudTrail as management events when IncludeManagementEvents: true is set. Organisation-wide and key-org trails are configured with this setting and no ExcludeManagementEventSources: kms.amazonaws.com exclusion. [Client response Q5, cobault-shared/log-archive/org-cloudtrail.yaml:52–68]

Object Lock compliance-mode audit buckets for key organisations. Audit trails for the ProductCo-KI and VerifierKeys-KI accounts are stored in S3 buckets configured with Object Lock in Compliance mode — these records cannot be deleted or overwritten by any user, including account administrators, for the retention period. [Architecture Deck, p.7; cobault-productco-infra/infra/logging.yaml:99–116; cobault-verifier-keys-infra/infra/logging.yaml:99–116]

ProductCo signer pause state is persisted. The ProductCo signer maintains a pause state in Postgres (signer_admin_controlstable) that survives pod restarts. The /sign handler checks this flag before any vault or KMS work and returns 503 SIGNER_PAUSED if set. This provides a surgical, durable operational halt for the ProductCo signing path. [Client response Q5, productco-signer/services/productco-signer/migrations/0001_schema.sql:124–141]

Idempotent signing with immutable intent records. The ProductCo signer records signed intents with a primary key of (vault_id, phase, input_index), protected by an immutable database trigger that prevents modification or deletion. Duplicate requests return the cached signature; conflicting requests are rejected. This prevents double-signing and protects audit integrity. [Inventory, §3.3; productco-signer/services/productco-signer/migrations/0001_schema.sql:27,47,86]

Release-gating lifecycle tests. All custody-impacting changes must pass three end-to-end lifecycle tests on a private signet before deployment: T32 (full happy-path lifecycle), T33 (customer recovery via timelock after Verifier unavailability), and T34 (customer recovery after a hostile Verifier). These are not optional — they are release gates. [Architecture Deck, p.10]