Governance Engine Sign only what you can prove
Verify user intent and onchain data before anything gets signed.
No more black-box trust
Every critical record is committed to a Merkle tree. Change one row, and the root breaks. Trust fails the moment data changes.
Intent signed on-device
Every sensitive action carries a passkey signature from the user’s device. We cannot forge it, replay it, or change what it authorized.
Two stateless components
The Governance Engine validates. A blockchain signer signs. You run both, with nothing to sync and no keys held by us.
TEEs optional, integrity built in
The proof is cryptographic, not hardware-bound. Use enclaves if you want them; integrity holds either way.
An injected user
signs nothing
The classic insider attack is adding a user in the database. With DFNS, credentials must be in the tree to authorize anything.
A credential must be in the tree to sign. Adding one to the database grants no power.
Each credential is tied to its registration count, so inserted credentials fail verification.
New credentials enter the tree only with verifiable signed intent.
Self-granted permissions
fail at use
A rogue actor who edits a permission row gains nothing. Permissions are governed records, so the change breaks the root.
Every permission is anchored. Edit one quietly, and the proof breaks.
Each signing request is checked against governed data, not an editable database row.
Even setup permissions are pinned, so the baseline cannot be rewritten unseen.
You cannot remove
a policy quietly
Policies are governed too. Change one in the system and the proof breaks. The signer verifies the right policy in force.
Every policy is tied to the root. Silent edits or removals fail verification.
The engine confirms the right quorum approved the governed policy, not an editable live row.
The Policy Engine defines the rules. The Governance Engine proves which rules were in force.
No one can
edit history
Policies depend on past transactions. Govern the history they read, and a rewritten record can’t approve a transaction that should be blocked.
Amount, asset, source, destination, and time are pinned. Edit them, and the proof breaks.
Updates preserve prior values, so each record remains verifiable as originally written.
Velocity limits run against governed history, not a ledger an attacker can rewrite.
Discover how Zodia Custody secures keys on DFNS.
“Thanks to their collaborative team and institutional-grade wallet platform, we've enhanced our operational capabilities and widened our business lines. Our security framework has also been reinforced by their state-of-the-art MPC cryptography.”
How integrity holds action by action
Sign the intent. Govern the data. Verify before signing. The same proof behind every operation.
0 data loss since 2020 · $100B+ assets secured · 400+ institutions using DFNS
The user authorizes on their own device.
Before any write, users sign the action with their passkey. The signature, the path, and a hash of the payload are bound into a challenge made outside our infrastructure, which we later re-verify.
// User signs the action on their device, before the API ever sees it
const userActionSignature = await dfnsApi.auth.signUserAction({
challenge,
credential: await navigator.credentials.get({ publicKey: { challenge } })
});
// The API only acts when the signature verifies against the registered passkey
const transfer = await dfnsApi.wallets.transferAsset({
walletId,
body: { kind: "Erc20", to, amount, contract },
userActionSignature
});
// Without the user signature, the request is rejected at the edge
// With it, the request enters the platform with provable user intentEvery protected write becomes a Merkle leaf.
Your Governance Engine polls ungoverned actions, serializes protected fields, and adds them to the tree. The record becomes provable; any change breaks the proof.
# Conceptual: every internal call carries an attestation document
# Verified by the receiving service against its pinned manifest
POST /internal/policies/evaluate HTTP/2
X-Dfns-Attestation: <base64-encoded Nitro attestation>
X-Dfns-Service-Id: policy-engine-v4
X-Dfns-PCR0: <measured boot hash>
Authorization: mTLS-cert-bound-to-enclave
# Receiving service verifies:
# 1. Attestation signed by AWS Nitro root
# 2. PCR0 matches the pinned manifest
# 3. Service ID is authorized in the routing graph
# Any failure: connection refused, alert raised, node quarantinedValidate the intent, the rules, then sign.
On each signature request, the engine re-verifies user intent, permissions, policy approvals, and transaction data. Only then can the Blockchain Signer sign.
-- Conceptual: every read at the storage layer is gated by attested identity
SELECT * FROM wallets
WHERE org_id = $1 -- tenant scope
AND decrypt(payload, tenant_key($1)) IS NOT NULL -- decrypts only inside TEE
AND requesting_service IN ('signing-v3', 'policy-v4') -- service ACL
AND attestation_valid(requesting_service); -- live attestation check
// What it looks like to a service: scoped, attested, audited
const pending = await internal.signing.listPending({
scope: "org:or-xxx-xxx",
attestation: currentAttestation,
// Cross-tenant read silently returns nothing. Cross-service read raises.
});