Exemption d’innovation SEC : la couche token laissée ouverte

Le problème : une chaîne ouverte, un pool fermé et aucun emplacement imposé pour la barrière

EN BREF L’emplacement de la barrière détermine ce qu’une plateforme peut encore faire appliquer une fois le token sorti du pool.

Sous conditions, la SEC (Securities and Exchange Commission, le gendarme boursier américain) permet désormais de négocier des actions NMS tokenisées sur une blockchain publique. Ce sont des actions cotées aux États-Unis. NMS veut dire National Market System. Les échanges se font dans des pools réservés aux wallets autorisés.

La décision décrit deux emplacements possibles pour le contrôle, dans le pool ou dans le token, sans imposer l’un ou l’autre.

C’est là qu’un auteur de standard de token a quelque chose à dire. Je lis donc la décision sous cet angle.

Les mots à connaître avant de lire la décision

EN BREF Une chaîne ouverte avec un pool filtré, c’est une salle réservée aux membres dans un bâtiment ouvert au public.

Ce que la SEC a accordé le 17 septembre

EN BREF La Release No. 34-106402 accorde deux exemptions, chacune pour cinq ans et sous conditions.

La première vise une Tokenized Securities VenueTokenized Securities Venue (TSV) Une plateforme de négociation qui exploite des pools d’actions NMS tokenisées et fixe les critères d’accès à la négociation. Voir le glossaire (TSV) qui exploite des pools de liquidité AMMPool de liquidité AMM AMM veut dire automated market maker. Des smart contracts détiennent deux actifs, ici un stablecoin et un token d’action. Une formule fixe le prix. Voir le glossaire pour des actions NMS tokeniséesAction NMS tokenisée En gros, une action cotée sur une Bourse américaine (NMS : National Market System), transformée en token sur une blockchain par son émetteur ou par un tiers sans lien avec lui. Voir le glossaire. Elle l’exempte de la définition légale d’« exchange » (une Bourse).

La seconde exempte certains apporteurs de liquidité de ces pools de la définition de « dealer » (un négociant). Le tableau reprend les principales conditions.

Négociation permissionnée sur une chaîne sans permission

EN BREF La chaîne doit rester ouverte à tous, tandis que la négociation sur la plateforme est restreinte.

Les smart contracts d’une TSV « must be auditable, public, and deployed on a public, permissionless distributed ledger ». Ils tournent donc sur une blockchain sans permissionBlockchain sans permission Une blockchain publique que, en règle générale, chacun peut lire et sur laquelle chacun peut écrire sans demander d’autorisation. Voir le glossaire, ce qui, selon la décision, signifie en règle générale que chacun peut la lire et y écrire sans autorisation.

La note 55 ajoute : « A permissioned AMM Liquidity Pool can be deployed on “permissionless” blockchain. » Un pool permissionné peut donc se trouver sur une chaîne ouverte.

La décision donne ensuite deux façons de construire la barrière. Un pool « may be encoded with criteria or a list of persons » : on peut y inscrire des critères ou une liste, pour que seuls les wallets autorisés négocient.

Autre voie : « a Tokenized NMS Stock could be encoded with criteria to only allow transfers ». Le token n’accepte alors de transfert que vers les wallets de personnes qui répondent aux critères de la plateforme. Un contrôle se trouve dans la plateforme, l’autre dans l’actif.

La chaîne publique était donc une question de conception avant d’être une question réglementaire. J’ai traité ce compromis dans quand la tokenisation RWA (actifs du monde réel) a besoin de sa propre chaîne.

Décrire la procédure d’accès, sans mécanisme imposé

EN BREF La décision demande à la plateforme de décrire comment elle accorde l’accès, pas d’utiliser un mécanisme donné.

Le point (f) de la notice obligatoire se rapproche le plus d’une spécification d’accès. Il demande les critères et « the procedures for approving access (e.g., white-listing or permissioning) », soit la façon d’autoriser un accès.

Il demande aussi quand la plateforme refuse ou limite l’accès. Les motifs incluent les sanctions de l’OFAC et la LCB-FT. L’OFAC (Office of Foreign Assets Control) gère les sanctions du Trésor américain. La LCB-FT, c’est la lutte contre le blanchiment et le financement du terrorisme.

Si une autre société fait les contrôles pour la plateforme, la décision précise que la TSV reste responsable. La procédure reste la sienne, quel que soit le code ou le prestataire qui l’exécute.

Couche pool ou couche token : OKXICE face à ERC-3643

EN BREF OKXICE vérifie un badge dans le pool à chaque opération ; ERC-3643 vérifie le destinataire dans le token à chaque transfert ordinaire.

OKXICE TSV a publié sa notice publique le 4 octobre. Son exploitant, OKXICE LLC, est une coentreprise entre Intercontinental Exchange Holdings et OKC USA Holding. Je la prends parce qu’elle est concrète, pas pour la recommander.

Son propre avertissement dit que la SEC « has not passed upon the merits or accuracy of the disclosures » : elle ne s’est prononcée ni sur le fond ni sur l’exactitude. Ses pools sont des pools Uniswap v4 sur X Layer, une blockchain publique. Un contrat d’extension, le « OKXICE TSV Hook », détermine qui peut s’en servir.

Seuls les wallets qui détiennent un soulbound tokenSoulbound token (SBT) Un token intransférable, attaché à un seul wallet. Une plateforme peut en émettre un comme badge : ce wallet a passé nos contrôles. Voir le glossaire (SBT) valide émis par la plateforme peuvent négocier ou apporter de la liquidité. C’est la couche poolCouche pool Le contrôle d’accès est placé dans le pool de négociation : seuls les wallets autorisés y négocient. Un transfert hors du pool ne passe jamais par ce contrôle. Voir le glossaire. Les étapes ci-dessous suivent la notice.

ERC-3643 place le même genre de contrôle dans le token : c’est la couche tokenCouche token Le contrôle d’accès est placé dans le contrat du token : un transfert ordinaire échoue si le destinataire n’est pas éligible, où qu’il ait lieu. Voir le glossaire. Un transfer ou transferFrom ordinaire échoue, sauf si deux conditions sont réunies. Le destinataire est vérifié dans l’Identity Registry (isVerified), et le contrat de conformité dit oui (canTransfer).

Il échoue aussi si l’un des wallets est gelé ou si le token est en pause. Dans ERC-3643, un agent est une adresse désignée par le propriétaire du token. Il fait des opérations comme mint (créer des tokens), le gel ou la récupération. Ces opérations suivent d’autres règles : voir l’encadré.

function transfer(address _to, uint256 _amount) public override whenNotPaused returns (bool) {
    require(!_frozen[_to] && !_frozen[msg.sender], "ERC-3643: Frozen wallet");
    require(_amount <= balanceOf(msg.sender) - (_frozenTokens[msg.sender]), "ERC-3643: Insufficient Balance");
    require( _tokenIdentityRegistry.isVerified(to), "ERC-3643: Invalid identity" );
    require( _tokenCompliance.canTransfer(from, to, amount), "ERC-3643: Compliance failure" );
    _transfer(msg.sender, _to, _amount);
    _tokenCompliance.transferred(msg.sender, _to, _amount);
    return true;
}

Ce qui se passe quand un token sort du pool

EN BREF Le contrôle d’un pool ne voit jamais un token qui passe d’un wallet à un autre hors du pool.

La décision limite elle-même l’exemption à « activity performed through the functionalities and systems provided by a TSV », c’est-à-dire à ce qui passe par les outils de la TSV. Un simple transfert de wallet à wallet ne passe pas par le pool.

La notice d’OKXICE dit aussi que l’action n’est pas réservée à sa plateforme. Une autre plateforme peut la proposer à trois conditions. Elle doit satisfaire aux exigences du tokenizer. Le tokenizer doit la prendre en charge. Elle doit respecter les conditions de l’exemption qui la visent.

Le token de l’action applique-t-il lui-même la liste blanche du tokenizer à chaque transfert ? La notice ne le dit pas, et je ne ferai pas de supposition.

Aucune couche n’est « la bonne ». Un filtre de pool convient aux règles de plateforme : qui négocie ici, plafonds de volume, suspensions. Un filtre dans le token convient aux règles de détention : qui peut détenir ce titre tout court.

CMTAT est un standard de token suisse. Il vient de la Capital Markets and Technology Association. J’ai comparé la façon dont ERC-3643, ERC-1400 et CMTAT placent ces contrôles dans un épisode dédié.

Un exemple concret : un wallet signalé après son admission

EN BREF Révoquer un badge ferme le pool à un wallet signalé, mais cette révocation, à elle seule, n’empêche pas ses transferts directs.

C’est une conception générique, pas le token d’action d’OKXICE : la notice ne le décrit pas sur ce point. Elle dit bien que la plateforme peut brûler ou révoquer le SBT après un signalement sur les listes de sanctions, et retirer le wallet de la liste blanche.

Ajoutez un gel dans le token, et le second cas change. Dans ERC-3643, setAddressFrozen bloque les transferts ordinaires vers et depuis ce wallet, quelle que soit la plateforme. Les opérations privilégiées des agents suivent toujours d’autres règles.

Chaque condition reliée à un contrôle

EN BREF Reliées ligne par ligne, les conditions de la décision ne tombent pas toutes proprement dans une seule couche.

Je relierais ainsi les conditions de la décision aux contrôles on-chain. La colonne OKXICE reprend sa notice. La colonne ERC-3643 dit ce que le standard peut mettre en œuvre, sans prétendre qu’il remplit quoi que ce soit.

Gel et récupération sont des pouvoirs du propriétaire du token et des agents qu’il désigne. D’où une question de gouvernance à part : qui peut les déclencher ?

Je l’ai examinée pour les opérateurs automatisés dans l’épisode Know Your Agent.

Ce qu’un contrat de token ne prouve pas seul

EN BREF Certaines conditions de la décision ne peuvent pas être inscrites dans un smart contract, aussi bon que soit le standard de token.

La décision exige que le token donne aux détenteurs « the same rights and privileges » que l’action classique. Même participation, mêmes dividendes, mêmes droits de vote, même part en cas de liquidation.

OKXICE dit le vérifier avec les déclarations juridiques du tokenizer, une attestation de réserves et des procédures écrites pour transmettre les droits. C’est du juridique et de l’opérationnel, et c’est normal. Un standard de token ne peut pas prouver qu’un dividende sera reversé.

C’est la couche du milieu que je regarderais de plus près. Les contrats d’OKXICE n’utilisent aucun oracle, ces services qui apportent des données extérieures on-chain. Les suspensions viennent d’un flux de données tiers.

Sa propre section sur les risques indique que des erreurs ou retards de ces données « could cause trading to continue during a halt » : la négociation pourrait continuer pendant une suspension. La pause relève du code. Son moment, non.

Ce que je demanderais à une plateforme avant de me fier à sa notice

EN BREF Avant de me fier à une notice de TSV pour un client ou une intégration, je voudrais des réponses écrites à cinq questions.

Aucune de ces réponses ne tranche la conformité d’une plateforme ; c’est une appréciation juridique. Elles disent quelle couche fait le travail. Pour approfondir la couche token, commencez par ERC-3643 expliqué.

Si vous lisez vous-même une notice de TSV

Sources : décision de la SEC, Release No. 34-106402, fiche de synthèse de la SEC, notice publique d’OKXICE TSV (4 oct. 2026), spécification ERC-3643.

FAQ