Find out before you sign

Transfer precheck reads the token's current verdict before you submit a transfer. It also identifies blocking conditions and who can resolve them.

Check before signingCopy Anchor Link

An asset's rules live in the transfer path: the token checks every configured rule before balances change, and the first rule that fails reverts the whole movement. That design is why a non-compliant transfer cannot settle on this platform, and it is not something to soften.

What it produced, though, was a bad moment. Someone filled in a transfer, approved it, signed it, waited, and then learned it was never going to work. Worse, they often could not tell why, or whether the problem was theirs to fix.

What the answer containsCopy Anchor Link

The pre-check returns the verdict from the token itself, which is the same authority the real transfer consults, so the answer is not a guess assembled from a copy of the rules.

When the answer is that the transfer would not clear, the response includes indexed explanations of blocking conditions, which saves the loop of fixing one blocker and discovering the next. Each is classified by who can act on it:

• Self-serve. The party can resolve it themselves, such as completing a verification that has lapsed.
• Operator. Someone at the issuing institution must act, such as lifting a freeze or adding an entry to a permitted list.
• Structural. The transfer is not going to be made to work in its current shape, such as a destination that the asset's design does not permit.

Use the classification to correct the request, ask an operator to act, or choose a transfer that the asset permits.

Where it shows upCopy Anchor Link

An investor meets it in the confirmation step of a transfer, so the check happens where the decision is made rather than on a separate screen nobody visits.

An operator gets a dedicated pre-check screen for investigating a case on someone's behalf, which answers the support question of why a particular movement will not go through. That screen is available to operators who already hold the permission to act on transfer restrictions, so it grants no new visibility to anyone.

Integrators get the same capability as a read on the versioned API, which fits naturally in front of a transfer in an automated flow.

GET /api/v2/tokens/{tokenAddress}/transfer-simulate

Availability and compatibilityCopy Anchor Link

Available with the upgrade, with no flag to turn on. Nothing changes for an existing integration: the route is additive, the v1 API stays frozen, and the transfer path itself is untouched.

Two things this does not change, and both matter to a reviewer.

The enforcement point does not move. The rules are enforced inside the token's own transfer, on the chain, and they run whether or not anybody consulted the pre-check first. Skipping the check does not skip the rules, and neither does submitting straight to the chain without going through the platform: the transfer reverts either way. The pre-check adds foresight, not permission.

And a pass is advice rather than a reservation. Eligibility is on-chain state that can move between the check and the transfer, so a passing check followed by a revoked verification still reverts. Treat a pass as the answer to "is this blocked right now", not as a promise about a transfer submitted later.

Understand transfer-path compliance → · Configure the rules → · Transfer from the Console →