Whitepaper · 14
Desenvolvimentos Futuros
O roteiro de uma interface alfa congelada até um padrão de fato e, depois, oficial, e o trabalho técnico que o acompanha. As datas são metas, não promessas.
Princípio
As interfaces é que são padronizadas; todo o resto pode evoluir. O roteiro tem, portanto, duas trilhas: padronização (tornar as interfaces confiáveis e adotadas) e implementação (melhorar a referência e os módulos sem tocar nas interfaces).
Trilha de padronização
| Fase | Meta | Critérios de saída |
|---|---|---|
| 0 · Congelamento alfa (agora) | rascunho 2.1.0-alpha.2 com as suas interfaces e o esquema de metadados 1.2.0; implementação de referência com todos os hooks de domínio e extensões; CI; especificação em formato ERC; uma suíte de conformidade independente de implementação; mapeamentos informativos para EPCIS 2.0, UNTP 0.7.0 e PACT 3.0.3; documento de projeto do sistema, registros de decisão e pacote de auditoria | nenhuma mudança de interface sem uma versão maior |
| 1 · Âncora de produção (6–12 meses) | uma implantação real (cooperativa, armazém graneleiro ou exportador) com lotes reais em uma L2 ou em uma rede permissionada | seis meses de operação; métricas públicas: lotes, transformações, transferências forçadas executadas, tempo para responder a uma solicitação de rastreabilidade; auditoria de terceiros publicada |
| 2 · Comunidade (em paralelo) | tópico no Ethereum Magicians; coalizão de implementadores independentes de hooks; adaptador bidirecional de conformidade do ERC-3643 | três implementações independentes de IARexHook fora deste repositório; dois tokens conformes independentes |
| 3 · Submissão | ERC em estado Draft em ethereum/ERCs contendo apenas standard/AREX-CORE.md (camadas 1–3; o ERC-7943 referenciado, não copiado) | aceitação pelos editores; Last Call sem objeções impeditivas |
| 4 · Governança neutra (ano 2) | grupo de trabalho ou associação independente dos autores originais; articulação com o ISO TC 307 (a iniciativa espanhola sobre o ERC-3643) e com a GS1 | documentos de governança adotados; especificação mantida fora de uma única empresa |
Por que não submeter agora: o ERC-3643 esteve em produção por três anos antes de seu EIP; o ERC-7943 atingiu o status Final em oito meses porque sua coalizão já o usava. Um ERC congela aquilo que padroniza, e as interfaces merecem um ciclo de produção antes de serem congeladas para todos.
Trilha de implementação
Módulos de domínio: migrados (setembro de 2026)
| Módulo | Agora | Situação |
|---|---|---|
| Perecibilidade | PerishabilityHook (linear, exponencial, em degraus; configuração por commodity e por lote) + ExpiryHook | concluído |
| Sazonalidade | SeasonalHook | concluído |
| Entrega | DeliveryHook (máquina de estados, cadeia de frio, disputas, trava de unidades O(1), liquidação por dados da transferência) | concluído |
| Rastreabilidade | TraceabilityHook (vocabulário EPCIS; apenas emissão ou persistido) | concluído |
| Sanções, conformidade | EligibilityHook (sanções com fonte e TTL) | concluído |
| Limites de transferência / cotas | não distribuído; o guia Desenvolvimento de hooks mostra um modelo de hook de cotas de custo limitado | em aberto (comunidade) |
| Oráculo | CommodityPriceOracle (rodadas numeradas, quórum, mediana) | concluído |
| Carbono | CarbonImmobilizationWrapper (créditos imobilizados em registro; atestação; sem emissão) | concluído |
| Seguro | ParametricInsurance (acionado por atestação) | concluído |
O trabalho de implementação restante nesses componentes é de otimização e de fortalecimento para produção, e não de projeto.
Primitivas de liquidação e de financiamento
- Retenções e escrow (entrega contra pagamento): um hook mais um contrato complementar que implemente a liberação condicional; alinhamento com o ERC-7573 quando uma perna de pagamento estiver on-chain.
- Fluxo de penhor: um contrato pequeno que aciona
setFrozenTokens/forcedTransfera partir do hash de um contrato de penhor, de modo que os financiadores operem o papel de enforcement por meio de um procedimento auditável, e não de chamadas diretas.
Privacidade
- Divulgação seletiva de dados de qualidade: provas de conhecimento zero de que uma medição no documento de metadados está dentro de um limite (umidade, aflatoxina, resíduos) sem revelar o valor; a prova se torna uma atestação.
- Controle de acesso a dados restritos: implementação de referência do ponteiro
restrictedcom tokens de capacidade para compradores, certificadores e reguladores.
Identidade e atestações
- Feito como adaptadores de referência (ADR-020 a ADR-022, Proposto): compatibilidade com o ERC-3643 por lote, um emissor de declarações do ONCHAINID e um espelho no EAS.
- Implementação de
IARexAttestbaseada no EAS. - Hook de elegibilidade baseado em declarações do ONCHAINID e em credenciais verificáveis (carteiras eIDAS 2.0).
Cross-chain
- Referência de wrapper ERC-7802 / CCIP; a linhagem permanece na rede de origem.
Ferramental
- Exportadores EPCIS 2.0 e UNTP 0.7.0 sobre o log de eventos, seguindo os mapeamentos informativos que o padrão passou a publicar.
- Validador de JSON Schema e canonicalizador RFC 8785 para metadados.
- Modelos de subgraph / indexador para lotes, linhagem, atestações e enforcement.
- Verificação formal das invariantes do pipeline de transferência (conservação da oferta, status terminal, ausência de reentrância); um teste de invariantes randomizado com semente já as exercita (
test/standard/Invariants.test.js).
Questões de pesquisa
- Se as transições de
statusdeveriam poder ser expressas como uma tabela on-chain (autômato definido pelo emissor) sem inchar o padrão. - Se uma interface padrão de elegibilidade de contas, separada dos hooks, facilitaria a integração com mecanismos de conformidade, ou se a conjunção de hooks basta.
- Regras de balanço de massa para processamento (limites de rendimento por par de commodities) como hooks, e sua interação com perdas legítimas.
- Conciliação entre a linhagem on-chain e a mistura física em silos, em que "qual quilograma" é, juridicamente, um direito fungível.
Propostas em análise
- Perfis de política por jurisdição e por organização para enforcement, pausa, sanções e revogação, com os esclarecimentos sobre a origem e a revogação que os acompanham (ADR-019, Proposto).
- A visão de compatibilidade com o ERC-3643, o emissor de declarações do ONCHAINID e o espelho no EAS (ADR-020, ADR-021, ADR-022, todos com status Proposto).
- Um objeto
extensionsno esquema de metadados 1.3.0 (ADR-017, Proposto), uma pegada de carbono declarada no formato PACT (ADR-018, Proposto) e o descritor de regrasarex.module/1(informativo, Proposto). Cada um aguarda um segundo implementador independente.
O que não mudará
- As quatro interfaces, sem uma versão maior e uma nota de migração.
- A regra de que os módulos são demonstrações, e não padrão.
- A regra de que os dados pessoais ficam off-chain.
- A regra de que a autoridade vem de papéis, e não de saldos.