Camadas do sistema
A arquitetura descreve como a cadeia do Hub executa transações e registra o estado canônico de entidades. O Hub roda na dCorps Chain, um rollup Arbitrum Orbit (modo rollup) que liquida no Ethereum. As camadas vão da execução e liquidação do rollup aos contratos do kernel, adaptadores opcionais e interfaces derivadas.
Execução do rollup
O rollup Arbitrum Orbit executa transações; o DCHUB alimenta gas, governança e taxas em nível de protocolo.
Módulos do kernel
Módulos centrais armazenam identidade, papéis, decisões, carteiras e o histórico de eventos.
Adaptadores opcionais
Adaptadores opcionais adicionam contexto de jurisdição, setor ou conformidade sem mudar o estado do kernel.
Interfaces e indexadores
Indexadores e apps leem a cadeia e exibem visões não autoritativas.
Módulos centrais do kernel
Toda entidade depende de um conjunto mínimo de módulos centrais que definem o registro canônico. Eles permanecem mínimos para que a governança evolua sem mudar o padrão.
Registro de entidades
Identidade, tipo de entidade e status de ciclo de vida para que entidades possam ser referenciadas e verificadas.
Papéis e autoridade
Vínculos de papéis e permissões definem quem pode propor, aprovar ou gastar.
Ações de governança
Propostas, votos e resoluções registrados como histórico oficial de decisões.
Carteiras e eventos
Carteiras oficiais e eventos de entrada e saída com tags acompanham a atividade de tesouraria.
Âncoras de documentos
Hashes de documentos ancoram evidências para que provas posteriores possam ser verificadas.
Sinais de divulgação e ciclo de vida
A arquitetura registra o modo de divulgação e o status do ciclo de vida no registro canônico para que interfaces mostrem o que é público, o que é agregado e se uma entidade está ativa.
Modo A · Tudo público
Máxima verificabilidade a partir dos dados brutos da cadeia.
Modo B · Estrutura pública, relatórios agregados
Agregados e provas substituem itens detalhados sensíveis.
Modo C · Execução privada, âncoras públicas
Zonas privadas ou subchains ancoram resumos no Hub.
rascunho
Criada, ainda não ativa para contrapartes.
ativo
Em operação e descobrível no registro.
suspenso
Pausada por governança ou gatilhos de política.
dissolvido
Encerrada e não mais ativa.
Módulos e adaptadores opcionais
Adicione contexto opcional por meio de módulos e adaptadores que interpretam o estado do kernel sem redefini-lo. Anexe ou remova conforme as necessidades mudem. Eles podem adicionar contexto de jurisdição, setor ou garantia.
Fluxos de jurisdição
Fluxos opcionais para alinhar entidades a requisitos de reconhecimento local.
Frameworks setoriais
Camadas de governança ou estruturas de relatórios específicas de setor construídas sobre o kernel.
Atestações
Atestações ou auditorias externas que referenciam registros do kernel sem reescrevê-los.
Camadas de relatórios
Templates de divulgação e saídas geradas a partir de registros de eventos padronizados.
Canônico vs derivado
Estado on-chain é ordenado no tempo e deixa evidência de adulteração. Visões derivadas são off-chain e não autoritativas; qualquer pessoa pode reconstruí-las a partir da cadeia.
Canônico (on-chain)
Estado de módulos, parâmetros e histórico de eventos protegido por consenso.
Derivado (off-chain)
Visões do indexador, dashboards e exportações recriadas a partir de dados canônicos.
Mecânicas de registro
Escreva eventos de forma determinística em formato nativo de stablecoin (USDC). Eventos são ordenados no tempo e podem incluir âncoras de evidência. Não há necessidade de trilhos fiat nem custódia.
Registro
Crie entidades e atualize o status de ciclo de vida em uma sequência verificável.
Governança
Envie propostas e registre aprovações que atualizam o estado canônico.
Eventos de tesouraria
Registre entradas, saídas e transferências de USDC com tags a partir de carteiras oficiais.
Âncoras
Ancore documentos e evidências com hashes que podem ser verificados mais tarde.
Manifesto
"Meu objetivo é simples: permitir que qualquer pessoa, em qualquer lugar, constitua uma entidade capaz de operar com credibilidade, continuidade e infraestrutura financeira real, projetada para operações nativas em stablecoins."
Ler o ManifestoNicolas Turcotte
Fundador e engenheiro-chefe
Contribua agora
A testnet é para desenvolvedores, operadores e responsáveis que querem validar o Hub em público.
Engenheiros de protocolo
Trabalhando em definições do kernel, escopo de mensagens e invariantes.
Engenheiros de indexação e dados
Definindo esquemas de eventos e entradas reproduzíveis para as visões.
Operadores iniciais
Testando o sequenciador, o envio de lotes e o escopo operacional sob as regras da testnet.
Investidores alinhados à infraestrutura
Acompanhando escopo, riscos e progresso (sem promessas de retorno).
Assessoria jurídica
Revisando a postura de limites, o escopo non-custodial e a ordem do pacote documental.
Responsáveis pela governança
Definindo a separação entre kernel e adaptadores e a postura de atualizações.
Acesso à testnet
Solicite acesso para explorar o Hub, testar as interfaces de referência e validar o comportamento do protocolo de ponta a ponta na dev testnet. Qualquer pessoa pode solicitar acesso; o acesso local/dev para operadores é analisado com mais rigor.
Acesso restrito. Aprovação necessária.
Testnet Somente em inglês
Acesso à testnet
Solicite acesso para explorar o Hub, testar as interfaces de referência e validar o comportamento do protocolo na dev testnet. O acesso local/dev para operadores é analisado com mais rigor.
Solicitar acesso à testnetBoletim Somente em inglês
Mantenha-se informado
Atualizações concisas sobre a prontidão da testnet, lançamentos e marcos de governança.