Qué es un token con restricciones (ERC-3643)

Qué le pide la RG 1150 al token

La RG CNV 1150/2026 reescribe el Título XXII de las Normas de la CNV. Cuatro artículos de la RG 1150 (cinco puntos, porque el art. 3 aparece dos veces) tocan directamente el diseño del contrato inteligente:

• Art. 3 (art. 5 del Título XXII, inc. e). La colocación, negociación y custodia se hacen en plataformas de PSAV (proveedores de servicios de activos virtuales) registrados, que no pueden ser más de 5. Tienen que adoptar estándares de interoperabilidad y una sincronización en tiempo real que evite discrepancias de registro entre ellos.
• Art. 3 (art. 5, inc. f). Los tokens no se transfieren ni negocian fuera de los PSAV intervinientes, ni hacia protocolos descentralizados. Se generan con contratos inteligentes "que impidan transferencias no permitidas".
• Art. 4 (art. 10). La TRD (tecnología de registro distribuido) tiene que garantizar seguridad, inmutabilidad, verificabilidad, fungibilidad, integridad, transferibilidad y trazabilidad.
• Art. 6 (art. 18). El PSAV bloquea los tokens de sus clientes desde la instrucción de voto hasta que termina la asamblea, y comunica las instrucciones con al menos 5 días de anticipación.
• Art. 8 (art. 36). Si la CNV suspende la oferta pública, los PSAV suspenden la comercialización digital hasta que se levante la medida.

La norma admite cualquier estándar de representación digital idóneo y no nombra ninguna red ni estándar. Elegir uno es una decisión técnica del emisor y de su proveedor. Si querés ver qué requisitos aplican a tu activo y régimen, el diagnóstico gratuito los lista.

Qué es ERC-3643 (T-REX)

ERC-3643, "Token for Regulated EXchanges", es un estándar de token con permisos para Ethereum y redes compatibles con su máquina virtual (EVM). Es compatible con ERC-20: expone las mismas funciones de saldo y transferencia, pero cada transferencia pasa por controles extra. La identidad on-chain es obligatoria: nadie recibe tokens sin una identidad verificada. Sus piezas:

• Identity Registry: liga cada billetera con un contrato de identidad (ONCHAINID) y un país. Su función isVerified dice si esa identidad tiene los atributos exigidos.
• Identity Registry Storage: guarda la lista de identidades habilitadas, separada de la lógica.
• Compliance: la función canTransfer evalúa las reglas de la oferta (por ejemplo, tope de tenedores o países permitidos) y devuelve sí o no. Después de cada transferencia, transferred actualiza su estado.
• Trusted Issuers Registry: lista quién puede firmar los atributos de identidad (por ejemplo, quien hizo el KYC).
• Claim Topics Registry: lista qué atributos tiene que tener toda identidad para operar.

Además trae funciones de administración: forcedTransfer (mueve tokens sin pasar por las reglas de compliance, aunque el receptor tiene que estar verificado), recoveryAddress (recupera el saldo de una billetera perdida), setAddressFrozen (congela una billetera), freezePartialTokens y unfreezePartialTokens (congelan una parte del saldo) y pause y unpause (frenan todo el token). El estándar define agentes, designados por el dueño del contrato, que gestionan el registro y pueden forzar transferencias.

Cómo cubre ERC-3643 lo que pide la norma

Un ejemplo: una transferencia aceptada y una rechazada

Supongamos una ON tokenizada con dos PSAV designados, A y B, ambos registrados en el Identity Registry. Un cliente de A vende 1.000 tokens a un cliente de B, y A envía los tokens a B. El contrato revisa que A tenga 1.000 tokens libres (su saldo menos lo congelado), que B pase isVerified, que ninguna de las dos billeteras esté congelada, que el token no esté pausado y que canTransfer devuelva sí. Todo se cumple: la transferencia se ejecuta y el contrato llama a transferred para actualizar el estado de compliance.

Ahora A intenta enviar 1.000 tokens a una billetera X que no está en el registro, por ejemplo la de un exchange no designado o el contrato de un pool de liquidez. isVerified(X) da falso, la transacción se revierte y el saldo no se mueve. Es lo que pide el inciso f: el propio contrato impide la transferencia.

La alternativa: un ERC-20 con whitelist propia

También se puede escribir un ERC-20 que consulte una lista de direcciones permitidas antes de cada transferencia, con pausa y congelamiento hechos a medida. La norma no lo impide, porque no impone estándar.

• A favor: menos contratos para desplegar, una lógica más corta y lista por dirección en lugar de identidades on-chain.
• En contra: todo el código es propio y la auditoría cubre más superficie; cada PSAV tiene que integrar una interfaz que no es pública; y funciones como recuperación de billeteras, bloqueo parcial o transferencia forzada hay que diseñarlas y probarlas desde cero.

Con hasta 5 PSAV que tienen que interoperar, una interfaz conocida simplifica la integración. Cómo impacta cada opción en horas y costo lo detalla la guía de costos y plazos, y quién opera cada pieza, la de PSAV o proveedor tecnológico.

Lo que no está confirmado: la página de ERC-3643 consultada no muestra el estado del estándar (borrador o final), así que no lo afirmamos. Tampoco asigna un rol a la mayoría de las funciones de administración. La RG 1150 no dice si las billeteras habilitadas son cuentas ómnibus de cada PSAV o billeteras por inversor custodiadas por el PSAV: es una decisión de diseño a validar con los PSAV y la CNV.