The Policy Engine has always had one job: decide, before anything signs, whether an action may happen. Until now, that job was scoped to a known list of sensitive activities, transfers, signatures, and changes to permissions, policies, and registries, each wired to the approval flow by hand. Policy Engine 4.0 removes the list. Any action signed on DFNS can now be put behind approval, with one mechanism, and the engine learns two new skills along the way: deciding on compliance data and counting in the asset’s own units.
Any signed action can now require approval
Every sensitive write on DFNS already passes through User Action Signing. The caller signs a per-request challenge with a credential, the platform verifies it, and only then does the request run. 4.0 places the Policy Engine at exactly that point. A new policy kind, UserAction, names an action kind, adding a tag to a wallet and either requires approval for it or blocks it outright. Endpoints are brought under the mechanism incrementally, each with the same small integration, which is why the list of governable actions grows from here rather than being fixed at launch.
The behavior is precise because precision is the point. When a policy triggers, the endpoint holds the request and returns a 202 error message with an activity to review. Nothing is created, changed, or moved until approvers say so. The handler stops before any side effect runs, so there is nothing to undo if the action is denied. When it’s approved, the original action is run for real, once, inside a database transaction that also records the action as done, so a redelivered event can never execute it twice and a transient failure rolls back cleanly and retries. If approvers deny, the action is recorded as blocked and never runs. And while a change to a resource is awaiting approval, a second signed change to the same resource is rejected, so two pending edits can never race each other into an inconsistent state.
When no policy applies, nothing changes. The endpoint behaves exactly as it does today, which is how an organization adopts this. One action kind at a time as its governance requires.
The first endpoint under the mechanism is deliberately simple: “wallet tags.” Tags matter more than they look, because other policies filter on them, so an organization may reasonably want a second person to approve before a wallet becomes “treasury.” That is the shape of what follows. The actions you never thought to gate, governed with the same rigor as a transfer.
This is phase one. A policy currently applies to a whole action kind. Phase two adds a programmable condition layer, so a policy can look inside the request, which tag, which initiator, what amount, and decide accordingly. The mechanism shipping today is the foundation that layer builds on.
Policies for Vaults
Vaults gave wallets a balance sheet with available, quarantined, and locked states. Our latest Policy Engine 4.0 upgrade gives two of those states their own policies.
- Quarantine release, decided on KYT. Funds arriving in a vault are quarantined by default. Releasing them is now a policy-governed action, and the policy evaluation carries the KYT result for the incoming transaction. In the dashboard, an operator reviews an incoming transfer and accepts the funds; if your KYT provider has flagged exposure, the release enters a pending approval with the evaluation attached, the exposure, the source, the detail an approver needs to decide. A transfer from a known exchange gets approved in one signature. A transfer from somewhere else gets a conversation first. The important part is what this enables beyond the dashboard. Because quarantine release is a policy, approvals can be granted by service accounts. Configure the policy so that clean KYT results are approved automatically, and incoming funds release themselves the moment screening clears, with every decision recorded, while anything flagged routes to a human. Straight-through processing for the 99%, human judgment for the 1%.
- Lock creation, under approval. Locking an amount inside a vault, for escrow, collateral, or off-exchange settlement, is now gated by its own policy. A lock request enters pending approval, approvers review the amount and asset, and only on approval does the locked balance change. The vault then shows each lock as a distinct entry, so a balance of seven locked across two commitments reads as two locks, not one number.
Limits in the asset’s own units
Transaction limit policies have expressed thresholds in a reference currency, which works when an asset has a reliable price and breaks when it does not. 4.0 adds a nominal amount limit per asset: a threshold set in the asset’s own units, on a specific network, scoped to the wallets you choose.
The use cases are the ones price feeds handle the worst. Assets without a dependable price index. Highly volatile assets, where a dollar threshold means a different quantity every hour. Treasury wallets where the mandate is written in units, “no more than one ETH without a second signature,” and the policy should say exactly that. Set the limit, choose request approval, define your approval groups and quorum, and any transfer above the threshold enters the approval queue with the policy evaluation attached: the amount, the limit, the asset, the wallet. The approver sees a transfer of 0.025 ETH against a limit of 0.001 and decides.
What 4.0 adds up to
The Policy Engine now governs actions, not just transactions, so the surface a second pair of eyes can cover is the whole platform. It now decides on data, so compliance signals turn into automated outcomes without losing the human path. And it now counts in the terms your mandate is written in. Together, they move the engine from a gate in front of transfers to the approval layer of the organization, which is what a core banking platform’s policy engine should have been all along.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team about Policy Engine: sales@dfns.co
