--- title: "Token con restricciones: qué es y cómo funciona ERC-3643" description: "Qué es un token con restricciones de transferencia, cómo funciona el estándar ERC-3643 (T-REX) y cómo cubre lo que pide la RG CNV 1150 para tokenizar valores." url: https://tokenizacion.com.ar/guias/token-con-restricciones-erc-3643 updated: 2026-11-09 --- # Qué es un token con restricciones (ERC-3643) Actualizado al 9 de noviembre de 2026. Por Agustín Chermaz, arquitecto blockchain. Un token con restricciones solo se mueve entre billeteras habilitadas: el contrato rechaza el resto. La RG 1150 pide contratos que impidan transferencias no permitidas, pero no impone estándar ni red. ERC-3643 (T-REX) es una opción técnica compatible con ERC-20: valida identidad y reglas antes de cada transferencia, y permite congelar, pausar y recuperar tokens. ## 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](https://tokenizacion.com.ar/#diagnostico) 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 **Mapeo entre la RG 1150 y ERC-3643 (la columna derecha es recomendación técnica)** | Lo que pide la norma | Cómo se resuelve con ERC-3643 | | --- | --- | | Transferir solo entre los PSAV intervinientes (art. 5 inc. f) | Solo se registran en el Identity Registry las billeteras de esos PSAV. Una transferencia exige que el receptor pase isVerified. | | No transferir hacia protocolos descentralizados (art. 5 inc. f) | El contrato de un protocolo no tiene identidad registrada: isVerified da falso y la transferencia se revierte. | | Contratos que impidan transferencias no permitidas (art. 5 inc. f) | canTransfer aplica las reglas de la oferta, como una restricción a inversores calificados. Los atributos exigidos se fijan en el Claim Topics Registry. | | Hasta 5 PSAV, interoperables y sincronizados en tiempo real (art. 5 inc. e) | Un solo contrato en la red funciona como registro común, con interfaz pública ERC-20. La conciliación con el agente de depósito queda fuera del estándar. | | TRD segura, inmutable, verificable, fungible, íntegra, transferible y trazable (art. 10) | La fungibilidad y la transferibilidad vienen de ERC-20. El resto depende sobre todo de la red elegida, que el estándar no define. | | Bloqueo de tokens para asambleas (art. 18) | freezePartialTokens sobre la cantidad instruida y unfreezePartialTokens al cerrar la asamblea. | | Suspensión si la CNV suspende la oferta (art. 36) | pause, y unpause cuando se levanta la medida. | | No lo pide la norma | recoveryAddress para billeteras perdidas y forcedTransfer para mover saldos sin pasar por compliance (el estándar exige que los agentes puedan hacerlo). | ## 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](https://tokenizacion.com.ar/guias/costos-y-plazos-de-tokenizar), y quién opera cada pieza, la de [PSAV o proveedor tecnológico](https://tokenizacion.com.ar/guias/psav-vs-proveedor-tecnologico). 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. ## Preguntas frecuentes ### ¿La RG 1150 obliga a usar ERC-3643? No. La norma pide contratos inteligentes que impidan transferencias no permitidas, pero no nombra ningún estándar ni red. ERC-3643 es una recomendación técnica, no un requisito. ### ¿Un token ERC-3643 funciona en una billetera común? Es compatible con ERC-20, así que una billetera lo puede mostrar. Pero solo recibe tokens si su dirección está registrada y verificada en el Identity Registry; si no, la transferencia se revierte. ### ¿Qué pasa si el inversor pierde la billetera? ERC-3643 trae la función recoveryAddress, que mueve los tokens de la billetera perdida a una nueva ligada a la misma identidad. La norma no lo pide, pero sin un mecanismo así el saldo quedaría inmovilizado. ### ¿Cómo se cumple la pausa ante una suspensión de la CNV? La obligación es del PSAV: suspender la comercialización digital (art. 8 de la RG 1150). Con ERC-3643, la función pause frena todas las transferencias del token hasta que se levante la medida. ## Guías relacionadas - [PSAV, entidad TRD y proveedor tecnológico: quién hace qué](https://tokenizacion.com.ar/guias/psav-vs-proveedor-tecnologico) : Roles de cada participante y cuándo hace falta registro ante la CNV. - [Costos y plazos de tokenizar un activo](https://tokenizacion.com.ar/guias/costos-y-plazos-de-tokenizar) : Semanas por etapa, horas de desarrollo, auditoría y qué queda afuera. - [Cómo tokenizar un fideicomiso o una ON pyme, paso a paso](https://tokenizacion.com.ar/guias/tokenizar-fideicomiso-u-on-pyme) : Seis etapas, quién hace cada una y cuánto lleva, con los requisitos de la norma. ## Fuentes - [RG CNV 1150/2026 (BO 11/06/2026)](https://www.argentina.gob.ar/normativa/nacional/norma-426586/texto) - [ERC-3643 (T-REX), estándar de token con permisos](https://ercs.ethereum.org/ERCS/erc-3643) Más detalle en la [metodología del diagnóstico](https://tokenizacion.com.ar/metodologia). Sitio independiente. No es asesoramiento legal ni financiero. El criterio oficial es el de la Comisión Nacional de Valores.