Capas del sistema
La arquitectura describe cómo la cadena del Hub ejecuta transacciones y registra el estado canónico de las entidades. El Hub corre en dCorps Chain, un rollup de Arbitrum Orbit (modo rollup) que se asienta en Ethereum. Las capas abarcan desde la ejecución y el asentamiento del rollup hasta los contratos del núcleo, los adaptadores opcionales y las interfaces derivadas.
Ejecución del rollup
El rollup Arbitrum Orbit ejecuta transacciones; DCHUB alimenta gas, gobernanza y comisiones a nivel de protocolo.
Módulos del núcleo
Los módulos centrales almacenan identidad, roles, decisiones, carteras y el historial de eventos.
Adaptadores opcionales
Los adaptadores opcionales añaden contexto de jurisdicción, sector o cumplimiento sin cambiar el estado del núcleo.
Interfaces + indexadores
Los indexadores y las apps leen la cadena; muestran vistas no autoritativas.
Módulos centrales del núcleo
Cada entidad depende de un conjunto mínimo de módulos centrales que definen el registro canónico. Se mantienen reducidos para que la gobernanza evolucione sin cambiar el estándar.
Registro de entidades
Identidad, tipo de entidad y estado del ciclo de vida para que las entidades puedan referenciarse y verificarse.
Roles y autoridad
Las asignaciones de roles y permisos definen quién puede proponer, aprobar o gastar.
Acciones de gobernanza
Propuestas, votos y resoluciones registradas como historial oficial de decisiones.
Carteras y eventos
Carteras oficiales y eventos etiquetados de entradas y salidas rastrean actividad de tesorería.
Anclajes de documentos
Los hashes de documentos anclan evidencia para que las pruebas posteriores puedan verificarse.
Señales de divulgación y ciclo de vida
La arquitectura registra el nivel de divulgación y el estado del ciclo de vida en el registro canónico para que las interfaces muestren qué es público, qué es agregado y si una entidad está activa.
Modo A · Todo público
Máxima verificabilidad desde datos en la blockchain sin procesar.
Modo B · Estructura pública, reportes agregados
Los agregados y pruebas reemplazan partidas sensibles.
Modo C · Ejecución privada, anclajes públicos
Zonas privadas o subcadenas anclan resúmenes en el Hub.
borrador
Creado, aún no activo para contrapartes.
activo
Operativo y descubrible en el registro.
suspendido
Pausado por gobernanza o disparadores de política.
disuelto
Cerrado y ya no activo.
Módulos y adaptadores opcionales
Agrega contexto opcional mediante módulos y adaptadores que interpretan el estado del núcleo sin redefinirlo. Puedes añadirlos o retirarlos según cambien las necesidades. Pueden añadir contexto de jurisdicción, sector o aseguramiento.
Flujos de jurisdicción
Flujos opcionales para alinear entidades con requisitos de reconocimiento local.
Marcos sectoriales
Capas de gobernanza o estructuras de informes por sector construidas sobre el núcleo.
Atestaciones
Atestaciones o auditorías externas que referencian registros del núcleo sin reescribirlos.
Capas de informes
Modelos de divulgación y resultados generados a partir de registros de eventos estandarizados.
Canónico vs. derivado
El estado en la blockchain está ordenado en el tiempo y es a prueba de manipulación. Las vistas derivadas están fuera de la cadena y no son autoritativas; cualquiera puede reconstruirlas desde la cadena.
Canónico (en la blockchain)
Estado de módulos, parámetros e historial de eventos asegurados por consenso.
Derivado (fuera de la cadena)
Vistas de indexadores, paneles y exportaciones recreadas desde datos canónicos.
Mecánicas de registro
Registra eventos de forma determinística en formato nativo de stablecoins (USDC). Los eventos están ordenados en el tiempo y pueden incluir anclajes de evidencia. No se requieren rieles fiduciarios ni custodia.
Registro
Crear entidades y actualizar el estado del ciclo de vida en una secuencia verificable.
Gobernanza
Presentar propuestas y registrar aprobaciones que actualizan el estado canónico.
Eventos de tesorería
Registrar entradas, salidas y transferencias USDC etiquetadas desde carteras oficiales.
Anclajes
Anclar documentos y evidencia con hashes verificables posteriormente.
Manifiesto
"Mi objetivo es simple: permitir que cualquiera, en cualquier lugar, pueda crear una entidad capaz de operar con credibilidad, continuidad y con infraestructura financiera real, diseñada para operaciones en stablecoins."
Leer el ManifiestoNicolas Turcotte
Fundador e ingeniero principal
Contribuye ahora
La testnet es para constructores, operadores y responsables que quieren validar el Hub en público.
Ingenieros de protocolo
Trabajando en definiciones del kernel, alcance de mensajes e invariantes.
Ingenieros de indexación y datos
Definiendo esquemas de eventos y entradas reproducibles para las vistas.
Operadores tempranos
Probando el secuenciador, la publicación de lotes y el alcance operativo bajo reglas de testnet.
Inversionistas alineados con la infraestructura
Siguiendo alcance, riesgos y progreso (sin promesas de retorno).
Asesoría legal
Revisando la postura de límites, el alcance no custodial y el orden de la pila documental.
Responsables de gobernanza
Definiendo la separación kernel/adaptadores y la postura de actualización.
Acceso a la testnet
Solicita acceso para explorar el Hub, probar las interfaces de referencia y validar el comportamiento del protocolo de punta a punta en la testnet de desarrollo. Cualquiera puede solicitar acceso; el acceso de operador local/dev se revisa con mayor rigor.
Acceso controlado. Aprobación requerida.
Testnet Solo en inglés
Acceso a la testnet
Solicita acceso para explorar el Hub, probar las interfaces de referencia y validar el protocolo en la testnet de desarrollo. El acceso local/dev de operador se revisa con mayor rigor.
Solicitar acceso a la testnetBoletín Solo en inglés
Mantente informado
Actualizaciones concisas sobre la preparación de la testnet, lanzamientos y hitos de gobernanza.