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.

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.

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.

Implantação cross-chain

O padrão é agnóstico quanto à blockchain. 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.

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