SettleMint
ConceptsCompliance & identity

Transfer-Path Compliance

Transfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.

Both failures land in the same place: nothing moved.A transfer or mint request reaches the token. The token first checks whether the recipient passes the identity registry checks; if not, the transaction reverts. If that passes, the token evaluates every configured rule, and any single failure also reverts. Both failures end in the same state: no balances change. A generic rejection may require simulation to identify the blocker. Only when the identity check and every rule pass do balances update and rule state record the movement. Nothing partially settles: the movement happens whole, or it does not happen.Both failures land in the same place: nothing moved.The same figure as the desktop variant, drawn portrait for phone widths: the request runs through two gates, identity then rules, and a failure at either gate turns right into the same reverted state while a pass at both gates continues down to balances update.

Ordinary transfers must pass identity and compliance checks. A failed check reverts the transaction and its balance changes.

Ordinary transfers and mints run the asset's applicable checks before balances change, and a failing rule reverts the movement. Tokens created through the current System Factory inherit global controls alongside their own modules, and recipient bypasses and recovery paths require separate review.

Eligibility depends on on-chain claims and configured rules. An off-chain decision affects transfers after the corresponding claim or policy update reaches the chain.

A read-only pre-check reports current blockers before signing. A clear result does not reserve eligibility or guarantee later execution.

Why transfer-path compliance matters

For an institution issuing regulated assets, transfer-path compliance means the securities rulebook travels with the asset: who may hold it, in which jurisdiction, up to what cap, under what lock-up. The token enforces applicable rules inside ordinary transfers and mints, including calls made outside the Platform API.

Transfer-path compliance runs on every ordinary transfer and mint across the whole asset lifecycle. The same eligibility registry that decides who may receive the first minted unit checks a transfer in year three and a redemption payment at maturity.

On-chain checks enforce the recorded policy. They do not establish that the policy is legally sufficient or that off-chain evidence is current.

Your existing compliance providers keep their role. An accredited know-your-customer (KYC) or anti-money-laundering (AML) provider becomes an on-chain issuer: its passed check grants a holder eligibility, and its sanctions hit revokes it. The platform enforces the rules you configure; the legal policy, the provider relationships, and the decision to change a rule stay with your organisation.

Running compliance day to day

Choose the rules each asset enforces and keep holder eligibility current. A country allow list, investor-count cap, or minimum holding can each block a transfer for a different reason. The platform applies whatever configuration exists when value moves, so rule changes and identity updates are live transfer controls, not paperwork.

You configure rules per asset under its governance role, either picking modules one at a time or applying a policy template, a named, versioned package of preconfigured modules you reuse across issuances. Reach for a template once you repeat the same rule set; a one-off asset with a bespoke mix costs less to hand-pick than to version. A rule that must hold everywhere, such as a sanctions block list, a compliance manager installs once as a global control that every bound token inherits at once, marked as inherited in that token's compliance view. A new global control governs future movements only, never balances that already settled.

Eligibility work is claims work: you review a participant's evidence off-chain, or a connected provider sends its verdict, and a trusted issuer records the result as a claim on the participant's on-chain identity. Revoking the claim withdraws eligibility the same way.

Two feeds govern ordinary movements.The eligibility feed carries off-chain review to a trusted issuer, who issues or revokes a claim on the holder's identity. The rule feed carries the asset's policy, a template or hand-picked rules, into the rules configured on the asset. Both feeds converge at the next transfer or mint attempt: when in-scope rules pass the movement executes, and when a rule fails the movement is blocked and simulation can help identify the blocker.Two feeds govern ordinary movements.The same figure as the desktop variant, stacked for phone widths: the eligibility feed and the rule feed each resolve to a state, both feed the next transfer or mint attempt, and that attempt either executes or is blocked with the failing rule named.

Two inputs govern an ordinary movement: the rules configured on the asset, and the claims recorded on each holder's identity. The next transfer or mint passes only when both agree.

When a transfer keeps failing, the pre-check console explains why: enter the sender, recipient, and amount, and it runs that exact transfer against the live rules without signing anything. The result lists detected blockers and who can resolve them, such as a holder with a missing claim or an operator managing a freeze. A stale price requires a fresh feed update. The result describes current state; execution can encounter later changes. Fix the blocker, re-check, then submit the real transfer.

How it works and where the boundaries sit

Transfer-path compliance runs as a check inside the token's own state-update path. Every way of moving the token, a direct transfer, an allowance-based transfer, or a batch item, ends in the same hook, so enforcement does not depend on which door the movement came through. The token standard extends ERC-3643, an open standard for permissioned security tokens.

An ordinary transfer first checks the recipient's identity eligibility. The compliance engine then checks the recipient bypass list. A bypassed recipient skips both module layers. Otherwise, active modules evaluate the movement in scope and the token engine delegates to the global engine. A failing check reverts the transaction; a generic rejection may require simulation to identify the blocker.

One engine reads two layers from one catalog.The token's compliance engine evaluates on every movement on the transfer path. It reads the platform's module catalog of registered control types, which feeds two layers: the rules installed on this token, and the global controls installed once at the platform level. Every rule passing lets the transfer proceed; the first failure reverts it.One engine reads two layers from one catalog.The same figure as the desktop variant, stacked for phone widths: the transfer path reaches the compliance engine, the engine reads the module catalog, and the catalog feeds both layers directly, rules installed on the token and global controls, each of which feeds forward to every movement, where every rule passing lets the transfer proceed while one failure reverts it.

One catalog supplies control types for token modules and global controls. Ordinary transfers evaluate the applicable modules in both layers unless the recipient is on the compliance bypass list.

Modules are typed and instanced. A control type must exist in the platform catalog before an engine can install it. Installing it deploys a fresh instance, so the same type can run more than once with different parameters. Each instance can limit its checks by sender, receiver, or country. Global rules can also select tokens by scope. The compliance manager sets a global rule's scope; the token cannot change that selection.

After a successful movement, stateful rules update their records in the same transaction: holder counts, issuance windows, consumed approvals, lock batches. A failed update reverts the whole transfer, so rule state and balances never diverge. A small set of paths move value without evaluating those rules; Controls and evidence lists each one with what it still requires.

The integration contract

The API surfaces transfer-path compliance as three parts: configuration, simulation, and a failure contract. You install, configure, scope, disable, or remove compliance modules on a token or at the system level, and group modules into compliance templates you apply at asset creation.

Before submitting a transfer, simulate it. The transfer-simulate endpoint takes the sender, recipient, and amount and runs the same on-chain compliance check the transfer itself would run. It returns a verdict, will clear or will revert, and on a revert a blocker list: the rule that fails, which party it applies to, the reason class, and who can remediate it. The endpoint signs and changes nothing, so call it as part of a pre-trade workflow.

Simulate first, then submit.The integrator first asks to simulate a transfer with the sender, recipient, and amount; the token answers with a clear verdict or the rules that block it, and the verdict returns to the integrator. Once ready, the integrator submits the real transfer under the same rules; the token executes it, or reverts it and names the failing rule, and the result settles on chain either way.Simulate first, then submit.The same figure as the desktop variant, stacked for phone widths: simulate resolves to a verdict, and once the integrator is ready, submit runs the real transfer under the same rules and settles on chain either way.

Simulate before submission to inspect current blockers. The real transfer checks the state at execution and can fail after a clear simulation.

DALP-1096 reports a rejected transfer and DALP-1110 a rejected mint. Neither code alone identifies the failing layer; inspect the simulation result and current policy. DALP-1111 identifies a stale-price blocker that needs a fresh feed update. Recheck after remediation. If a write was already accepted, read its outcome before deciding whether to retry the existing request or start a new attempt.

Enforcement lives in the token contract, not the API. A movement submitted through any client or a direct on-chain call passes the same checks, and no API path can waive them.

Controls and evidence

Transfer-path compliance is preventive for the movements within its scope. A failed check reverts that transaction's balance changes. Governance must account for bypassed recipients, recovery paths, and policies that do not encode every legal requirement.

Enforcement reads on-chain state at execution time: a revoked claim or a new block-list entry binds at the next movement that needs it. The lag between an off-chain decision and the matching on-chain claim update is your operating responsibility; the platform enforces only what your process has already recorded.

You can read the evidence without reconstructing it. Each token shows its own modules plus the inherited global controls, marked as inherited, and one platform-level page shows the global policy. Each identity carries its claim history, with issuers, and simulation can identify the current transfer blockers. Keep personal evidence off-chain. Claim fields and identifiers are public, so review their contents before issuance. A claim records an issuer's attestation, and withdrawing trust in that issuer stops its claims from counting at the next movement, without touching the claims themselves.

The exception inventory has four entries, each still traceable. A custodian forced transfer skips module evaluation but still checks the recipient's identity eligibility; only the custodian role can run it, and the chain records it as a custodian operation. Wallet recovery does the same for a different actor. Once the identity registry has recorded a wallet as lost and named its replacement, that replacement wallet, not a custodian, moves the lost wallet's balance under the same identity requirement. A current registry verifies claims; an older registry can fall back to registration. The platform's own settlement and vault contracts may receive assets without rule evaluation, but ordinary transfers leaving them for a non-bypassed recipient pass the applicable checks. A burn skips eligibility checks because no one receives anything; supply-tracking rules record it after the fact.

Frequently asked questions

What happens when a holder loses eligibility after acquiring tokens?

The held balance stays where it is; enforcement applies to movements, not to holdings. Once an issuer revokes a claim, the holder cannot receive more of any asset that requires it, and sender-scoped rules bind their outgoing transfers too. Freezing or moving the balance itself is a governed custodian decision, not an automatic consequence.

Can anyone get around the rules?

The configured bypass and recovery paths skip module evaluation. Controls and evidence lists all four paths that move value without evaluating a token's rules. Review the authorization and recorded evidence for each path. The one a non-custodian can invoke is wallet recovery, and even that only works once the identity registry has already recorded the original wallet as lost and named the caller as its replacement. Nobody can declare their own recovery. A direct on-chain transfer between two ordinary wallets runs the identical checks as one submitted through the platform.

Does a clear pre-check guarantee the transfer will succeed?

No. The verdict only holds for the instant the simulation runs against live state, not as a lock on that state. Between the read and the signature, an issuer can revoke a claim or a compliance manager can add a global control, and neither one waits for you to sign. Re-run the simulation immediately before submitting, especially after any delay for review, approval, or a wallet's own signing prompt, since that is exactly the gap where eligibility can move.

How is this different from checking compliance in the application before submitting?

An application-side check advises; the token enforces. Because the rules run inside the token contract, they bind every submission path, including ones that never touch your application. Simulation inspects the applicable on-chain checks against current state. A later transfer can see different state or encounter another execution failure.

How do decisions from our KYC provider reach the chain?

Two paths, one result. A connected provider sends its verdict, and the issuer identity the platform provisioned for that provider issues or revokes the matching claim. Or your own reviewers complete the review, and an authorised trusted issuer records the claim manually. Either way, enforcement reads the claim, and the attestation counts only when the registry trusts the issuer for that claim topic.

Who decides which rules an asset enforces?

Your organisation, split by role. Whoever holds the asset's governance role picks and parameterizes its modules, or applies a policy template, at issuance. The compliance manager, a platform-wide role, is the only one who can install or scope a global control. Whoever your policy names as trusted-issuer administrator decides which issuers count for each claim topic. The platform validates and enforces whatever that configuration says; it does not choose the policy or substitute for legal or regulatory judgment.

  • Asset Lifecycle: the whole working life of a regulated tokenized instrument, from issuance through servicing to redemption. Transfer-path compliance runs inside every transfer and mint across that whole life.
  • Participant: the stable on-chain subject that a claim, a role grant, and an audit row all point at. The identity check inside every transfer resolves to one of these.
  • On-Chain Identity: the ledger record of one subject that the token resolves in the identity registry before any rule runs.
  • Compliance Policy: the reviewed policy template and platform-wide global controls that the rules enforced on this page are configured from.
  • Role Grant: the on-chain permission an access manager checks before a privileged call runs. The governance role, compliance manager, and trusted-issuer administrator roles this page names are each one.
  • XvP Settlement: An on-chain exchange in which every leg settles together in one transaction or none settles at all, so no party delivers without receiving what they are owed.

Compliance Policy

A Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.

Role Grant

A role grant turns an institution's segregation-of-duties policy into a check the ledger itself runs before every privileged call.

On this page

Why transfer-path compliance mattersRunning compliance day to dayHow it works and where the boundaries sitThe integration contractControls and evidenceFrequently asked questionsRelated concepts