An embedded wallet, and signatures your policy accepts
An embedded Dynamic wallet for self-custody, structured signatures that providers can inspect, and DFNS wallets on the network you work on.
DALP 3.2 adds an embedded wallet and fixes the DFNS integration. Smart accounts now sign typed data that a custody provider can inspect before it approves the operation.
One custody choice, more of the platform behind it
Custody is where an organisation decides who holds the keys and whose approval policy runs before a signature is returned. The wider that choice reaches, the fewer places a key sits outside it.
- DFNS
- Wallets on the network you use
- Self-custody
- Embedded wallet built in
- Smart accounts
- Sign typed data
- Balances
- Visible in your vault console
DFNS wallets on the network you use
Two corrections in this release matter if you tried the DFNS integration before upgrading. DFNS wallets were created against mainnet regardless of which network the organisation was actually working on, which meant the integration could not work on a test network at all. And a defect on the broadcast path affected every provider, not just DFNS. Both are fixed. Retry affected test-network and broadcast operations after upgrading.
Signatures a strict policy will approve
The platform's smart accounts, meaning accounts that are code on the chain carrying their own signing rules rather than being a plain private key, produce operations that need signing. Those were being signed as raw data: an opaque hash, with nothing in it the provider could read. A provider policy can reject raw signing because the provider cannot inspect the operation fields.
Those operations now sign as typed structured data, where the fields are legible to the provider before it signs. A workspace whose transaction policy forbids raw signing can now run smart accounts on DALP, where previously it could not. Nothing changes for a workspace that permitted raw signing; the resulting authorisation is the same.
A wallet built into the Console, keys the platform never holds
Some members of an organisation have no wallet at all, and asking them to install one is where a rollout stalls. For them the platform now offers an embedded wallet through Dynamic: a wallet that lives inside the Console session, created when the member first needs it, with nothing to install and no seed phrase to write down. The key never exists in one place: it is split across independent parties that co-operate to sign, so neither DALP nor Dynamic ever holds the whole key, and the member remains the custodian.
Signing in stays exactly as it was. The member logs into the Console once, with their organisation's own login; behind the scenes the platform hands Dynamic a short-lived, signed voucher for that session, and Dynamic verifies it against the platform's published keys. There is no second account, no second password, and the wallet is bound to the same identity the rest of the platform already audits.
This joins Privy and browser wallets on the self-custody side of the provider list, meaning accounts where the member signs personally, as distinct from the vault providers above where the organisation's custodian signs.
External wallets see what they sign
The same legibility this release brings to smart accounts now reaches every personal wallet on the platform. Token spending permits and governance ballots present the full typed structure to the wallet. The confirmation screen shows the relevant spender, amount, deadline, ballot, and chosen option. Members can read what they are approving instead of an opaque value. Identity claims and settlement approvals present a readable message. One case was a straight defect: some wallets add a standard safety prefix when they sign, and the platform's verification did not expect it, so those signatures were rejected. Signing and verification now agree on the same form.
Balances where your treasury already looks
The organisation's wallets and the platform's system wallets register with Fireblocks as read-only internal wallets. Deployed tokens register as workspace assets. Their balances then appear in the Fireblocks console used by the treasury team.
Individual participant wallets are excluded from registration. Registration is best effort. A failure to display a balance never blocks a deployment.
Availability and compatibility
Nothing here breaks an existing integration and no migration is required. An organisation already using a custody provider keeps its configuration untouched.
The provider list an organisation sees still depends on what its deployment offers, and the choice of provider family remains a commitment rather than a setting: once an organisation adopts a provider, later credentials must match the same one.
Compare custody providers → · Understand approval planes → · Configure it in the Console → · Read the 3.1 foundation →
Live activity tray
Every Console operation now reports its progress through named phases in a tray that follows you across pages, survives a refresh, and offers an undo.
Networks & RPC
The platform runs its own connection layer: admins define networks and endpoint pools, traffic leaves a lagging node, and an organisation can use many chains.