← Blog

v0.3.0 is live: hardening sprint walkthrough

2026-05-15 · Engineering trust contract-change ship

v0.3.0 plugin shipped: 2026-05-15.   v0.3.1 patch (Tier-1 close-out): 2026-05-15.   Server v0.12.0 → v0.12.1 deployed same day.

@paladinfi/eliza-plugin-trust@0.3.0 is the first public release of our on-chain-trust-anchor architecture for DeFi swaps on Base. The plugin verifies every /v1/simulate response against PaladinKeyRegistry on Base — a non-upgradable contract holding the current 2-of-2 KMS signing pair, the bundled TOKEN_REGISTRY_HASH, and a revocation mapping. An independent-from-the-codebase Gnosis Safe 2-of-3 owns the registry. The customer's defense against malicious key rotation is the 7-day on-chain timelock plus the plugin's sticky-revoked enforcement plus the keyTrustMode: 'pinned' config.

We held back an internal v0.2.0 candidate for a security-hardening sprint after a 3-adversary audit returned a major-rewrite verdict. The hardening shipped as v0.12.0 server / v0.3.0 plugin, then a v0.3.1 patch closed remaining ship-debt. This post walks through what changed and why, with links to the live contract, the verified source, and the live test pack.

What the audit surfaced

Three reviewers in parallel: Security (audit-mode framing — treat real-money signing as audit not code review), Maintainer (operational stability), and B2B Buyer + Domain Skeptic (would I integrate this in production). Security returned REQUIRES-MAJOR-REWRITE with four high-severity findings. Two findings were real and structurally fixable and drove the bulk of v0.3.0. Two more led to defense-in-depth fixes after we verified the transitive bindings against ground truth. Every flagged item got verified before becoming either a fix or a defense-in-depth improvement.

Process note. Three full rounds of 3-adversary review cleared before public ship: round 1 on v0.2.0 + initial test pack, round 2 on the v0.12.0 hardening, then a Tier-2 follow-up + a fresh Tier-1 review on the announce drafts themselves. Total cycle: roughly 10 hours of review-and-fix between the initial audit verdict and the npm publish. The Adversarial Review Gate says no public-surface deploy without 3-adversary cleared; the gate worked.

The signing digest changed (the C-1 fix)

Pre-v0.3.0, the signing digest formula was a single keccak over a raw domain prefix concatenated with the canonical JCS bytes of the response body: 

digest = keccak256(b"paladin-simulate-v1" || JCS(body))

The "domain separator" was the literal UTF-8 bytes of paladin-simulate-v1 — the same string that appears as the apiVersion field inside the canonical payload. Cross-service signature-replay defense was by-policy (different services use different prefix strings + key segregation across providers), not by digest math. The auditor flagged this as structurally weak: a sibling signed service using paladin-quote-v1 as both apiVersion and domain bytes, sharing a KMS key, opens cross-version sig confusion.

v0.3.0 ships a typed-domain digest with a hashed constant + a hash-of-hash pattern. Both inputs to the outer keccak are now 32-byte hashes, which cannot accidentally collide with any field value the way raw UTF-8 bytes can: 

DOMAIN_HASH = keccak256("PaladinFi/simulate/v2")  # 32 bytes, computed once
BODY_HASH   = keccak256(JCS(body))                # 32 bytes
DIGEST      = keccak256(DOMAIN_HASH || BODY_HASH) # 32 bytes

Wire format bumped paladin-simulate-v1 → paladin-simulate-v2. No v0.2.0 customers existed (this is the first public release), so the breaking change has no migration friction. A cross-language parity test asserts byte-equality of the new constant between the Python server signer and the TypeScript plugin verifier.

chainId is now signed explicitly (the H-1 fix)

The auditor flagged that chainId wasn't a top-level signed envelope field. They missed that chainId is bound transitively via requestHash (which the plugin already checked against expected — a tampered chainId in transit would surface as a requestHash mismatch, fail-closing the customer). But the transitive binding is implicit, and audit-grade defense-in-depth says make load-bearing checks explicit.

v0.3.0 adds chainId as a top-level signed envelope field, and the plugin verifier now asserts signed.chainId === expectedChainId as a direct invariant. The VerifyOpts interface gained a required expectedChainId parameter; both call sites in the plugin's swap action wire it through. A direct /v1/simulate caller sending the wrong chainId now gets caught at the explicit check, not just at the transitive binding.

Cross-language JCS strict mode (the H-3 fix)

Pre-v0.3.0, the Python and TypeScript canonicalizers behaved asymmetrically at the edges of safe-integer range. Python rejected integers above 2^53 - 1; TypeScript permitted them and serialized through JS Number. The asymmetry doesn't fire on any field in the current envelope (epoch, signedAt, gasUsed are all bounded well below 2^53), but a future field hitting the threshold would silently produce different canonical bytes on the two sides, which would break signature verification.

v0.3.0 makes TypeScript reject integers outside Number.MAX_SAFE_INTEGER too. Symmetric strict mode across both languages. Customers should keep monetary values as strings — that hasn't changed.

The other six items

Shorter walkthroughs of the remaining hardening:

What we didn't ship and why

The honest scope-notes section of the v0.3.0 announce names what's not in this release. Three items worth flagging:

Owner is PaladinFi-controlled. The Gnosis Safe 2-of-3 has all signer keys under operational control of a small team. The customer's defense against malicious rotation is the 7-day on-chain timelock plus the plugin's sticky-revoked plus the keyTrustMode: 'pinned' config plus monitoring pendingRotation in the returned TrustState. A future release adds an independent third-party Safe signer. The 7-day timelock IS the customer's defense in the interim.

Layer 4 is our Anvil, not yours. Truly independent simulation (Tenderly fork, local Anvil in the plugin) is on the roadmap but nontrivial in practice — the Uniswap V3 callback pattern's CallbackTransferFailed() revert in stateOverride mode means generic publicClient.call doesn't generalize across all aggregator paths we route through. We don't ship the optimistic version that pretends to work; the new e2e test #07 exercises real Velora calldata and honestly reports the Anvil revert as a documented Layer-4 limitation. The signing chain still verifies regardless.

KMS-backed signing keys, not HSM-on-prem. AWS KMS Key #1 = software-key FIPS 140-2 Level 1; GCP Cloud KMS Key #2 = HSM-backed FIPS 140-2 Level 3 (GCP rejects secp256k1 at software level — HSM is mandatory). Cloud-provider operator + lawful-process exposure is documented in the THREAT_MODEL.md. Evaluating HSM-on-prem is on the roadmap; we'll commit to a path when the operational tradeoffs are concrete.

vs running an Anvil fork yourself

A reasonable question: why pay $0.001 per call when I can run anvil --fork-url base locally for free?

A self-run Anvil fork covers Layer 4 of the plugin's 5-layer defense. The other four layers — router allowlist, selector deny-list, multi-token state-diff invariants, signed-bytes binding — run locally in the plugin for free, but they assume a signed envelope that binds the simulation result to the specific token + amount tuple you requested. That's the Layer 4 attestation v0.3.0 ships. The $0.001 per call buys the signature from the registered KMS pair, anchored to an on-chain epoch, and cross-validated against an independent invariant set. Layer 4 is trusted-but-attested; the signing chain (Layer 5) is what makes a falsely-favorable simulation result detectable by the customer's plugin. A DIY Anvil can't produce that attestation. Layers 2-5 are contributed independently by the plugin gate; you don't pay extra for them.

v0.3.1: Tier-2 follow-up items

v0.3.0 left three items as deferred ship-debt that the Tier-2 Security reviewer surfaced. v0.3.1 (same day) closes them: a new public /v1/simulate/health endpoint (so customers can probe the simulator's version unambiguously, not the co-deployed swap-router's /health), a quorum-tally key-type hardening (canonical hex string instead of raw int — defense-in-depth against future numeric type drift), and removing a dead Pydantic model that wasn't being used to validate the response path. No wire-format change between v0.3.0 and v0.3.1; the plugin update is a drop-in replacement.

Verify

Questions or repro cases: dev@paladinfi.com.