Skip to main content

EVM Contract Set

The EVM Contract Set is the identity, compliance, custody, and settlement contracts DALP deploys around one composable security token, checked in one call.
Every ordinary transfer passes one compliance gate before any balance changes.A transfer request carries a sender, a receiver, and an amount. Before any balance changes, the request passes a compliance gate inside the same transaction: the receiver's identity is verified, the instrument's own compliance rules are checked, then the platform-wide rules that apply to every instrument. If every check clears, the balance updates and the transfer is recorded on the ledger. If any check fails, the transaction reverts and no balance changes. A mint takes the same path. A burn has no receiver to check, but a frozen sender or a Token Feature rule can still block it. A registered fee feature can split a transfer, a mint, or a burn into a net leg and a fee leg, so the amount credited is not always the amount submitted. Custodian powers such as freeze, forced transfer, and recovery skip the ordinary compliance and freeze checks, but a forced transfer's receiver must still pass the identity check.Every transfer, one pathTransfer requestfrom → toamount and assetthis instrumentA mint takes thissame path. A burnhas no receiver check,but can still revert(fee features may split it)Compliance gateinside the same transactionIdentity verifiedmay hold this assetInstrument’s own ruleschecked per tokenPlatform-wide ruleschecked for every assetAll three must clearbefore value movesBalanceupdatedPassesrecorded on ledgerRevertedFailsno balance changesCustodian powers (freeze, forced transfer, recovery) skip the rule checks.A forced transfer’s receiver must still pass the identity check.Every ordinary transfer passes one compliance gate before any balance changes.The same figure as the desktop variant, drawn portrait for phone widths. A transfer request flows down into the compliance gate, where identity, the instrument's own rules, and the platform-wide rules are checked inside the same transaction. The outcome is one of two: balance updated and recorded on the ledger, or reverted with no balance changes at all. A mint takes the same path. A burn has no receiver to check, but a frozen sender or a Token Feature rule can still block it, and a registered fee feature can split any of these into a net leg and a fee leg. Custodian powers such as freeze, forced transfer, and recovery skip the ordinary compliance checks and the sender's freeze, but a forced transfer's receiver must still pass the identity check and must not be frozen.Every transfer, one pathTransfer request: from → toamount and asset, this instrumentCompliance gateinside the same transactionIdentity verifiedmay hold this assetInstrument’s own ruleschecked per tokenPlatform-wide ruleschecked for every assetBalanceupdatedPassesRevertedFailsno balance changesA mint follows this path. A burn skipsreceiver checks, but a frozen sender orfeature rule can still block it. Feefeatures may split any of these. Custodianpowers skip ordinary checks. A forcedtransfer still checks receiver identity.

Identity, this instrument's own rules, and the platform's own rules all clear inside the same transaction that changes the balance, or none of it happens.

  • One generic, standards-based token contract carries every instrument issued on the network.

  • Every ordinary transfer checks identity and compliance inside the same transaction that moves value. A recipient on the platform's own bypass list skips the rules that judge the recipient. A failed check reverts before any balance changes.

  • A single custodian role can freeze an address, force a transfer, or recover a lost wallet's tokens without a second signer's on-chain consent.

Custody calls use one role, and the signing account adds approval

The EVM (Ethereum Virtual Machine) Contract Set is the on-chain half of the platform on EVM chains: one Composable Token configured per instrument, meaning one regulated contract deployed per issued asset rather than a different contract per product type. It does not ask a second party to co-sign a transfer, a freeze, or most recoveries. Use a custody approval policy or a weighted Smart Wallet when a privileged call needs more than one approver. It builds on published standards: ERC-3643 for identity-gated transfers and ERC-20 as the base fungible interface. Coverage depends on the instrument terms a configuration carries.

The contract checks compliance before the balance changes, and no off-chain system is trusted to apply it. An ordinary transfer that would violate compliance never settles, so nothing is unwound later. The bypass list and the custodian role are the recorded exceptions.

Custody power concentrates freezing and forced transfer in one custodian role, and the contract asks for nothing more than that role to exercise them. Recovering a lost wallet has two paths instead of one: the identity registry's named replacement wallet can claim the balance itself once the registry flags the original wallet lost, or the custodian role can force the same recovery directly. Institutions pair the custodian role, and who the registry may name as a replacement, with their own authorisation policy before granting either (see Custody Approval).

Single signing key

An address that holds the custodian role can authorise a privileged call. Separate role assignments do not require two signatures on that call.

Weighted Smart Wallet

A Smart Wallet can hold the custodian role and require a configured signature threshold. Check its installed validators: another validator can provide an additional authorisation path.

A failed compliance check reverts the transfer

A transfer that fails compliance reverts during execution, inside the same transaction that would have moved the balance. No separate remediation queue exists to run afterward: the sender sees the failed transaction, and no balance anywhere has moved. Resubmitting the same request fails again. Fix the eligibility, scope, limit, or approval condition the failing module flagged, or get the receiver registered and cleared in the identity registry if that check failed. Compliance Policy covers how to find which tier, this instrument's own rules or the platform-wide floor, rejected the movement.

The EVM Contract Set deploys one token per instrument. Issuing starts with an Instrument Template, and no new contract is requested: the template supplies the facts, features, and compliance choice, and deployment produces one configured token that already carries identity and compliance enforcement.

Servicing steps follow the same pattern. Freezing an address, freezing part of a balance, and forcing a transfer are each a single call from whoever holds the custodian role for that asset. Recovering a lost wallet's tokens can be that same call, or a direct call from the registry-named replacement wallet instead. None of them waits on a second signer at the contract level. Freeze the whole address when the wallet itself is the concern: a full freeze blocks both directions, so it can neither send nor receive, and a mint to it reverts too. Freeze part of the balance instead when only a specific amount needs to hold: a partial freeze locks that amount while the holder keeps receiving and keeps spending whatever sits above it.

Trades between counterparties settle through a dedicated escrow contract rather than the token contract itself. Local-only execution is atomic, and hashlock-committed settlements can defer blocked deliveries. See XvP Settlement for local atomic execution, external coordination, and deferred deliveries.

The compliance check runs inside the same step that moves the balance

The low-level operation that changes a balance is the same operation that runs the compliance check, so an ordinary transfer or mint cannot settle without that operation running. Two deliberate exceptions break that pattern: the platform's own bypass list, and the custodian role's privileged powers.

The EVM Contract Set combines identity, compliance, features, and custody around the token. First, an identity registry with trusted issuers decides who may hold the asset at all, as Onchain Identity describes. The Composable Token itself carries identity checks, roles, and metadata. Second, a compliance layer evaluates every ordinary transfer or mint twice. It checks this instrument's own compliance modules first, small rule contracts plugged into the token that each test one condition such as eligibility or a holding limit. Then it checks a platform-wide set of the same kind of module that applies across every instrument on the deployment. Third, Token Features can approve or refuse an operation before it runs, and when one rewrites an operation it can split it into several legs. A fee feature, for example, turns one transfer into a net leg plus a fee leg rather than moving the requested amount whole. Fourth, a custody layer sits alongside, with its own privileged bypass.

Put a rule at the instrument tier when it belongs to this issuance's own terms, such as an eligibility test or a holding limit unique to the offering. Put it at the platform tier when it has to hold for every instrument regardless of terms. Compliance Policy names which rules belong at which tier, and Transfer-Path Compliance describes the general mechanism this contract set implements.

Two conditions change how the ordinary compliance rules run. Compliance keeps its own bypass list, separate from the instrument's own modules and the platform-wide set. The platform manages it: the token and add-on factories add the contracts they deploy, and no Console screen or Platform API route edits the list directly. A recipient on that list skips only the rules that judge the recipient: country and identity lists, identity verification, claim expiry, holder counts and transfer approval. Sender-side, lock-up, minimum-holding and supply rules still run in both tiers. Compliance contracts still on the earlier version skip every rule for a bypassed recipient. A paused token works the other way: every ordinary transfer, mint, and burn fails outright before compliance runs at all. Wait for the emergency role that paused the token to lift the pause.

Minting passes through the identical gate as an ordinary transfer, with its own revert reason. Burning is different: it has no destination address for identity or the ordinary compliance modules to check, so those two checks do not run. A burn still runs through the custody layer, so a burn from a fully frozen address reverts, whether the holder redeems or the Supply management role burns. It still runs through Token Features too, so a feature such as a conversion lock can refuse a burn on the same terms it would refuse a transfer.

The custodian role's privileged powers skip the ordinary compliance checks and the sender's freeze, since a freeze or a forced transfer is itself the enforcement step. The receiving wallet's identity check still runs, so even a forced transfer cannot deliver tokens to a wallet the identity registry has not verified. A forced transfer also refuses a receiving address that is frozen. A current registry checks the required claims, and older registries can fall back to registration. The ledger records the write: a forced transfer records as a transfer, with the custodian's step recorded as its own on-chain event. Recovering a lost wallet is the one custodial power with a second path. The identity registry's named replacement wallet can claim the balance itself once the registry flags the original wallet lost, with no role check at all, or the custodian role can force the same recovery directly. Custody functions are gated by a single role check made by the platform's access manager, the per-token contract that records role assignments and answers whether a caller holds one.

One role authorises every custodial lever.A single custodian role authorises four privileged powers on this ledger. Freezing an address blocks sending and receiving. Freezing part of a balance leaves the rest spendable. Forcing a transfer skips the compliance rules and the sender's freeze, while the receiver's identity check and freeze still apply. Recovering a lost wallet moves freeze state to the replacement wallet. The custodian role can force that recovery, or the registry-named replacement wallet can claim it directly with no role check at all. Freezing an address, freezing part of a balance, and forcing a transfer are each a single on-chain call from whoever holds that role. None requires a second party to co-sign at the contract level.Custodian roleOne roleone on-chain checkFreeze an addressblocks send and receiveFreeze part of a balancethe rest stays spendableForce a transferskips rules and sender freezereceiver identity, freeze checkedRecover a lost walletfreeze state moves with itor wallet self-claims, no roleOne role authorises every custodial lever.The same figure as the desktop variant, drawn portrait for phone widths, with a spine connecting the custodian role at the top to all four levers stacked below it. Freezing an address blocks sending and receiving. Freezing part of a balance leaves the rest spendable. Forcing a transfer skips the compliance rules and the sender's freeze, while the receiver's identity check and freeze still apply. Recovering a lost wallet moves freeze state to the replacement wallet. The custodian role can force that recovery, or the registry-named replacement wallet can claim it directly with no role check at all. Freezing an address, freezing part of a balance, and forcing a transfer are each a single on-chain call from whoever holds that role. None requires a second party to co-sign at the contract level.Custodian roleOne roleone on-chain check, four leversFreeze an addressblocks send and receiveFreeze part of a balancethe rest stays spendableForce a transferskips rules and sender freezereceiver identity, freeze checkedRecover a lost walletfreeze state moves with itor wallet self-claims, no role

Freezing, partial freezing and forced transfer share one role check, and recovery adds a second path through the registry-named replacement wallet.

Read the outcome of a submitted transaction

A simulation or preflight can reject a blocked transfer before submission. A transaction can also revert during on-chain execution after the Platform API has accepted the request. Follow the accepted request's status until its outcome is recorded. The contract error reference names every reason along with what it takes to clear each one. A burn skips recipient eligibility checks, but a feature or a stateful compliance hook can still revert it. Read the failure details and resolve the cause before starting another attempt.

A wallet can submit these transactions directly, or through ERC-4337 account-abstraction infrastructure when an integration wants sponsored or batched submission. That infrastructure is a separate layer from the contract set itself.

Custody operations are ordinary contract calls gated by a role check, with no additional signature payload from a second party required at the call level. Multi-party settlement integrates through the settlement contract's own interface, not through the token contract. See XvP Settlement.

The control and the transaction are one object, so nothing settles then reverses

Every ordinary transfer is checked twice inside one transaction: this instrument's own compliance modules, then a platform-wide set of rules evaluated the same way for every instrument on the deployment. A failing check reverts before any balance changes, so a non-compliant transfer is never settled and then reversed. The platform's own bypass list is the one address-level exception: it lifts the rules that judge a recipient, and the chain records every change to the list with the account that called the compliance contract, which is the factory for an address it adds or removes and the calling account for a direct call.

Custody enforcement on the network is single-role authorised: the contract itself asks for one role check, not a second party's on-chain consent, for freezing, forced transfer, and recovery. Controls that require multi-party sign-off for those steps live in the platform's own operating policy around who may hold that role, as Custody Approval describes, not in the contract's own logic.

On-chain events and receipts record contract execution. Keep the platform audit trail and approval evidence as well: the chain alone does not identify every human decision behind a signing account.

Frequently asked questions

Can an address escape compliance checks entirely?

Only partly on current contracts, and only through the platform's own bypass list. Once an address is on the list, a transfer or mint into it skips the rules that judge the recipient in both the instrument's own rules and the platform-wide floor. The other rules still run, and compliance contracts still on the earlier version skip every rule. Removing the address from the list restores every check. The platform manages the list: the token and add-on factories add the contracts they deploy, and no Console screen or Platform API route edits it directly. A System manager can change the list by registering a custom token factory or add-on, or by pointing a registered one at new code, because every registered factory and add-on can add and remove addresses. A Compliance manager can change it with a direct call to the system compliance contract.

What happens to a transfer while the token is paused?

It reverts, and so does every mint or burn submitted while the pause holds. Pausing is an emergency-role step that stops the whole asset at once, ahead of the compliance check rather than as one, so nothing settles and nothing is left half-applied.

Can a forced transfer move tokens that are frozen?

Yes. When the amount exceeds the sender's unfrozen balance, the contract unfreezes exactly the shortfall and moves the tokens, recording that unfreeze as its own on-chain event. A full address freeze on the sender does not stop the call either. Three limits hold. The receiving wallet must still pass the identity check, its address must not be frozen, and the destination cannot be the zero address, so a forced transfer can never destroy supply.

What happens to a freeze when a lost wallet is recovered?

The freeze moves with the tokens. Recovery transfers the lost wallet's whole balance to its replacement and migrates both the partially frozen amount and any full-address freeze, so reporting a wallet as lost does not clear a freeze. A freeze already sitting on the replacement wallet also stays until a custodian explicitly lifts it. Recovery itself only runs after the identity registry has flagged the wallet lost and named its replacement.

Does the platform still support the older asset-specific contracts?

New issuance uses the composable contract model. Older per-type contracts are deprecated for creation. Existing deployments still require servicing and a planned upgrade path. Instrument Templates supply terms for new configured tokens. See Composable Token for the model that replaced them.

Was this page helpful?