Tokenized Assets
Check token transfers, issuer permissions and trading liquidity before adding custody or a swap route.
Add the asset and its trading route separately#
First review the token's units, transfers and custody behavior, then use supported-token registration to admit it to the Pool. To trade it, also register an adapter route. A token can be transferable even when there is no market the adapter can use.
The source has no admitted tokenized-stock route. The stock integration document contains the onboarding process and a historical venue screen. Use this guide to prepare an addition; a named equity needs token admission, an executable venue and a route release before the app can offer deposits or trades.
Check the unit that will become a note#
Record chain, address, runtime, decimals, supply behavior and proxy/upgrade authority. Test rebasing, transfer fees, blacklists, issuer allowlists and registry restrictions. The ordinary adapters require fixed balances and full-amount transfers. An ERC-20-shaped interface and a familiar ticker do not answer those questions.
If a wrapper gives fixed shares over a rebasing asset, review both contracts. Check who can wrap or unwrap, which versions holders can still use, and whether the Pool, adapter and withdrawal recipient can hold it. Issuer freezes, redemption eligibility, underlying custody and corporate actions still affect the token inside a private note.
| Part of the integration | Questions to answer |
|---|---|
| Fungible units | Do balances rebase? Do transfers arrive in full? What are the decimals? |
| Issuer controls | Who can freeze, upgrade or restrict transfers? |
| Wrapper | Which version is transferable, and who can unwrap it? |
| Receiver rules | Can the Pool, adapter and destination receive the token? |
| Backing and redemption | Who can redeem it, and under what conditions? |
| Route liquidity | Can the configured amount trade in both directions now? |
Check an executable quote in each direction#
For an AMM, check factory, pool, tokens, fee, runtime and available liquidity. Quote bounded input sizes in both directions. A pool with no in-range liquidity can exist without providing a usable fill. A ticker price or redemption value also cannot replace the quote for the adapter's actual call.
For an issuer RFQ, check who may issue and execute quotes, expiry, replay protection, recipient, input/output accounting and cancellation. Build a separate adapter for the issuer's protocol. Passing its calldata through the fixed Uniswap adapter would skip these assumptions and change that adapter's supported calls.
What the stock screen checked#
At Ethereum block 26,048,625, the screen checked 16 issuer-current xStocks v2 wrappers against USDC and WETH. It searched Uniswap V2, four V3 fee tiers and standard no-hook V4 keys. None of the 288 direct legs existed. The USDC/WETH controls passed, so the same lookup found the fixture's known pools.
The report covers those candidates and that block. Other venues, aggregators, custom hooks and later liquidity were outside the screen. Raw rebasing xStocks and unwrap-only v1 wrappers also have different transfer behavior. Keep the block/hash, candidate list, pool/key choices and exclusions with the report when using its result.
# Rechecks archived report structure and recorded source hashes.
# This does not refresh present-day liquidity or execute trades.
python3 docs/integrations/evidence/stock-venue-screen-2026-09-24/verify-evidence.pyPrepare the token and route release#
Create a fungible manifest for custody and screened exit, and put its digest in the asset release file outside mutable API configuration. Next describe the trading route: assets, venue, operation, input range, slippage policy, runtime/proxy checks, quote lifetime and public exposure. Publish the token and action registrations separately.
Add quote/relay validation and browser checks. Display the token or share count as the balance, with any estimated value and receiver restrictions alongside it. Use a supported adapter or write a narrow one, then put its output and owner in the action proof. Standard fungible routes can reuse the spend circuit; different token semantics may need another design.
Check withdrawal permissions and identity exposure#
A screened withdrawal sends the token to a public destination. Check the issuer's or wrapper's receiver rules first. Primary redemption and sale happen outside that transfer and may require issuer eligibility. When trading is revoked, offer only the withdrawals that the token's transfer rules still allow.
The venue, direction, amounts and timing of a trade are public. A permissioned issuer or RFQ counterparty may also know the trading identity. Explain how controller addresses, gas funding and app identity affect that exposure before the user generates a proof.
Test custody, trade and recovery together#
Test deposit accounting, both trade directions and a minimum-output failure that leaves the input unspent. Change a proxy or receiver permission and check rejection. Withdraw to a valid destination and exercise the user-facing failure for an invalid one. Then recover the final asset balance from history on a fresh client.
Keep the research screen, static checks, contract tests, funded Linux execution and service deployment results attached to their own runs. A stock listing still needs the token, liquidity, adapter, publisher and recovery checks described here. The source remains without an admitted stock route until that release exists.