An embedded wallet, and signing requests your policy can read, Ripple included

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, so a provider workspace whose policy rejects typed data must accept it before you upgrade. If you run Ripple custody, update your Ripple policies before you upgrade. Version 3.2 changes operation names that DALP sends on its Ripple intents, the requests that DALP files with Ripple for approval. It also adds a mark for role changes that DALP cannot list in full, which needs a top-ranked policy of its own.

Custody & Settlement

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 Fireblocks console

DFNS wallets on the network you useCopy Anchor Link

One correction in this release matters 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. This is fixed. Retry affected test-network operations after upgrading.

Signatures a strict policy will approveCopy Anchor Link

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 provider workspace whose transaction policy forbids raw signing can now run smart accounts on DALP, where previously it could not. A workspace that permits raw signing gets the same authorisation as before, as long as its policy also accepts typed data.

Ripple policies can match the operation and its rolesCopy Anchor Link

If you run Ripple custody, your Ripple policies decide who must approve each intent that DALP files with Ripple. DALP adds custom properties to every intent, so you can send a role grant to a stricter workflow than a token mint, or write a policy for one network or one contract. Ripple matches a value exactly with is, or matches text inside it with contains, and can combine conditions with AND and OR, as its policy reference describes. 3.1 already sent every property in this table except dalpRolesUndescribed, and the values that changed are under Availability and compatibility.

DALP limits each property value to 100 characters. When the role list is longer, DALP sends the leading role names that fit, adds +N for the N roles it left out, and sets dalpRolesUndescribed to true. A grant of twelve roles on the platform's access manager contract, for example, can send admin,auditor,systemManager,tokenManager,complianceManager,claimPolicyManager,claimIssuer,+5.

DALP also sets dalpRolesUndescribed to true, with no dalpRoles, when it cannot name every role, or when the roles are not all on one contract:

• A role ID that DALP does not know.
• A batch that changes roles and also calls another contract.
• A call that passes a role change on to another contract to run.
• A wrapper call, a call that carries other calls inside it, that DALP cannot unpack, even one that changes no role.

DALP reads roles only from calls to functions that it knows. A call to a function that DALP does not know adds no name to dalpRoles and does not set dalpRolesUndescribed, even when it changes a role, so that intent gets the policy that its other properties match.

Add a dalpRolesUndescribed policy and rank it above your role policies, because Ripple runs only one policy for each intent.

Among the policies that apply to an intent and whose condition matches, Ripple runs the one with the highest rank, or the older one at equal rank. An intent that no policy matches cannot run. Add one policy that matches dalpRolesUndescribed is true, applies to every intent type, intent origin and domain that your role policies apply to, and uses your strictest workflow for role changes. DALP signs each intent that it files, so Ripple treats it as a user-signed proposal: a policy that omits the intent origin matches it, and a policy for system-signed proposals only does not. Give it a higher rank than every policy that a role change can also match. Keep it in the domain of your role policies or in a parent domain: under Ripple's CoerceDescendants governing strategy, a parent policy overrides a child policy whatever its rank. A request with dalpRolesUndescribed set then gets that workflow, never a looser one that matched only the names that fit.

Role changes reach Ripple as transaction orders and as manifests, so apply each role policy to both intent types. To match a single role, use contains, because is on dalpRoles matches only the complete list. Before you use contains, check that no longer role name includes the same text.

One request can change more than one role, and Ripple still runs only one policy. Rank your role policies by how strict their workflows are, with the strictest highest, and above any other policy that a role change can also match, such as a policy on dalpKind. A grant of auditor and admin together then gets the stricter admin workflow. Never give two role policies with different workflows the same rank, because at equal rank Ripple runs the older policy.

A wallet built into the Console, keys the platform never holdsCopy Anchor Link

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. The member has no second account and no second password. The platform binds the wallet to the same identity it audits everywhere else.

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 signCopy Anchor Link

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 looksCopy Anchor Link

The organisation's wallets and the platform's system wallets, the wallets that the platform itself operates, 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 compatibilityCopy Anchor Link

If you run Ripple custody, check your Ripple policies before you upgrade, because the dalpKind values in this table changed after 3.1. A policy whose condition names an old value stops matching. Its intents then go to the next policy that matches, or cannot run when no policy matches.

Token mint, burn, transfer and forced transfer keep their 3.1 values: token.mint, token.burn, token.transfer and token.forcedTransfer. Because a user operation sent no dalpKind in 3.1, a 3.1 policy on an operation, such as token.mint, now also matches that operation when a smart account runs it. The trading venue is new in 3.2 and sends txqueue.enqueue. The table names each kind of change with examples. It does not yet pair these 3.1 values with their 3.2 names:

• The contract. values of token feature writes, and the token.feature values that end in Create or Attach, such as token.featureAumFeeCreate.
• token.approve, token.delegateBySig and the token.transfer-approval. values.
• smart-wallet.install-module, smart-wallet.uninstall-module and smart-wallet.set-threshold.
• identity-recovery.identity-create, invitation.identity-attach.register-pending, and the system.identity-create. and system.identity-delete.paired. values.
• system.grant-role-by-participant, system.revoke-role-by-participant, compliance.provider-webhook-reactivate, compliance.provider-webhook-revoke and addon.fixedYieldSchedule.claim.
• The paymaster.set-signer-rollback. values, refundSplitter.recoverErc20 and refundSplitter.setSponsorship.

Before you upgrade, run the operations that your policies cover on a 3.2 test deployment, and compare the dalpKind that Ripple shows with each policy condition. Until the upgrade is done, match both the 3.1 and the 3.2 value with an OR condition, so that an intent from either version finds its policy. Where 3.2 sends one value for more than one operation, such as txqueue.enqueue, add a dalpContract condition, so that each policy still matches only its own contracts. Then check each policy against the property list, and add the dalpRolesUndescribed policy.

On any custody provider, a workspace policy that permits raw signing but rejects typed data must accept typed data before you upgrade, because smart accounts now sign typed data.

An organisation keeps its custody configuration through the upgrade. The provider list an organisation sees still depends on what its deployment offers. The choice of provider family, such as Fireblocks, DFNS or Ripple, 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 →