Padrão do Núcleo

Objetivo de projeto: a menor interface que um terceiro implementará

Um padrão é adotado quando implementá-lo custa menos do que não ser interoperável. Cada campo, função e regra do A-REX Core teve de passar em um teste: uma equipe independente, construindo uma plataforma de armazém graneleiro na Argentina ou o sistema de um exportador de café na Colômbia, aceitaria essa restrição em troca de interoperabilidade? Enumerações de culturas, nomes de classes de qualidade dos EUA, um registro obrigatório de propriedades rurais, uma pilha de identidade prescrita e uma fórmula de valoração falharam nesse teste. Identidade de lote, linhagem, enforcement e um ponto de extensão passaram.

O registro do lote, campo a campo

O que está deliberadamente ausente: latitude e longitude, identificador de propriedade rural, enum de classificação, umidade e proteína, flag de verificação e endereço do verificador, um campo quantity (o controle de oferta do ERC-1155 é a fonte autorizada) e qualquer noção de valor.

Linhagem como operação

Um ciclo de vida com um estado PROCESSED, mas sem forma de produzir o bem processado, é um erro comum. Os regimes de rastreabilidade são explícitos ao dizer que a transformação é um evento que liga entradas a saídas: o evento crítico de rastreamento de transformação da FSMA 204, o TransformationEvent do EPCIS 2.0 com inputQuantityList e outputQuantityList. Um mapeamento de lotes-pai escrito por um administrador não carregaria nem as quantidades nem a atomicidade.

transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) queima e cunha em uma única transação, registra os lotes-pai em cada saída, emite um único evento com todas as quantidades e uma referência de processo, e executa o pipeline de hooks em cada etapa. Divisão (1→n), união (n→1) e processamento (n→m) são a mesma função. A implementação de referência permite que qualquer titular faça o reagrupamento (mesma commodity e mesma unidade, quantidade conservada) para a sua própria conta, mas exige TRANSFORMER_ROLE para alterar a natureza ou a quantidade dos bens, ou para entregar as saídas a outra conta — um moinho pode transformar trigo em farinha, um produtor não pode transformar trigo em ouro. As duas etapas de uma transform executam os hooks como OP_TRANSFORM, de modo que um produtor que vende parte de um lote primeiro o reagrupa no lugar e depois o transfere; a venda passa por todas as regras de transferência.

transform não atravessa tokens. Quando o token de um comprador recebe bens do token de um fornecedor, o novo lote indica o lote do fornecedor nos seus metadados: a lista upstream do esquema 1.2.0 informa o chain id, o contrato, o id do token e se os bens foram recebidos dele sem alteração (received_from) ou processados a partir dele (processed_from). Uma referência a montante é uma afirmação do emissor a jusante, e não um fato on-chain; por isso, pede-se a indexadores, auditores e ferramentas de recolhimento que a confrontem com o token a montante e que exibam como não verificadas as referências que não conseguiram verificar. Um recolhimento para a frente entre tokens lê essas listas, porque o token a montante não guarda nenhum registro delas.

Enforcement vindo do ERC-7943, e não reinventado

Lotes agrícolas estão rotineiramente sujeitos a gravames, warrants, embargos, processos de insolvência e recolhimentos. Um token que não pode ser congelado nem movimentado por uma parte autorizada contra a vontade do titular não consegue representar esse lote perante um banco, um tribunal ou um regulador. O ERC-3643 resolveu isso para valores mobiliários em 2021; o ERC-7943 o generalizou para qualquer ativo do mundo real e atingiu o status Final em maio de 2026, com uma variante para ERC-1155. O A-REX adota essa interface literalmente, em vez de definir a sua própria, para que mecanismos de conformidade que reconhecem o ERC-7943 (Chainlink ACE, ferramentas do ERC-3643) reconheçam um token A-REX sem adaptação.

A variante multi-token se ajusta naturalmente ao ERC-1155: o congelamento é por conta e por identificador de lote, as transferências forçadas indicam o lote e a elegibilidade é por conta.

Um único hook, ordenado, com códigos

Um sistema de módulos baseado em cinco interfaces de capacidade, cada uma sondada com supportsInterface a cada transferência, não escala; com oito módulos e cinco ids em uma transferência múltipla, eram oitenta chamadas estáticas antes de qualquer regra ser executada. As rejeições eram strings livres que nenhum indexador conseguia interpretar e nenhum teste conseguia comparar de forma confiável.

O A-REX Core define uma única interface de hook, com um bitmap constante de flags armazenado em cache no registro. O token avalia os hooks em uma ordem fixa e para no primeiro código bytes32 diferente de zero, revertendo com ARexHookRejected(hook, code). A ordem é auditável (getHooks), a remoção a preserva e um hook descobre o token chamador por msg.sender, de modo que uma única implantação atende a muitos tokens. A elegibilidade (canSend/canReceive) é incorporada à mesma interface, de modo que as views do ERC-7943 do token são a conjunção de seus hooks.

Por que códigos, e não erros personalizados vindos do hook? Porque check é uma view que precisa ser componível: o token precisa perguntar a cada hook, comparar as respostas e expor a primeira delas por transferCheck sem reverter. Os códigos são baratos, indexáveis, traduzíveis e com namespace (keccak256("AREX:BATCH_EXPIRED"), keccak256("MYHOOK:QUOTA")).

Atestações por lote, emissores por tópico

Certificar um produtor é um problema de identidade com soluções maduras (ONCHAINID, Ethereum Attestation Service, credenciais verificáveis, e-ID nacional). Certificar um lote é o que compradores, autoridades aduaneiras e reguladores verificam, e isso não tinha uma forma padrão. IARexAttest registra (batch, topic) → (issuer, reference, validity) e permite que um administrador decida qual emissor pode atestar qual tópico, espelhando o registro de emissores confiáveis do ERC-3643 sem prescrever um provedor de identidade. Os tópicos são bytes32 abertos, de modo que tópicos de declaração do ERC-735, identificadores de esquema do EAS e hashes de nomes de certificação coexistem.

isAttested é a única pergunta que um hook faz: é falso se a atestação estiver ausente, revogada, expirada ou se seu emissor tiver perdido a confiança. Isso permite que um hook imponha "lotes de café precisam de uma referência de devida diligência do EUDR antes de poderem ser vendidos" em seis linhas.

O emissor de uma atestação sempre pode revogá-la, e um revogador que ele tenha delegado também pode, como acontece com as listas de status de credenciais do W3C e com os emissores de declarações do ERC-3643. No rascunho proposto com o ADR-019 (Proposto), um administrador do token ou do contrato de atestações não deveria poder revogar na 2.x uma atestação que não emitiu, e não deve poder a partir da versão 3.0; uma implementação 2.x que mantenha esse poder o documenta para os emissores e para quem confia nas atestações. Um operador que considere um certificado incorreto não o revoga: ele o marca como contestado off-chain e avisa o emissor; um token que deixa de confiar em um emissor o remove do tópico, o que torna as atestações desse emissor falsas para esse token.

O que o padrão não diz

• Não diz quem pode criar lotes, alterar o status ou exercer o enforcement — apenas que se trata de papéis, e nunca de saldos.
• Não diz o que significam os status 1..254; o emissor publica uma tabela nos metadados.
• Não diz como valorar um lote, como ele decai, quando pode ser negociado sazonalmente, como é entregue ou segurado: tudo isso são hooks ou contratos complementares.
• Não diz qual blockchain, qual provedor de identidade, qual oráculo, qual registro.
• Não diz se o token é um valor mobiliário ou uma commodity.
• Não diz quem pode usar uma capacidade, se ela está ativada nem quais listas e autoridades se aplicam: quem detém o papel de enforcement, quem pode pausar, quais listas de sanções contam. O ADR-019 (Proposto) coloca isso em um perfil de política versionado por jurisdição e por organização, de modo que uma mudança na lei seja uma atualização do perfil, e não um novo contrato nem uma nova versão do padrão.

Lições que moldaram o projeto

Compatibilidade retroativa

Os tokens A-REX Core são tokens ERC-1155 e ERC-7943 completos. Carteiras, marketplaces e indexadores que conhecem o ERC-1155 funcionam sem alterações; as ferramentas de conformidade que reconhecem o ERC-7943 identificam a superfície de enforcement. Os mecanismos de regras escritos para outros tokens se conectam por meio de um adaptador IARexHook, desde que suas decisões dependam apenas dos parâmetros da chamada e do registro do lote.