Whitepaper · 06

Padrão do Núcleo

A fundamentação de cada elemento do A-REX Core: por que o registro de lote tem exatamente estes campos, por que a linhagem é uma operação e não um mapeamento, por que o enforcement vem do ERC-7943, por que códigos substituem enums e quais lições moldaram o projeto.

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

Campo	Por que está on-chain	Por que tem esta forma
`commodity: bytes32`	hooks, marketplaces e reguladores precisam filtrar por produto sem interpretar os metadados	`keccak256("HS:100199")` aceita qualquer esquema (HS, FAO/CPC, GTIN, códigos nacionais) sem uma tabela no padrão; uma enum congelaria a lista mundial de culturas na implantação
`unit: bytes32`	quantidades não têm sentido sem uma unidade; uma transferência de `1000` equivale a 1000 kg ou a 1000 caixas	a Recomendação 20 da UN/CEFACT é a lista de códigos usada por EDI, EPCIS e alfândegas
`producedAt: uint64`	perecibilidade, sazonalidade e contratos a termo dependem todos da data de produção	`0` significa "ainda não produzido": recebíveis de safra, contratos a termo e warrants sobre colheitas futuras são os instrumentos de financiamento agrícola predominantes na América Latina e devem poder ser representados
`expiresAt: uint64`	a regra de transferência mais comum na agricultura é "não depois desta data"	`0` significa nenhuma; os hooks decidem o que a expiração implica
`originRef: bytes32`	a origem deve ser comprovável (EUDR, orgânico, indicações geográficas)	um hash ou uma referência, nunca coordenadas: a geolocalização de parcelas de um produtor é dado pessoal (Diretrizes 02/2025 do EDPB, v2.0, julho de 2026) e uma rede pública imutável não pode atender a pedidos de apagamento
`metadataHash: bytes32` + `uri`	todo o resto está off-chain, mas o token precisa se comprometer com esse conteúdo	hash de um documento JSON canônico que segue um esquema publicado; `uri` pode ser IPFS, HTTPS ou um GS1 Digital Link
`status: uint8`	um lote percorre um ciclo de vida e alguns estados devem bloquear a movimentação	valores abertos com dois pontos fixos (`0` ativo, `255` baixado); a enum anterior de nove estados codificava o vocabulário de uma única cadeia de suprimentos e era alterável por qualquer titular
`issuer`, `createdAt`	responsabilização e auditoria	definidos pelo contrato, nunca pelo chamador

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), mas exige TRANSFORMER_ROLE para alterar a natureza ou a quantidade dos bens — um moinho pode transformar trigo em farinha, um produtor não pode transformar trigo em ouro.

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 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.

Lições que moldaram o projeto

Lição	Consequência no A-REX Core
Um padrão que inclui um registro de propriedades rurais e um sistema de identidade como OBRIGATÓRIOS não é um padrão de token, é um produto	nada fora do token é obrigatório
Uma enum fechada na assinatura de uma função torna qualquer "registro dinâmico" de commodities código morto	commodities, unidades, status e tópicos são códigos abertos
Autoridade derivada do saldo é uma vulnerabilidade em um token com múltiplos titulares	as alterações de status são restritas por papel; RETIRED é terminal
Lógica de negócio no núcleo contradiz um "núcleo sem lógica de negócio"	valoração, decaimento e janelas ficam em hooks
Um build que não compila a partir de um clone limpo não é uma implementação de referência	dependências com versões fixadas, arquivo de lock versionado, CI a cada push
As datas regulatórias em um whitepaper envelhecem; o código que depende delas não deve envelhecer	o token armazena referências e hashes, nunca lógica regulatória

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.