OpenZeppelin y ERC-3643: cómo se construye un security token

Una plataforma de valores tokenizados necesita contratos que representen el instrumento y apliquen las condiciones de sus operaciones. Algunas de esas funciones pueden construirse a partir de componentes existentes, mientras que otras dependen del diseño jurídico y operativo de la emisión. OpenZeppelin y ERC-3643 intervienen en partes distintas de ese trabajo.

OpenZeppelin aporta componentes reutilizables de contratos inteligentes. ERC-3643 define una arquitectura de tokens con identidad y controles de transferencia. Entender el alcance de cada uno permite decidir qué se reutiliza y qué debe configurar o desarrollar el equipo; su incorporación no certifica el producto ni garantiza por sí sola el cumplimiento normativo.

Qué aporta OpenZeppelin

OpenZeppelin Contracts proporciona implementaciones de tokens y controles de acceso reutilizables. La revisión de una biblioteca no cubre automáticamente las modificaciones, configuración, proxies o integraciones de un proyecto. Cada informe de auditoría tiene una versión y un alcance.

Un ERC-20 básico describe una interfaz para saldos y transferencias. Una emisión regulada puede necesitar restricciones adicionales, identidad de titulares, recuperación y administración. El estándar técnico no determina por sí solo los derechos del inversor.

Qué define ERC-3643

La especificación ERC-3643 describe tokens sujetos a permisos, con registros de identidad, declaraciones de terceros de confianza y controles de transferencia. El sistema comprueba las condiciones configuradas antes de permitir ciertas operaciones.

Eso no significa almacenar documentos de identidad completos en una red pública. Hay que diseñar qué datos quedan fuera de la cadena, quién emite las declaraciones, cuándo caducan y cómo se revocan. Una declaración incorrecta puede pasar una comprobación técnica sin reflejar la situación real.

Identidad, reglas y administración

• Identifica quién puede emitir, pausar, recuperar tokens o cambiar las reglas.
• Prueba transferencias permitidas y rechazadas, además de revocaciones y caducidades.
• Documenta la relación entre wallet, titular identificado y registro jurídico.
• Separa aprobación legal, revisión del contrato y operación del sistema.

Cómo evaluar alternativas

ERC-1400 propone una familia de interfaces con particiones y controles de transferencia. No debe describirse como necesariamente off-chain ni como más barata sin evaluar una implementación concreta. Tampoco una declaración de estandarización prueba la adopción, calidad o cumplimiento de un producto.

Compara las funciones necesarias, implementaciones mantenidas, auditorías de versiones concretas, permisos administrativos y pruebas de integración. Los costes de gas se miden con las mismas operaciones y condiciones.

Qué comprueba una transferencia y qué no

La especificación ERC-3643 diferencia la verificación de identidad del receptor mediante isVerified y las reglas globales mediante canTransfer. Una transferencia ordinaria también comprueba saldo disponible, bloqueos y pausa. No debe suponerse que todas las funciones ejecutan ese mismo recorrido: mint y forcedTransfer omiten las reglas globales de compliance descritas para transfer, aunque verifican al receptor; burn omite los controles de elegibilidad.

Esta diferencia exige pruebas por operación. Como ejemplo de ingeniería, si el proyecto configura un límite de posiciones, hay que estudiar tanto la compra ordinaria como una emisión administrativa que aumente el saldo. Probar únicamente transfer no demuestra que el conjunto de acciones privilegiadas respete el diseño acordado. Los controles adicionales que se necesiten deben quedar implementados y documentados.

La comprobación previa de una interfaz tampoco reserva el estado de la red. Entre la consulta y la ejecución pueden cambiar saldos o permisos. El frontend debe explicar el rechazo, actualizar la información y evitar presentar una simulación favorable como una operación finalizada.

Recuperación y permisos: un escenario de aceptación

Supongamos que un titular pierde acceso a su wallet. El procedimiento necesita validar la solicitud, autorizar la nueva dirección y ejecutar la recuperación prevista. Después deben contrastarse saldo, identidad vinculada, restricciones y evidencia de la operación. También hay que probar que una solicitud no autorizada no pueda producir el mismo resultado.

Es una propuesta de prueba de integración, no un procedimiento jurídico universal. El equipo debe concretar qué actor aporta la evidencia y cuál tiene permiso de ejecución. Una función administrativa correcta no compensa una comprobación de identidad incorrecta fuera de la red.

OpenZeppelin permite organizar permisos mediante controles de acceso. En la evaluación conviene incluir a quien puede conceder nuevos permisos, además de quien ya los tiene. Separar funciones operativas sirve de poco si una sola cuenta puede reasignarse todas ellas sin controles.

El entregable debería identificar versiones y configuración desplegadas, responsables administrativos y resultados de las pruebas de transferencia, bloqueo y recuperación. Así se puede relacionar cada función con un requisito y revisar lo que cambia en una actualización.

Aplicación a una emisión

El marco MiCA excluye los criptoactivos que sean instrumentos financieros. Elegir ERC-3643 no concede autorización para emitir ni sustituye el análisis de valores, comercialización o custodia. La arquitectura debe implementar los requisitos que resulten del diseño jurídico, y documentar sus límites.