Governance Engine

End-to-end integrity. Not just enclave-deep.

Every request signed by a TEE certificate. Every datastore cryptographically isolated. Every internal call pull-based and verifiable. The integrity guarantee extends from the API edge to the signature, not just inside the enclave.

Governance Engine dashboard
TEE certs on every hop

Every service signs every response with a hardware-bound TEE certificate. Verified by the next service. No trust assumed between components.

Database isolation by cryptography

Per-tenant, per-service encryption keys derived inside TEEs. No service reads what it isn't entitled to. No operator reads anything at all.

Poll-only data flows

Internal services pull from authenticated queues. No push, no injection paths, no man-in-the-middle. The data plane has one direction.

Beyond verifiable cloud

Most attestation stops at “the enclave ran trusted code.” Ours covers the request, the routing, the storage, and the signature. End-to-end, not enclave-deep.


Attestation is the new audit trail

Every step of every request leaves a cryptographic receipt. The audit isn't generated — it's what actually happened.

Hardware roots

TEE-backed certificates
on every service

Every microservice in the DFNS control plane runs in a Trusted Execution Environment. Each one carries a hardware-bound certificate, signed at boot by AWS Nitro attestation. Every call between services is mutually authenticated. No certificate, no conversation.

Per-service identity

Each service has its own enclave-bound key pair. Service-to-service mTLS terminates inside the enclave. Compromised hosts can't impersonate services.

Boot-time measurement

PCR values are captured at enclave launch and verified against pinned manifests. Unknown binaries don't get certificates. Unknown certificates don't get calls.

Continuous attestation

Re-attestation runs on a schedule, not just at boot. A drift in measured state revokes the certificate and quarantines the node.

Wallets dashboard
Data plane

Every datastore
cryptographically isolated

Per-tenant encryption keys, derived inside TEEs, never exported. Per-service access scopes, enforced at the storage layer. Operators see encrypted bytes. Services see only the rows their certificate authorizes.

Tenant-bound keys

Each organization gets a distinct key, derived from a master sealed inside an enclave. Compromise of one tenant's data plane reveals nothing about another's.

Service-scoped reads

The policy engine reads policies. The signing service reads pending requests. No service queries outside its scope. Cross-scope access requires cryptographic re-authorization.

At-rest, in-use, in-transit

Encrypted at rest with tenant keys. Decrypted only inside TEEs at point of use. Re-encrypted before transit. The plaintext lifetime is microseconds.

Wallets dashboard
Control plane

Poll-only,
never pushed

Internal services don't accept inbound traffic. They pull authenticated work from signed queues. No webhook into a signing node. No RPC into a policy evaluator. No injection surface, because there's no inbound surface.

Authenticated queues

Every message in transit is signed by its producer and verified by its consumer. Replay-protected, ordering-preserved, tamper-evident.

One-way data flow

Requests flow forward. Acknowledgements flow back signed. Control flow doesn't loop, doesn't fork, doesn't admit out-of-band input.

No lateral RPC

Services don't call each other ad hoc. The graph is fixed, the topology is attested, the message paths are pre-declared. Surprise calls don't reach production.

Wallets dashboard
End-to-end proof

From API edge to signature,
cryptographically continuous

User Action Signing at the edge. TEE attestation in every hop. Tenant-isolated storage in every read. MPC signature at the core. Every link in the chain produces a verifiable receipt. The audit isn't reconstructed — it's recorded.

User Action Signing

Every sensitive action is signed by the end user's passkey before it enters the platform. The chain of custody starts at the device, not the API.

Receipt per hop

Every service that touches the request signs its handoff. Auditors replay the chain. Mismatches surface in seconds, not in post-mortems.

Non-repudiation by construction

Operators can't forge a request. Services can't impersonate each other. Tenants can't read each other's state. Not by policy — by cryptography.

Wallets dashboard

Discover why ABN AMRO backs DFNS.

“We believe that securing private keys, and therefore custody of digital assets, is a strategic capability for the future of financial institutions. Having worked closely with Dfns and their team, we are excited to be a part of their future as well.”

TEE certs on every hop

Every service signs every response with a hardware-bound TEE certificate. Verified by the next service. No trust assumed between components.

Database isolation by cryptography

Per-tenant, per-service encryption keys derived inside TEEs. No service reads what it isn't entitled to. No operator reads anything at all.

Poll-only data flows

Internal services pull from authenticated queues. No push, no injection paths, no man-in-the-middle. The data plane has one direction.

Beyond verifiable cloud

Most attestation stops at “the enclave ran trusted code.” Ours covers the request, the routing, the storage, and the signature. End-to-end, not enclave-deep.

Edwin van Bommel Chief Strategy & Innovation Officer, ABN AMRO

Four layers of cryptographic continuity

Every request crosses four boundaries before it becomes a signature. Each boundary is attested. Each boundary is verifiable. Each boundary holds independently.

The chain of custody starts at the device.

User Action Signing binds every sensitive request to a passkey signature on the end user's hardware. The request that reaches the API isn't trusted because it came over TLS — it's trusted because the device cryptographically signed the intent.

// 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 intent
Treat User Action Signing as the foundation. Without it, attestation is internal-only. With it, the cryptographic chain extends all the way to the end user's fingerprint or face.

Every service proves what it is, before it speaks.

Every microservice in the path runs in an AWS Nitro enclave. Each one carries a hardware-bound certificate, refreshed on schedule, anchored to its measured boot state. Services that can't prove what they are can't participate.

# 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 quarantined
Audit the attestation chain. The Dfns whitepaper publishes the pinned manifests. Verify the running services match what's published. Trust, then verify — independently.

Read only what your certificate entitles you to.

Tenant data is encrypted with per-tenant keys derived inside enclaves. Services receive scoped read capabilities tied to their attestation. Operators see ciphertext. Services see only the rows their identity unlocks.

-- 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.
});
Treat database isolation as a hard boundary, not a soft one. The platform enforces it cryptographically. Your auditors can verify it without trusting Dfns by reading the encrypted data directly.

Pull the work. Sign under MPC. Emit the receipt.

Signing nodes don't accept inbound traffic. They poll the authenticated queue, verify the attestation chain on the pending request, run MPC across enclaves, emit the signature, and produce a per-hop receipt the auditor can replay.

// Conceptual: the signing node's loop. No inbound RPC, only pull.
while (true) {
  const next = await queue.pull({ scope: "signing", attestation: currentAttestation });
  if (!next) { await sleep(POLL_INTERVAL); continue; }

  // 1. Verify the full chain of custody up to this point
  if (!verifyChain(next.receipts, pinnedManifests)) {
    return quarantine(next, "Chain of custody broken");
  }

  // 2. MPC signing across enclaves. No single node holds the key.
  const signature = await mpc.sign({
    threshold: 3, total: 5,
    payload: next.payload,
    attestation: currentAttestation
  });

  // 3. Emit signature + receipt. The receipt is the audit.
  await emitSignature(signature);
  await emitReceipt({ stage: "signed", attestation, signature, payload: next.payload });
}
Verify a receipt chain end-to-end. Pick any transaction in your activity log. Walk the receipts from edge to signature. Every hop signed, every signature verifiable. That's what end-to-end integrity looks like in practice.
Settings → Credentials → Active Passkeys → Verify
Settings → Credentials → Active Passkeys → Verify
Security → Attestation → Service Inventory → Live Manifests
Security → Attestation → Service Inventory → Live Manifests
Security → Data Plane → Tenant Key Status → Audit Reads
Security → Data Plane → Tenant Key Status → Audit Reads
Activity → Request ID → Receipt Chain → Verify End-to-End
Activity → Request ID → Receipt Chain → Verify End-to-End

Ready to verify, not trust?

End-to-end attestation. TEE certs, isolated data, poll-only flows. The integrity guarantee that doesn't stop at the enclave wall.

Documentation

Explore our tools and APIs.

Read the whitepaper

The full integrity architecture.

Pricing

Transparent and predictable.

Contact sales

Design your deployment.

Contact us