Check that a lot's information has not been changed

When a lot is registered, A-REX publishes its information (product, quantity, lot code, origin, dates) and records a fingerprint of it on the ledger. The fingerprint is a short code computed from the exact content: change one letter or one digit and it no longer matches. A buyer, an auditor or an authority can therefore check, without an account and without relying on A-REX, that the information they read is the one your company recorded, and since when.

The fingerprint shows that the information was not changed after it was recorded. It does not show that what was declared is true: the ledger records who declared what, and when.

What the fingerprint covers

• Every field of the lot's published information, exactly as it was recorded.
• One version only. A correction publishes a new version with its own fingerprint, recorded with the correction; the earlier version and its fingerprint stay on record and can still be checked. See Correcting a lot's information.
• Not the files of certificates: each has its own fingerprint. See Certificates.

Where the console shows it

1. Open the lot from Lots.
2. Open Technical details at the bottom of the lot page. The long value starting with 0x just above Open the public record is the fingerprint recorded for the lot.
3. Open the public record opens the published information, which anyone can read. Its web address ends with the same fingerprint.

Owners and admins also find it in Technical lots, on the page of each lot.

How anyone checks it

1. Download the published information from its public address, the one Open the public record opens. It contains no personal data.
2. Put it in its standard form, the canonical form of RFC 8785: the fields in a fixed order and no extra spaces, so the same information always gives the same text.
3. Compute the fingerprint of that text with the keccak-256 method.
4. Compare it with the fingerprint recorded for the lot. The same value means the information is the one recorded. Any other value means the copy differs from what was recorded.

Your developers or auditors can do this with a few lines of code; the next section shows how.

For developers and auditors

This section uses technical terms. The fingerprint is the batch's metadataHash, shown as Metadata hash under Technical details: the keccak256 of the RFC 8785 (JCS) canonical serialization of the metadata document, taken over its UTF-8 bytes (AREX-CORE §3.5). The document is served at GET /m/{company}/{metadataHash}.json on the A-REX API, the batch's uri on chain, once the batch is on the ledger (drafts answer 404). The response is the canonical text itself, readable from any origin.

In JavaScript (Node 18 or later), with the canonicalize package (RFC 8785) and viem:

import canonicalize from 'canonicalize';
import { keccak256, toBytes } from 'viem';


const url = 'https://API_HOST/m/fazenda-boa-vista/0x5c1e…9a2b.json'; // Open the public record
const recorded = '0x5c1e…9a2b';                                 // Metadata hash of the lot


const doc = await (await fetch(url)).json();
const computed = keccak256(toBytes(canonicalize(doc)));
console.log(computed === recorded.toLowerCase() ? 'unchanged' : 'different');

With ethers v6 the last step reads keccak256(toUtf8Bytes(canonicalize(doc))). Canonicalizing matters when you check a copy that was re-formatted (indented, keys reordered): the published file is already canonical, so its raw bytes give the same value.

From the command line, with Foundry's cast:

curl -s "https://API_HOST/m/fazenda-boa-vista/0x5c1e…9a2b.json" -o lot.json
cast keccak "$(cat lot.json)"

To compare with the ledger itself rather than with what the console shows, read the batch from the token contract (Token contract, Token ID and Network under Technical details):

cast call "$TOKEN" "batchOf(uint256)((address,uint64,uint8,bytes32,bytes32,uint64,uint64,bytes32,bytes32,string))" "$TOKEN_ID" --rpc-url "$RPC_URL"

The ninth value of the tuple is metadataHash and the tenth is uri. After a correction, batchOf returns the corrected version, and each BatchMetadataUpdated(id, metadataHash, uri) event records a version. Documents declare schemaVersion 1.0.0, 1.1.0 or 1.2.0 (A-REX writes 1.2.0); the check is the same for all of them. Validating the document against its schema is a separate step: any JSON Schema 2020-12 validator with schema/batch-metadata.schema.json of the standard, or POST /v1/metadata/validate with an API key.