Aurema Group

1. ¿Qué es ERC-3643 (T-REX)?

ERC-3643, anteriormente conocido como T-REX (Token for Regulated Exchange),
es un estándar de token Ethereum diseñado específicamente para security tokens que deben
cumplir con regulaciones financieras como MiCA (UE), SEC (USA) y otras normativas globales.

Historia y Evolución

Características Clave de ERC-3643

2. ¿Por Qué ERC-3643 vs ERC-20 para Security Tokens?

La elección del estándar de token es crítica para security tokens. ERC-20, aunque ampliamente
adoptado, no fue diseñado para cumplir con regulaciones financieras. ERC-3643 llena ese vacío.

Comparativa Detallada: ERC-20 vs ERC-3643

Cuándo Usar Cada Estándar

3. Arquitectura Técnica de ERC-3643

ERC-3643 no es un contrato monolítico, sino un sistema modular compuesto por
varios componentes que trabajan juntos para habilitar compliance on-chain.

Componentes Principales

Flujo de Transferencia con Compliance

// Pseudocódigo simplificado de transferencia ERC-3643

function transfer(address to, uint256 amount) public returns (bool) {
// 1. Verificar identidad del receptor
require(IdentityRegistry.isVerified(to), “Receiver not verified”);

// 2. Verificar reglas de compliance
require(
ComplianceModule.canTransfer(msg.sender, to, amount),
“Transfer violates compliance rules”
);

// 3. Ejecutar transferencia ERC-20 estándar
_transfer(msg.sender, to, amount);

// 4. Emitir evento para reporting
emit ComplianceTransfer(msg.sender, to, amount, block.timestamp);

return true;
}

Diagrama de Arquitectura

┌─────────────────┐
│   Inversor A    │
│ (Wallet 0x123)  │
└────────┬────────┘
         │ transfer()
         ▼
┌─────────────────┐
│ Token ERC-3643  │
│ "PropToken"     │
└────────┬────────┘
         │ canTransfer()?
         ▼
┌─────────────────┐     ┌─────────────────┐
│ Identity Registry│◄───►│ Compliance Module│
│ - Verifica A/B  │     │ - Evalúa reglas │
│ - País, tipo    │     │ - Jurisdicción  │
└────────┬────────┘     └────────┬────────┘
         │                       │
         └───────┬───────────────┘
                 │ ✅ Permitido / ❌ Rechazado
                 ▼
        ┌─────────────────┐
        │ Ejecutar/Revertir│
        │ Transferencia   │
        └─────────────────┘
            

4. Compliance On-Chain: Cómo Funciona en la Práctica

La magia de ERC-3643 está en cómo transforma requisitos regulatorios complejos en
código ejecutable que se aplica automáticamente en cada transacción.

Ejemplo: Reglas de Compliance para Token de Real Estate

// Configuración de reglas para “Prop Trust Verified Token” (PTV)

ComplianceRule[] rules = [
// Regla 1: Solo inversores verificados
ComplianceRule({
type: “INVESTOR_VERIFIED”,
params: { required: true }
}),

// Regla 2: Solo jurisdicciones permitidas
ComplianceRule({
type: “COUNTRY_WHITELIST”,
params: {
allowed: [“ES”, “FR”, “DE”, “IT”, “US”, “AE”, “CH”, “SG”]
}
}),

// Regla 3: Solo inversores acreditados/profesionales
ComplianceRule({
type: “INVESTOR_TYPE”,
params: {
allowed: [“ACCREDITED”, “PROFESSIONAL”]
}
}),

// Regla 4: Lock-up de 3 años desde fecha de compra
ComplianceRule({
type: “LOCKUP_PERIOD”,
params: {
duration: 1095 days, // 3 años en segundos
startDate: “purchase_date”
}
}),

// Regla 5: Límite de concentración por inversor
ComplianceRule({
type: “HOLDING_LIMIT”,
params: {
maxPercentage: 10, // Máximo 10% del supply por inversor
scope: “INDIVIDUAL”
}
})
];

Escenarios de Transferencia: ¿Se Permite o No?

Gestión de Identidades: Off-chain vs On-chain

Actualización de Reglas de Compliance

Las reglas de compliance pueden evolucionar. ERC-3643 permite actualizaciones controladas:

• Gobernanza: Cambios requieren aprobación de múltiples firmas (multi-sig)
• Notificación: Inversores son notificados de cambios materiales
• Período de transición: Nuevas reglas pueden tener fecha de entrada en vigor futura
• Grandfathering: Tokens existentes pueden mantener reglas anteriores si es necesario

5. Distribuciones Automatizadas de Dividendos

Una de las ventajas más poderosas de ERC-3643 para real estate tokenizado es la capacidad de
automatizar distribuciones de dividendos de manera compliant y eficiente.

Flujo de Distribución Trimestral

Código de Distribución (Simplificado)

// Función de distribución de dividendos en ERC-3643

function distributeDividends(uint256 totalAmount, address paymentToken)
external
onlyManager
{
// 1. Verificar que hay fondos suficientes
require(
IERC20(paymentToken).balanceOf(address(this)) >= totalAmount,
“Insufficient funds for distribution”
);

// 2. Obtener snapshot de holders elegibles en este bloque
uint256[] memory holders = TokenSnapshot.getEligibleHolders(block.number);

// 3. Calcular distribución proporcional
uint256 totalSupply = IERC20(token).totalSupply();

// 4. Ejecutar pagos
for (uint256 i = 0; i < holders.length; i++) {
address holder = holders[i];
uint256 balance = IERC20(token).balanceOf(holder);
uint256 dividend = (balance * totalAmount) / totalSupply;

// 5. Pagar en moneda preferida del inversor
PaymentPreference preference = getUserPreference(holder);
if (preference == PaymentPreference.EUR) {
payInEUR(holder, dividend); // Via oracle/bridge
} else {
IERC20(paymentToken).transfer(holder, dividend); // USDC
}

// 6. Emitir evento para reporting
emit DividendPaid(holder, dividend, paymentToken, block.timestamp);
}

// 7. Actualizar estado de distribución
lastDistributionBlock = block.number;
emit DistributionExecuted(totalAmount, holders.length, block.timestamp);
}

Ventajas de la Automatización

Consideraciones Técnicas Importantes

• Gas Optimization: Para muchos holders, usar merkle distributions o layer 2 (Polygon) para reducir costes
• Oracle Security: Datos off-chain (tipos de cambio, preferencias) deben venir de oráculos confiables (Chainlink)
• Reentrancy Protection: Usar Checks-Effects-Interactions pattern para evitar ataques
• Emergency Pause: Función de pausa para detener distribuciones en caso de emergencia

6. Mecanismos de Redemption bajo MiCA Artículo 44

MiCA requiere que los holders de Asset-Referenced Tokens (ARTs) tengan derecho a
redeem sus tokens a valor justo. ERC-3643 implementa este requisito de manera nativa.

Flujo de Redemption

Código de Redemption (Simplificado)

// Función de redemption conforme a MiCA Artículo 44

function redeem(uint256 amount) external {
// 1. Verificaciones básicas
require(amount > 0, “Amount must be positive”);
require(amount <= balanceOf(msg.sender), «Insufficient balance»);
require(IdentityRegistry.isVerified(msg.sender), «Not verified»);

// 2. Obtener fair value del token (vía oracle)
uint256 fairValuePerToken = FairValueOracle.getTokenValue(address(this));
require(fairValuePerToken > 0, “Invalid fair value”);

// 3. Calcular monto a pagar
uint256 payoutAmount = amount * fairValuePerToken;

// 4. Verificar liquidez para redemption
require(
IERC20(paymentToken).balanceOf(address(this)) >= payoutAmount,
“Insufficient liquidity for redemption”
);

// 5. Ejecutar redemption
_burn(msg.sender, amount); // Quemar tokens
IERC20(paymentToken).transfer(msg.sender, payoutAmount); // Pagar

// 6. Emitir eventos para compliance
emit TokensRedeemed(msg.sender, amount, payoutAmount, block.timestamp);
emit FairValueUpdated(fairValuePerToken, block.timestamp);

// 7. Notificar a autoridades si requiere reporting
if (payoutAmount >= REGULATORY_THRESHOLD) {
RegulatoryReporter.reportRedemption(msg.sender, amount, payoutAmount);
}
}

Garantías de Liquidez para Redemption

Para cumplir con MiCA, el emisor debe garantizar que siempre hay liquidez suficiente para redemptions:

• Reserva de liquidez: Mantener 5-10% del valor de tokens en activos líquidos (efectivo, stablecoins)
• Facilidades de crédito: Líneas de crédito con bancos para cubrir redemptions temporales
• Mercado secundario: Facilitar trading P2P para reducir necesidad de redemption directo
• Right of first refusal: Emisor puede comprar tokens a fair value antes de redemption externo

7. Custodia y Seguridad de Tokens ERC-3643

La seguridad de los tokens es crítica. ERC-3643 está diseñado para integrarse con
soluciones de custodia institucional que cumplen con estándares regulatorios.

Opciones de Custodia

Integración con Fireblocks (Ejemplo)

// Configuración de política de firma para tokens ERC-3643 en Fireblocks

{
“policy”: {
“assetId”: “ETH:0x123…abc”, // Dirección del token ERC-3643
“operations”: [“TRANSFER”, “APPROVE”, “CONTRACT_CALL”],
“approvals”: {
“threshold”: 2, // 2-of-3 multi-sig para operaciones críticas
“allowExternal”: false, // Solo direcciones whitelisted
“operators”: [
“aurema-compliance@…”,
“aurema-ops@…”,
“aurema-legal@…”
]
},
“amountLimits”: {
“maxAmount”: “1000000”, // Límite por transacción
“timeWindow”: “24h”
},
“compliance”: {
“requireDestinationTag”: true, // Para reporting
“blockSanctionedAddresses”: true, // Listas OFAC/UE
“requireApprovalForNewAddresses”: true
}
}
}

Mejores Prácticas de Seguridad

Recuperación de Acceso

¿Qué pasa si un inversor pierde acceso a su wallet? ERC-3643 permite mecanismos de recuperación controlados:

• Social recovery: Designar “guardianes” que pueden ayudar a recuperar acceso (con límites)
• Custodian recovery: Custodio institucional puede ayudar tras verificación de identidad rigurosa
• Legal recovery: Orden judicial puede forzar transferencia a nueva dirección (último recurso)

8. Integración ERC-3643 con MiCA Regulation

ERC-3643 y MiCA están diseñados para trabajar juntos. El estándar técnico habilita el cumplimiento
regulatorio de manera eficiente y verificable.

Mapeo: Requisitos MiCA → Funcionalidades ERC-3643

Ejemplo: Verificación de Reservas On-Chain

// Función para verificar que reservas cumplen MiCA Artículo 36

function verifyReserves() public view returns (bool) {
// 1. Obtener valor total de tokens en circulación
uint256 totalTokenValue = totalSupply() * fairValuePerToken();

// 2. Obtener valor de reservas (vía oracle)
uint256 reserveValue = ReserveOracle.getReserveValue(address(this));

// 3. Verificar que reservas >= valor de tokens (MiCA Art. 36)
bool isFullyBacked = reserveValue >= totalTokenValue;

// 4. Verificar que al menos 30% de reservas son líquidas (MiCA)
uint256 liquidReserves = ReserveOracle.getLiquidReserveValue(address(this));
bool hasLiquidity = liquidReserves >= (totalTokenValue * 30) / 100;

return isFullyBacked && hasLiquidity;
}

// Evento emitido en cada actualización de reservas
event ReservesUpdated(
uint256 indexed timestamp,
uint256 totalTokenValue,
uint256 reserveValue,
uint256 liquidReserves,
bool compliant
);

Auditoría y Reporting Automatizado

ERC-3643 facilita auditorías regulatorias al proporcionar un trail de auditoría completo on-chain:

• Transacciones: Cada transferencia registrada con metadatos de compliance
• Distribuciones: Eventos de dividendos con amounts, recipients, timestamps
• Redemptions: Registro completo de redemptions con fair value aplicado
• Actualizaciones: Cambios en reglas de compliance o parámetros del token

9. Caso Práctico: Tokenización de Portfolio Residencial con ERC-3643

Veamos cómo se aplica ERC-3643 en un caso real de tokenización inmobiliaria.

Escenario: Valencia Residential Portfolio

Configuración de Compliance para PTV

// Configuración inicial del token PTV (simplificada)

PTVTokenConfig config = PTVTokenConfig({
// Información básica
name: “Prop Trust Verified Token”,
symbol: “PTV”,
decimals: 0, // 1 token = €1 de valor

// Reglas de compliance
complianceRules: [
// Solo inversores verificados
Rule.VERIFIED_INVESTOR_REQUIRED,

// Jurisdicciones permitidas (MiCA + SEC)
Rule.COUNTRY_WHITELIST([“ES”, “FR”, “DE”, “IT”, “US”, “AE”, “CH”, “SG”]),

// Solo accredited/professional investors
Rule.INVESTOR_TYPE_ALLOWED([“ACCREDITED”, “PROFESSIONAL”]),

// Lock-up de 3 años desde compra
Rule.LOCKUP_PERIOD({ duration: 1095 days }),

// Límite de concentración: máx 10% por inversor
Rule.HOLDING_LIMIT({ maxPercentage: 10 }),

// Redemption permitido con fair value
Rule.REDEMPTION_ENABLED({
fairValueOracle: “0x…”,
paymentTokens: [“EUR”, “USDC”],
minRedeemAmount: 1000
})
],

// Configuración de distribuciones
distributionConfig: {
frequency: “QUARTERLY”,
paymentMethods: [“SEPA_EUR”, “USDC”],
autoReinvestOption: true
}
});

// Despliegue del token
PTVToken token = new PTVToken(config);

// Vincular con Identity Registry y Compliance Module
token.setIdentityRegistry(identityRegistryAddress);
token.setComplianceModule(complianceModuleAddress);

// Registrar emisor como manager con permisos
token.addManager(emisorAddress);

Flujo de Inversión de un Inversor

1. Onboarding: Inversor completa KYC/AML vía portal → Identidad registrada en Identity Registry
2. Verificación: Sistema confirma status accredited + jurisdicción permitida
3. Inversión: Inversor transfiere €50,000 → Recibe 50,000 tokens PTV en su wallet
4. Lock-up: Tokens no pueden transferirse durante 3 años (regla automática)
5. Distribuciones: Cada trimestre, recibe ~€1,150 (9.2% annual) en EUR o USDC
6. Post lock-up: Puede vender tokens en secundario o redeem a fair value

Beneficios Concretos de ERC-3643 en Este Caso

10. Comparativa de Estándares para Security Tokens

ERC-3643 no es el único estándar para security tokens. Veamos cómo se compara con alternativas.

ERC-3643 vs Otros Estándares

Factores de Decisión para Elegir Estándar

1. Regulación aplicable: Si MiCA/SEC aplica, ERC-3643 es la opción más segura
2. Perfil de inversores: Si hay inversores minoristas, compliance on-chain es crítico
3. Escala esperada: Para >100 inversores, la automatización de ERC-3643 ahorra costes
4. Horizonte temporal: ERC-3643 tiene roadmap a largo plazo con soporte institucional
5. Integraciones necesarias: Verificar que custodios/exchanges soportan el estándar elegido

11. Preguntas Frecuentes sobre ERC-3643

12. Conclusión: ERC-3643 como Estándar para el Futuro

ERC-3643 representa la convergencia entre innovación blockchain y cumplimiento regulatorio.
Para inversores institucionales y emisores de activos reales tokenizados, no es solo una opción técnica,
sino una necesidad estratégica para operar con seguridad legal y eficiencia operativa.

Resumen de Ventajas Clave

Próximos Pasos para Implementar ERC-3643

1. Evaluación: Determinar si ERC-3643 es adecuado para tu caso de uso (security token regulado)
2. Asesoramiento: Consultar con expertos en ERC-3643 y regulación aplicable (MiCA/SEC)
3. Proof of Concept: Desplegar token de prueba en testnet para validar funcionalidades
4. Auditoría: Auditoría de seguridad del contrato por firma reconocida
5. Despliegue: Lanzamiento en mainnet con Identity Registry y Compliance Module configurados
6. Onboarding: Integración con procesos KYC/AML y custodia institucional
7. Monitoreo: Herramientas para monitorear compliance y generar reportes regulatorios

📚 Recursos Técnicos Adicionales

Última actualización: Enero 2026
Autor: Aurema Group Technology & Compliance Team
Tiempo de lectura: 45 minutos