Governance Engine Sign only what you can prove
Verify user intent and onchain data before anything gets signed.
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 Standard Chartered operates regulated digital asset custody.
SCB operates a regulated digital asset custody serving institutional clients across multiple jurisdictions with DFNS as the core wallet management infrastructure.
DFNS excels in providing a wallet management system that is quick, scalable, and simple to implement, even for lesser-known or pre-launch blockchains. They free us from transaction building, offering scalable, easy-to-implement solutions that simplify our project delivery.
Every critical record is committed to a Merkle tree. Change one row, and the root breaks. Trust fails the moment data changes.
Every sensitive action carries a passkey signature from the user’s device. We cannot forge it, replay it, or change what it authorized.
The Governance Engine validates. A blockchain signer signs. You run both, with nothing to sync and no keys held by us.
The proof is cryptographic, not hardware-bound. Use enclaves if you want them; integrity holds either way.
- 01 · Sign the intent
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.
- 02 · Govern the data
Every 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.
- 03 · Verify before signing
Validate 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.
