Es una pila, no un único estándar
El primer error es tratar la elección como una sola decisión. Un security token necesita que el mercado reconozca el activo, una forma de saber quién puede tenerlo, un contrato que lo represente, datos sobre cuánto vale y, a veces, una forma de moverse entre cadenas. Cada uno de esos problemas tiene sus propios estándares, y se relacionan entre sí de dos maneras distintas:
- Entre capas, por dependencia. ERC-3643 requiere un sistema de identidad; un fondo ERC-7540 necesita una fuente de NAV. Son relaciones entre capas, no herencia.
- Dentro de la capa de token, por herencia. ERC-3643 extiende ERC-20; ERC-7540 extiende ERC-4626. Ahí sí existe un árbol genealógico real.
Por eso un único árbol para todo confunde: MiCA no es padre de ERC-3643, y ONCHAINID no es hijo de ERC-20. A continuación vamos capa por capa, y dibujamos el árbol solo donde la herencia es real.
Capa 1: marco legal y regulatorio
No es un estándar técnico, pero condiciona a todos los demás: decide si el token es un instrumento financiero, quién puede comprarlo y qué restricciones de transferencia debe aplicar. Los regímenes que aparecen con más frecuencia:
| Régimen | Alcance | Qué implica para el token |
|---|---|---|
| MiCA (UE) | Criptoactivos que no son instrumentos financieros | Los valores tokenizados quedan fuera de su alcance; siguen bajo MiFID II |
| MiFID II + Régimen Piloto DLT (UE) | Instrumentos financieros; Reglamento 2022/858, aplicable desde marzo de 2023 | Permite que infraestructuras de mercado DLT negocien y liquiden valores tokenizados con exenciones específicas |
| Reg D, Reg S, Reg A+ (EE. UU.) | Colocaciones privadas, ofertas fuera de EE. UU. y ofertas públicas pequeñas | Definen la elegibilidad del inversionista y los periodos de bloqueo de reventa que el contrato debe aplicar |
| SCA y VARA (EAU, onshore) | Security tokens y contratos de tokens de commodities a nivel federal (Decisión SCA 15/RM/2025); en Dubái, activos virtuales, incluidos los referenciados a activos (ARVA), bajo VARA | Los security tokens deben negociarse y liquidarse en un mercado o ATS con licencia; un ARVA respaldado por activos que no son valores sigue en cambio el reglamento de emisión de VARA |
| DFSA (DIFC) y FSRA (ADGM), zonas francas de los EAU | Regímenes financieros propios: Investment Tokens en el DIFC, valores digitales en ADGM | Un valor tokenizado se regula como valor; la zona franca que elijas define el reglamento y la licencia |
El punto técnico: cada restricción que define el abogado (países elegibles, solo inversionistas acreditados, periodos de tenencia) tiene que terminar como una regla que el token aplica on-chain. Decidir esas reglas es trabajo del abogado de valores, no nuestro ni del estándar.
Capa 2: identificadores del activo
Un token también tiene que ser legible para la infraestructura de mercado tradicional: custodios, agentes de transferencia, sistemas de reporte. Para eso siguen aplicando los identificadores ISO:
| Estándar | Identifica | Por qué importa on-chain |
|---|---|---|
| ISIN (ISO 6166) | El valor | El token es el mismo valor; el ISIN suele vivir en la metadata del token |
| CFI (ISO 10962) | El tipo de instrumento | Clasifica el instrumento (acción, deuda, cuota de fondo) para reporte |
| DTI (ISO 24165) | El token digital y su registro | Vincula un contrato concreto en una red concreta con su ISIN |
| LEI (ISO 17442) | La entidad legal (emisor, SPV) | Identifica quién emite y quién es la contraparte |
| ISO 20022 | Mensajería financiera | Cómo el lado de pagos y liquidación se comunica con los bancos |
En la práctica, la dirección de un contrato por sí sola no es un identificador que el mercado reconozca. El par ISIN y DTI es lo que conecta el token con el mundo tradicional.
Capa 3: identidad y KYC
Un token con permisos necesita saber si una wallet pertenece a una persona verificada y elegible, sin poner datos personales on-chain. Dos familias de estándares lo resuelven.
ONCHAINID es el sistema de identidad que usa ERC-3643. Se basa en ERC-734 (gestión de llaves) y ERC-735 (claims), dos propuestas que nunca llegaron a ser EIP finales pero que corren en producción a través de ONCHAINID. Cada inversionista tiene un contrato de identidad con claims firmados por un emisor de confianza (tu proveedor de KYC), como "pasó KYC" o "inversionista acreditado". Lo que vive on-chain es la prueba, no el dato.
Los Decentralized Identifiers (DID) y Verifiable Credentials (VC) del W3C son el estándar de la web para la misma idea: credenciales emitidas por una parte de confianza que el titular presenta y cualquiera puede verificar. Son más comunes off-chain y fuera de la EVM, y pueden alimentar un claim on-chain.
La decisión de arquitectura aquí es dónde se verifica la elegibilidad: en cada transferencia (claims on-chain) o una sola vez, antes de habilitar la wallet (un registro o una allowlist). Ambas son válidas; difieren en costo, privacidad y en qué tan portable es la identidad entre tokens.
Capa 4: estándares de token, el árbol genealógico
Las tres raíces
ERC-20 (fungible), ERC-721 (no fungible) y ERC-1155 (multi-token) son las bases. Ninguno tiene cumplimiento: circulan libremente. Casi todos los estándares de activos reales extienden uno de los tres.
Valores con permisos
ERC-3643 (T-REX), Final. Un ERC-20 con un registro de identidades, un registro de claims requeridos, emisores de confianza y un contrato de cumplimiento modular. Las transferencias a wallets no elegibles revierten. Incluye congelamiento, transferencias forzadas y recuperación de wallets, y es la opción más madura para valores tokenizados en la EVM. Lo explicamos en detalle en Por qué ERC-3643 y no un token normal.
La familia ERC-1400, nunca finalizada. ERC-1410 (particiones), ERC-1594 (emisión y redención con validación de transferencias), ERC-1643 (documentos) y ERC-1644 (operaciones del controlador). Se propuso en 2018 como issues de GitHub y nunca entró al repositorio oficial de ERCs. Se sigue citando en todas partes y tiene despliegues, pero no es un estándar finalizado, un detalle que muchas comparativas omiten. Sus ideas (particiones, documentos adjuntos) siguen vivas en estándares más nuevos.
ERC-7518 (DyCIST), en Review. Un security token construido sobre ERC-1155 con particiones semifungibles: cada ID de token puede representar una clase o tramo con sus propias reglas, e incluye previsiones para cumplimiento entre cadenas. Vale la pena seguirlo; todavía no es final.
ERC-7943 (uRWA), Final. El más nuevo y el más minimalista. No prescribe cómo se hace el cumplimiento, solo la interfaz: canTransfer, canSend, canReceive, setFrozenTokens, getFrozenTokens y forcedTransfer, con variantes para ERC-20, ERC-721 y ERC-1155. Su valor es la interoperabilidad: un protocolo DeFi o una wallet puede preguntarle a cualquier token de activo real "¿esta transferencia puede ocurrir?" sin conocer su lógica interna. Más que competir con ERC-3643, se monta encima: un token con lógica de cumplimiento completa también puede exponer la interfaz uRWA.
Fondos y vaults
ERC-4626, Final. El estándar de vaults tokenizados: depositas un activo y recibes participaciones, con una tasa de cambio estándar entre ambos. ERC-7540, Final, lo extiende con solicitudes asíncronas: los depósitos y rescates se solicitan ahora y se liquidan después. Así funciona exactamente un fondo real (suscripciones y rescates al siguiente corte de NAV), y por eso ERC-7540 es la referencia para fondos tokenizados y crédito privado.
Instrumentos estructurados
ERC-3525, Final. Semifungible: cada token tiene un ID, un slot y un valor, y los tokens del mismo slot son fungibles entre sí. Encaja con bonos de distintos vencimientos o tramos. ERC-6960 (token de doble capa) va en una dirección parecida, con categorías y subcategorías de activos, pero todavía es un Draft.
El estado de un estándar no es un detalle. "Final" significa que la interfaz no va a cambiar; "Review" o "Draft", que todavía puede cambiar; y "nunca fue EIP", que no hay una especificación oficial contra la cual auditar.
| Estándar | Extiende | Qué agrega | Estado |
|---|---|---|---|
| ERC-3643 | ERC-20 | Identidad, cumplimiento, congelamiento, transferencia forzada | Final |
| Familia ERC-1400 | ERC-20 | Particiones, documentos, controlador | Nunca fue EIP |
| ERC-7518 | ERC-1155 | Particiones, cumplimiento dinámico, entre cadenas | Review |
| ERC-7943 | ERC-20, 721 o 1155 | Interfaz mínima de cumplimiento | Final |
| ERC-4626 | ERC-20 | Participaciones de vault | Final |
| ERC-7540 | ERC-4626 | Depósitos y rescates asíncronos | Final |
| ERC-3525 | ERC-721 | Slots y valor (semifungible) | Final |
Más allá de Ethereum: Polygon, Avalanche y Solana
La elección de red cambia menos de lo que parece entre cadenas EVM, y mucho cuando entra Solana.
Polygon y la C-Chain de Avalanche son EVM: los mismos estándares (ERC-3643, 7943, 4626, 7540) se despliegan sin cambios, con las mismas herramientas y los mismos auditores. Las diferencias son de costo y de ecosistema, y las comparamos en En qué blockchain desplegar un RWA.
Las Avalanche L1 (antes subnets) agregan algo que las demás no tienen: permisos a nivel de red. Con los precompiles de allowlist de Subnet-EVM, TxAllowList y ContractDeployerAllowList, puedes restringir quién envía transacciones o despliega contratos en toda la cadena. Eso no reemplaza el cumplimiento a nivel de token; agrega un segundo perímetro, útil en entornos institucionales.
Solana no usa ERCs. Su equivalente es el programa Token-2022 (Token Extensions): en lugar de escribir un contrato nuevo por token, se habilitan extensiones sobre el mint. Existen las mismas funciones de cumplimiento, implementadas de otra forma:
| Requisito | EVM (Ethereum, Polygon, Avalanche) | Solana Token-2022 |
|---|---|---|
| Solo titulares verificados | Registro de identidades (ERC-3643) o canReceive (ERC-7943) | Default Account State en congelado; las cuentas se descongelan tras el KYC |
| Reglas de transferencia a medida | Módulo de cumplimiento | Transfer Hook, un programa que se invoca en cada transferencia |
| Transferencia forzada y recuperación | forcedTransfer (ERC-3643, ERC-7943) | Permanent Delegate |
| Congelar y pausar | Funciones de congelamiento y pausa | Freeze authority y la extensión Pausable |
| Metadata y documentos | Metadata del token, documentos ERC-1643 | Metadata Pointer y Token Metadata |
| Saldos confidenciales | No nativo (red privada o zero-knowledge) | Confidential Transfer |
| Visualización de rendimiento | Precio de la participación del vault (ERC-4626) | Interest Bearing, Scaled UI Amount |
La consecuencia práctica: el diseño de las reglas de cumplimiento es portable, el código no. Una emisión en EVM y en Solana implica dos implementaciones de las mismas reglas, y tienen que mantenerse sincronizadas.
Capa 5: datos y oráculos
Dos tipos de datos llegan al token desde el mundo real. Proof of Reserve verifica que el activo que respalda el token existe (saldos en custodia, inventario certificado) y puede bloquear la emisión si la oferta supera las reservas. Los feeds de NAV publican el valor por participación de un fondo, que es justo lo que necesita un vault ERC-7540 para liquidar suscripciones y rescates. Chainlink es el proveedor más común tanto en la EVM como en Solana. Aquí importa menos la interfaz que el proceso: quién certifica el dato, cada cuánto y qué pasa si deja de actualizarse.
Capa 6: interoperabilidad
Cuando el mismo activo vive en más de una red, la pregunta es cómo se mueve la oferta sin duplicarse. Predominan tres enfoques:
| Opción | Modelo | Dónde encaja |
|---|---|---|
| Chainlink CCIP (estándar Cross-Chain Token) | Burn-and-mint o lock-and-release, con el emisor en control de sus pools de tokens | Redes EVM y Solana |
| Wormhole NTT (Native Token Transfers) | Burn-and-mint del token nativo, con límites de tasa | Especialmente EVM y Solana |
| xERC20 (ERC-7281) | El emisor fija límites de emisión por bridge | Una propuesta que nunca entró al repositorio oficial de ERCs |
Para un token con permisos, el bridge es el punto delicado: el cumplimiento tiene que sostenerse en ambos lados. La wallet receptora necesita una identidad válida en la red de destino, y el contrato del bridge necesita el rol para emitir y quemar sin saltarse las reglas. Antes de elegir un bridge, pregunta cómo aplica la cadena de destino la misma elegibilidad. Si la respuesta es "no la aplica", el bridge es un hueco de cumplimiento.
Cómo se combinan las capas: puntos de partida típicos
Ninguna combinación es universal, pero estos son puntos de partida razonables por tipo de activo. Son un insumo para el Discovery, no una recomendación para tu caso concreto:
| Activo | Token | Identidad | Datos |
|---|---|---|---|
| Inmuebles (participaciones de un SPV) | ERC-3643 | ONCHAINID y un proveedor de KYC | Tasación y reporte de rentas |
| Crédito privado o bonos | ERC-3643, o ERC-3525 para tramos y vencimientos | ONCHAINID | Calendario de pagos y NAV |
| Fondos | ERC-7540 con un token de participación con permisos | ONCHAINID o una allowlist | Feed de NAV |
| Commodities y reservas | ERC-3643 | ONCHAINID | Proof of Reserve |
| Emisión en Solana | Token-2022 con Transfer Hook y Default Account State | KYC off-chain y luego descongelamiento | Proof of Reserve o NAV |
Dónde termina nuestro alcance
Braincoders diseña y construye las capas técnicas (contratos de token, integración de identidad, reglas de cumplimiento en código, oráculos y lógica entre cadenas) en redes EVM y en Solana. Lo que no hacemos es decidir la capa legal: la naturaleza del instrumento, quién es elegible y qué régimen aplica los define el abogado de valores, y nosotros los aplicamos on-chain.
Este mapa cambia rápido. El estado de cada estándar de este post se verificó contra el repositorio oficial de ERCs en septiembre de 2026.
¿Necesitas decidir qué estándares debe combinar tu tokenización? Agenda una llamada de descubrimiento y mapeamos tu activo capa por capa.
