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 esquema de metadados usa de propósito os nomes do EPCIS/CBV, para que um exportador mapeie campos, e não conceitos.

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.

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.

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