Interoperabilidade

Com o ecossistema Ethereum

Um token A-REX Core é um token ERC-1155. Carteiras, exploradores, marketplaces e indexadores que entendem o ERC-1155 funcionam sem alterações: saldos, transferências múltiplas, uri(id), aprovações, verificações do receptor em transferências seguras. O A-REX acrescenta eventos e views; não remove nada.

Um token A-REX Core é um multi-token ERC-7943. Os mecanismos de conformidade e as plataformas de custódia que têm o ERC-7943 como alvo (o Automated Compliance Engine da Chainlink demonstrou compatibilidade; as plataformas de emissão da coalizão do ERC-7943 o estão adotando) reconhecem canTransfer, forcedTransfer, setFrozenTokens, canSend e canReceive sem adaptação.

Com os padrões de dados de rastreabilidade

GS1 EPCIS 2.0 / CBV

O padrão publica um mapeamento informativo, evento por evento:

O esquema de metadados usa de propósito os nomes do EPCIS/CBV, para que um exportador mapeie campos, e não conceitos.

Leituras de sensores não fazem parte do núcleo. Um hook de entrega pode registrar uma temperatura na cadeia; as demais medições (umidade, CO₂ e O₂, impacto, inclinação, porta, posição) ficam fora da cadeia na mesma sensorElementList, com seu tipo CBV e sua unidade da Rec. 20. O mapeamento descreve um padrão para se comprometer com elas: por janela de tempo, a pior leitura de temperatura com uma referência que é uma raiz sobre cada leitura da janela e a mensagem original de onde veio, para que um auditor possa conferir uma leitura com a cadeia. O compromisso prova o que quem registrou tinha naquele bloco, não que o dispositivo mediu corretamente. Pontos de leitura e locais de negócio são identificadores de site, nunca coordenadas.

UN Transparency Protocol (UNTP 0.7.0)

Um mapeamento informativo converte um lote, os seus eventos e as suas atestações em credenciais do UNTP 0.7.0, com os mesmos identificadores do mapeamento EPCIS, para que os dois possam ser cruzados:

As credenciais seguem o W3C Verifiable Credentials Data Model 2.0 e são assinadas com VC-JOSE-COSE sob o did:web do emissor; a revogação usa uma Bitstring Status List. Uma credencial assinada também pode ser ancorada ao seu lote como uma atestação cuja referência é o hash da credencial; a âncora prova o compromisso, a assinatura prova o conteúdo. Uma credencial traz apenas o que o token ou os seus metadados contêm, e os valores que exigem um método (uma pegada, uma pontuação de risco) só aparecem quando uma parte identificada os declarou. O mapeamento declara o que não cobre, a começar pelo Passaporte Digital de Produto da UE: o ESPR não se aplica a alimentos, rações nem a plantas e animais vivos, e o A-REX não faz nenhuma afirmação de passaporte para eles.

O local onde os bens foram produzidos é dado em códigos: o país (ISO 3166-1), a subdivisão de primeiro nível (ISO 3166-2, por exemplo BR-MG) e o UN/LOCODE de uma cidade apenas para um local comercial, como um armazém ou um porto, nunca para uma fazenda. Leituras de sensores vão no sensorData do MoveEvent da entrega; um passaporte traz no máximo um resumo. A partir do esquema de metadados 1.3.0 (ADR-024, Proposto), origin.region é sempre um código assim.

Pegadas de carbono declaradas (PACT 3.0.3)

O ADR-018 (Proposto) permite que um lote traga uma pegada de carbono de produto calculada por um terceiro, em extensions.pact_pcf do documento de metadados. O fragmento segue campo a campo as WBCSD PACT Technical Specifications 3.0.3: quem a declarou, a unidade declarada e o período de referência, a pegada com e sem a absorção biogênica e um status de verificação obrigatório que indica o verificador quando a pegada é verificada. Ela é copiada, nunca calculada, somada nem transmitida aos lotes feitos a partir do lote, e não é um crédito de carbono (ADR-014). O mapeamento é um derivado separado do PACT e não copia nenhum arquivo do PACT.

Códigos de commodity e de unidade

Um código de commodity é keccak256("<SCHEME>:<CODE>") para qualquer esquema: o Sistema Harmonizado (HS), nomenclaturas tarifárias nacionais (NCM no Mercosul, CN e TARIC na UE, HTS nos Estados Unidos, entre outras), FAO, CPC, GTIN ou um esquema próprio do emissor. Desde o esquema de metadados 1.1.0, o esquema no documento também é aberto, de modo que os metadados podem espelhar o código on-chain. As unidades são códigos da Recomendação 20 da UN/CEFACT (KGM, TNE, LTR), a lista que EDI, EPCIS e alfândegas já usam.

FSMA 204

Os elementos-chave de dados são campos de metadados (traceabilityLotCode, GLN, datas, quantidades) e eventos; o CTE de transformação é BatchTransformed; a solicitação de registros em 24 horas é uma consulta ao indexador. Consulte o capítulo regulatório para o mapeamento completo.

Codex, ISO 22000, GLOBALG.A.P., esquemas orgânicos

Todos são tópicos de atestação. O padrão não os enumera: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") são convenções que o emissor publica com seu esquema de metadados.

Com registros de documentos jurídicos

Os tokens A-REX referenciam instrumentos jurídicos; não os substituem até que uma jurisdição reconheça o próprio token:

Com sistemas de identidade

O token pergunta apenas canSend(account) / canReceive(account). Por trás dessa pergunta pode haver:

• uma lista de permissão/bloqueio mantida pelo emissor (EligibilityHook);
• um registro de identidade ONCHAINID com tópicos de declaração (o modelo do ERC-3643);
• atestações do Ethereum Attestation Service sobre a conta;
• credenciais verificáveis validadas off-chain e refletidas on-chain por um relayer;
• um esquema nacional de e-ID (carteira eIDAS 2.0 na UE) por meio de um verificador de credenciais.

Nenhum deles faz parte do padrão, razão pela qual um emissor no Brasil e outro na Alemanha podem usar provedores diferentes e continuar interoperáveis.

Com mecanismos de regras e plataformas

Uma regra ou um módulo adicional pode publicar um descritor arex.module/1: um documento JSON com os seus parâmetros, configurações, campos de lote exigidos, tipos de certificado, eventos, códigos de rejeição e como o seu estado passa para uma nova versão. Uma plataforma, carteira, indexador ou auditor que lê descritores integra uma nova regra sem código personalizado. O formato é informativo e está Proposto; passa a ser um formato recomendado quando um segundo implementador independente o consumir. A revisão 1.1 acrescenta uma lista opcional e informativa ops com as operações que uma regra governa; ausente, significa desconhecidas, e nunca é usada para aplicar controles. A revisão 1.2 acrescenta o tipo de local ref:site (o originRef que os seus lotes carregam, nunca uma localização) e diz que o gás declarado é medido com as configurações preenchidas (gas.setup opcional). A revisão 1.3 documenta os campos que o seu primeiro consumidor já escreve (ações, erros próprios do contrato, medidas, o dado por entrega e uma forma completa dos eventos), todos opcionais. A revisão 1.4 acrescenta o que uma plataforma precisa para montar formulários de módulos adicionais: mais tipos de valor, o que chega ao registro (nunca dados pessoais), apresentação e verificações por campo, visualizações somente leitura e como um registro é levado ao EPCIS e a um passaporte UNTP (uma característica declarada pela sua organização, nunca uma alegação). A revisão 1.5 adiciona sal a cada impressão digital: um descritor que declara fingerprint: { "scheme": "salted-jcs/1" } registra o hash de cada valor junto com seu próprio sal de 32 bytes, para que textos curtos, números ou contornos de talhões não possam ser encontrados testando candidatos. A revisão 1.6 acrescenta medidas que não são totais (avg, min, max de um campo numérico, nunca somadas entre grupos nem entre empresas) e duas formas de agrupá-las, pela parte que criou o lote (party) e pelo seu local (site); o modelo do complemento de umidade da versão de referência 2.0.0-alpha.10 a usa para a umidade média no recebimento. A revisão 1.7 permite que o visibleWhen de um campo use a árvore de condições do descritor de vocabulário (all, any, not; no máximo 3 níveis e 12 folhas) sobre os demais campos do formulário; a condição única da revisão 1.4 continua válida, mas obsoleta.

As organizações podem publicar seus próprios tipos de trabalho de campo, tipos de processo e listas de etapas como definições de vocabulário arex.vocab/1. Cada uma é associada a uma de 26 classes de etapa de referência (por exemplo drying ou fermenting) e a um passo de negócio GS1 CBV. Seus eventos EPCIS levam três camadas: o bizStep CBV que qualquer sistema EPCIS lê, a classe de referência (arex:stageClass) que permite que duas organizações com nomes diferentes comparem seus registros, e o tipo, os nomes e os valores publicados da própria organização. Em um passaporte UNTP os valores são características, nunca alegações. Os metadados de um lote processado podem nomear o tipo de processo e a execução por trás dele em um objeto process, previsto para o esquema de metadados 1.4.0. A revisão 1.1 acrescenta um layout opcional de formulário (seções, larguras, condições) que apenas restringe o que os campos aceitam. A revisão 1.2 permite que as condições usem not, cheguem a 3 níveis com até 12 folhas e leiam o contexto do registro em códigos (a cultura como código EPPO, dias desde o plantio, tipo de local, país, posição SH do produto, última etapa); contexto desconhecido é lido como vazio. A revisão 1.3 acrescenta a ordem de uma lista de etapas (order): strict (o padrão; uma etapa anterior obrigatória deve ser registrada antes) ou flexible (qualquer ordem, lacunas ficam para os relatórios). A revisão 1.4 acrescenta métodos de processamento do café (washed, natural, honey, pulped_natural, wet_hulled, anaerobic e outros) que um tipo de processo dá às suas saídas e que os metadados process de um lote levam: uma declaração da organização, não uma certificação. A revisão 1.5 acrescenta subclasses das classes amplas (separating, conditioning, sorting_grading, heat_treating) de uma lista fechada, de modo que um leitor só associa a etapa de outra organização de uma classe ampla pela sua subclasse ou por um mapeamento explícito por remetente. A revisão 1.6 acrescenta to_processor, uma subclasse de transporting: mercadoria enviada a um processador que a trabalha para o seu dono (prestação de serviço), de modo que muda a custódia e não a propriedade. As etiquetas no livro-razão, as referências de etapa e os sujeitos de local levam sal, de modo que nenhum fluxo de processo nem a cronologia de uma fazenda pode ser lido no livro-razão, e valores em dinheiro nunca são escritos em claro no livro-razão. Uma etapa de embalagem ou de carregamento registrada com uma unidade logística (um SSCC, um número de contêiner) corresponde a um AggregationEvent do EPCIS. Na versão de referência 2.0.0-alpha.9, o CompanyFactsHook grava esses registros no livro-razão e o RequireStageHook recusa entregas de lotes aos quais faltam as etapas exigidas; nenhum dos dois módulos é obrigatório. Tudo é informativo e Proposto.

Implantação cross-chain

O A-REX Core é um padrão EVM (ADR-026, Proposto): um token conforme funciona em qualquer rede EVM de nível paris ou posterior, e o padrão não mantém lista de redes; as que uma organização pode usar são definidas pelo seu perfil de políticas. As redes são identificadas por ids CAIP-2, como eip155:8453 ou hedera:mainnet. Modelos práticos:

• Uma única rede de origem por emissor (recomendado): a linhagem e o enforcement permanecem coerentes; as demais redes mantêm representações encapsuladas por meio de adaptadores no estilo ERC-7802 ou do CCIP.
• Rede EVM permissionada para emissores cuja autoridade de proteção de dados ou instituição âncora a exija; o EDPB favorece expressamente projetos permissionados. Mesmo bytecode.
• Espelhos para liquidez: um identificador de lote na rede de origem, um wrapper ERC-20 em outra; o wrapper deve respeitar canTransfer do token de origem ou restringir-se a titulares elegíveis.

A linhagem nunca atravessa redes; as referências, sim. Entre tokens da mesma rede ou de redes diferentes, um lote feito a partir do lote de outro token o indica na lista upstream dos seus metadados (esquema 1.2.0) por chain id, contrato e id do token. Essas referências são afirmações do emissor, a serem confrontadas com o token a montante. A partir do esquema 1.4.0 (Proposto), uma entrada também pode indicar a rede CAIP-2 (network), e um lote registrado em uma rede que não é EVM é indicado pela sua rede e pelo seu ativo CAIP-19.

Registros que qualquer pessoa pode verificar, em qualquer rede

A evidência em torno de um token não depende da rede do token. Uma vez por período, um emissor pode combinar as impressões digitais dos seus registros (seu log de auditoria, relatórios, documentos) em uma única raiz de Merkle e publicar esses 32 bytes em várias redes independentes: sua própria rede EVM, o Bitcoin por meio do OpenTimestamps e o Hedera Consensus Service. Cada registro recebe uma prova arex.anchor-proof/1 curta. Quem tiver o registro e sua prova pode verificar, sem nenhum serviço da A-REX, que o registro existia sem alterações, no máximo, no momento em que cada rede recebeu a raiz; um contrato EVM pode verificar a mesma prova com o MerkleProof da OpenZeppelin. Só são publicados hashes, nunca dados pessoais. O formato é informativo e Proposto (ADR-026). Em quais redes um emissor ancora é uma questão de política, definida pelo seu perfil de jurisdição ou de organização, e uma prova é válida com qualquer número de recibos. Um recibo do Hedera indica o id da sua transação quando a raiz é enviada e ganha o número de sequência e o horário de consenso da mensagem assim que um nó espelho público a confirma.

De onde vêm os números de um relatório assinado

Um relatório calculado a partir dos registros de um emissor, como "1 200 kg entregues a um comprador em outubro" ou uma lista de registros, pode levar as suas fontes: uma linha por registro lido, com o lugar onde o livro-razão guarda esse registro e os valores que o relatório usou. Cada linha é uma fonte arex.report-sources/1; sua folha é keccak256(0x03 ‖ JCS(source)), e as folhas ordenadas são emparelhadas até uma única raiz das fontes. A raiz e o SHA-256 do arquivo de fontes (<report>.sources.csv) são selados com o relatório, no seu manifesto assinado ou sob a assinatura de um PDF, de modo que depois nenhuma linha pode ser acrescentada, removida ou alterada. O relatório diz quantos dos seus registros se verificam contra o livro-razão, quantos por meio de uma impressão digital no livro-razão (uma âncora diária ou uma janela de leituras) e quantos são apenas registros do emissor, cobertos pelo seu selo. Uma fonte nunca contém um valor pessoal em claro. Um leitor verifica tudo sem nenhum serviço da A-REX: o verify-sources.mjs, um verificador autônomo (Node.js 20, nada a instalar) que qualquer implementação pode distribuir, recalcula cada folha e a raiz, compara-as com o relatório e depois lê cada registro do livro-razão em qualquer nó da sua rede. Um relatório com vários cartões mantém um só arquivo de fontes e uma só raiz; cada linha nomeia o seu cartão no membro opcional section (revisão 1.1), de modo que os números de cada cartão se somam à parte.

node verify-sources.mjs report.csv.sources.csv --manifest report.csv.manifest.json --rpc https://<a node of the network>

O formato é informativo e Proposto (revisão 1.1 das fontes de relatório). O documento do padrão, compartilhado por acesso antecipado, traz as colunas do arquivo, cada verificação e um vetor de exemplo; o esquema descreve uma fonte.

Com sistemas de gestão de propriedades rurais e ERP

Os pontos de integração são os mesmos de qualquer token ERC-1155, mais as views de lote:

• Caminho de escrita: um serviço de originação detém ISSUER_ROLE e chama createBatch a partir de eventos do ERP (ticket de balança, emissão de recibo); setBatchStatus/setBatchMetadata a partir de eventos do armazém; transform a partir de ordens de processamento.
• Caminho de leitura: um indexador materializa lotes, linhagem, atestações e eventos de enforcement nas tabelas de rastreabilidade do ERP; exportação EPCIS para parceiros e reguladores.
• Verificação prévia: transferCheck permite que um ERP explique uma recusa a um operador antes de enviar uma transação.
• Identificadores: as chaves GS1 nos metadados fazem a ponte com repositórios EDI e EPCIS existentes; as unidades UN/CEFACT já estão nos ERPs.

Matriz de compatibilidade