On September 17, 2026 the Securities and Exchange Commission exempted Tokenized Securities Venues from the definition of exchange, on conditions. One of those conditions is that the venue sets standards for who may access trading, and the order describes those standards as a property of a wallet address. Send a wallet and a condition. Get a signed yes or no you can put in the file.
A TSV, in the order's words, “sets standards to allow only permissioned TSV Participants to access trading and to buy and sell Tokenized NMS Stock on the TSV.” It then describes how that standard may be enforced: a liquidity pool “may be encoded with criteria or a list of persons to ensure that only certain ‘white-listed’ or ‘allow-listed’ crypto asset wallet participant addresses (i.e., wallet addresses that meet certain credentialing requirements) gain access to trading,” or the stock itself may be encoded to allow transfers only to qualifying addresses.
On where the screening happens, the order leaves both doors open: “Applicable identification or eligibility screening processes may be done through, for example, active, offchain management or onchain protocols.” This page is about the first of those, active offchain management, the one that does not put your admission rule inside a smart contract.
Read wallet state, evaluate the condition, return a signed boolean. Nothing is written to a chain, nothing is transferred, no participant profile is built.
Holds the venue participant pass. Holds an attestation written by your onboarding provider. Holds the asset the pool is priced in. The rule travels with the request, so it is never hard-coded inside somebody else's system, and it is the rule you can quote in your notice.
Read-only queries across 39 blockchains, answered at a named block. A check made at the moment of the trade reflects a change made that morning. A list refreshed at onboarding does not.
The result, a hash of the condition evaluated, the block it was read at and the times it was made and expires. Signed with ECDSA P-256 under a published key identifier, with an independent post-quantum companion signature beside it. Ask for a proof and the answer also carries the chain's own Merkle proof of the value behind it.
A venue keeps information about the methods used to screen participants and verify wallet addresses, and preserves it for the life of the exemption plus three years. An answer that can be checked again later is worth more than one that has to be taken on trust.
Eligibility facts change during the day. Attestations expire. A delegation can be revoked in one transaction. A check against current state is a different artifact from a list refreshed at onboarding, and the difference shows up in the record.
The pool receives the qualification result, not the participant's portfolio. No participant profile and no holdings database is kept on our side, by design.
ECDSA P-256 with a key identifier, verified offline against the published key set by anyone who was not in the room. Beside it, since September 2026, an independent post-quantum companion signature covering the same answer, under ML-DSA-65 as standardised in FIPS 204. Both are additive and neither depends on us being reachable.
The condition that was evaluated is hashed into the signed answer. Anyone can re-hash the rule they believe was applied and confirm it matches. What was checked stops being a matter of recollection.
Ask for it and the answer carries an EIP-1186 proof, on 27 of 33 EVM chains: a storage proof for a token balance, or an account proof for a native one. It checks against that block's state root using nothing but the block header, and an account proof can prove a balance of zero, which a lookup never can.
If a required read fails or returns unreliable data, no attestation is issued. There is no guess in the file.
A venue's admission rule is a mix, and only part of it lives on a chain. Being clear about the boundary is more useful to you than a longer feature list.
And the honest one. The order does not require any of this. It requires a venue to set standards, to describe its procedures, and to keep records of the methods it used. This is one way of doing that which leaves behind something an examiner can reproduce.
Your policy comes first. It decides which facts have to be true, and each of those facts is answered by whoever is authoritative for it. Chain state is one of them. Where a venue wants several signed inputs in one place, they can be assembled without any of them being re-signed, wrapped or altered, so each stays independently verifiable under the key of the provider that issued it. The relying party applies its own policy to the set. No composite verdict is produced, and no single signature is placed over the aggregate.
The wiring is public. The multi-attestation format is documented in the open, and SkyeMeta's SkyeProfile, powered by InsumerAPI, runs a live reference assembly across independent issuers.
A per-trade admission check in about forty lines, with a real signed response and local verification. A free key takes an email and two seconds.
Our reading of the order for issuers and venues is here • Verification reference