One record per farm, published for anyone to run
The Farm Registry Protocol is how Sequestra registers, hashes, anchors and overlap-checks every farm polygon. Version 1.0 is published here in full, with a JSON Schema, test vectors and an open-licensed reference implementation, so any platform, programme or registry can run the same method on its own farms and compare results with ours.
Illustrative mock-up · sample dataFive steps, each one reproducible
Every step is deterministic: given the same polygon and the same record, two independent implementations produce the same hashes, the same registry ID, the same anchor digest and the same overlap result. That is what makes the layer shareable.
Canonicalise the polygon
The farm outline is a GeoJSON polygon in WGS84. Rings are closed, oriented by the right-hand rule, cleaned of repeated and collinear vertices, rounded to 7 decimals and rotated to start at their smallest vertex. The same land always gives the same bytes.
Hash the record
The record is serialised with RFC 8785 and hashed with SHA-256. A geometry hash identifies the land; a record hash covers the whole baseline. The registry ID is the country code and the first eight hex characters of the geometry hash.
Anchor the digest
A five-member payload (version, registry ID, both hashes, onboarding instant) is hashed once more and that digest is written to any ledger with immutable, timestamped entries. The record keeps a reference to where it was written.
Check every candidate for overlap
Before enrolment, a candidate polygon is projected to an equal-area plane with every registered polygon and intersected. Overlaps of 0.1 ha or 1 % of the candidate are flagged. The earlier registration stays the reference.
Append enrolments, never edit them
Each programme the land joins is appended to the record with its start date. Enrolments sit outside the record hash, so the anchor stays valid and the list becomes the land's history.
Published under an open licence
The specification is CC BY 4.0, the reference implementation and test vectors are MIT. Adopt, implement and redistribute them with attribution.
What is written on the day a farm joins
One JSON document per farm polygon. Four attributes are required: the tenure reference, the land-use history, content hashes of the imagery kept with the record, and the recorded above-ground biomass. Registrants can add their own attributes; everything added is hashed with the rest. The country is a field the registrant supplies, never derived from coordinates, so a border farm has one unambiguous ID.
{
"version": "1.0",
"country": "BR", // ISO 3166-1 alpha-2, supplied
"registrantReference": "0142", // optional, your own reference
"geometry": { "type": "Polygon", "coordinates": [[ ... ]] },
"onboardedAt": "2026-03-14T13:20:00Z", // ISO 8601, UTC
"attributes": {
"tenureReference": "MG-TENURE-0142-SAMPLE",
"landUseHistory": [
{ "from": "2016-01-01", "to": "2026-03-13", "use": "pasture" },
{ "from": "2026-03-14", "use": "restoration" }
],
"imageryReferences": ["0xa1a1…", "0xb2b2…"], // content hashes
"aboveGroundBiomass": { "value": 12.4, "unit": "t/ha" }
},
"enrolments": [ // outside the record hash
{ "programmeId": "restoration-programme-2026", "since": "2026-03-14" }
],
"anchor": { // outside the record hash
"ledger": "example-ledger",
"reference": "entry 184220:7",
"anchoredAt": "2026-03-14T14:02:11Z"
}
}The protocol records the biomass value. How a registrant arrives at it is outside the protocol. Enrolments and the anchor reference sit outside the record hash, for the reasons below.
From the outline to the registry ID
Serialisation is RFC 8785, the JSON Canonicalization Scheme: members sorted, no whitespace, numbers in shortest form. The hash is SHA-256. Worked through for the test-vector farm, about 96 ha in the south of Minas Gerais, Brazil:
{"coordinates":[[[-45.454173,-21.400855],[-45.453529,-21.402253],[-45.451705,-21.401854], … 18 more … ,[-45.454173,-21.400855]]],"type":"Polygon"}- 2 · Geometry hash = SHA-256 of those bytes
- 0xf7a61901b7e7cd7e806489e6fc538402b255b3c53835a7cee1de1e17e48daa9b
- 3 · Registry ID = REG-<country>-<first 8 hex, upper case>
- REG-BR-F7A61901
- 4 · Record hash = SHA-256 of the JCS of the record minus anchor and enrolments
- 0xcb1f3ad1317cc88f3e3574136bddaecca93c89b1f7420f6f680033a756f70aad
The geometry hash identifies the land, whatever encoding the polygon arrived in. The record hash covers the whole baseline. Two polygons with the same registry ID but different geometry hashes are different polygons; the full hash is the identifier of record.
One digest on any ledger that cannot be edited
The protocol is chain-agnostic. Five members make up the anchor payload, nothing else: no coordinates, no attributes, no personal data. Its SHA-256 digest is what goes on the ledger, and the record keeps a reference to where.
{
"version": "1.0",
"registryId": "REG-BR-F7A61901",
"geometryHash": "0xf7a61901b7e7cd7e806489e6fc538402b255b3c53835a7cee1de1e17e48daa9b",
"recordHash": "0xcb1f3ad1317cc88f3e3574136bddaecca93c89b1f7420f6f680033a756f70aad",
"onboardedAt": "2026-03-14T13:20:00Z"
}- Anchor digest = SHA-256 of the JCS of the payload
- 0x6d503040b7e23fb262621dd450ddb63ad69f06106b7508893bc146c2bd39963d
- Anchor reference, kept in the record
- {"ledger":"example-ledger","reference":"entry 184220:7","anchoredAt":"2026-03-14T14:02:11Z"}
Verification
- Validate the record against the schema and canonicalise its geometry.
- Recompute the geometry hash, record hash and registry ID.
- Build the anchor payload and its digest.
- Compare with the digest read back from the ledger, case-insensitively.
Any change to a hashed member after anchoring changes the digest and the comparison fails. Adding an enrolment or the anchor reference itself does not. A verifier needs only the record and the ledger entry, not access to the registrant.
Any ledger with immutable, timestamped entries will do. On a ledger that records events with arbitrary data, one event whose data is the 32-byte digest is enough.
Hectares in common, before anything is enrolled
A candidate polygon and every registered polygon are projected to a Lambert azimuthal equal-area plane centred on the candidate, intersected there, and the intersection measured in hectares. Two thresholds flag an overlap: 0.1 ha, which catches a strip of a large farm, or 1 % of the candidate, which catches most of a small one.
{
"candidateHectares": 100.0054,
"overlaps": [
{
"registryId": "REG-BR-EXAMPLE0",
"hectares": 25.0012,
"shareOfCandidate": 0.249999
}
],
"flagged": true
}What the result means
- The earlier registration stays the reference.
- The registered record, with its onboarding date, anchored baseline and enrolment history, is the reference for the land in common. The candidate does not replace it.
- The decision belongs to the programme owner.
- Decline the candidate, enrol only the part outside the overlap, or enrol it with the overlap disclosed. The protocol supplies the evidence and does not rank programmes.
- Below the thresholds is still reported.
- Every non-zero intersection is listed, largest first; only those at or above a threshold set the flag. A shared boundary with no area is not an overlap.
Verify a record in your browser
The textarea holds the published test-vector record. Press Verify to run the reference implementation on it, or edit a value and watch every hash change. Paste one of your own records to compute its identifiers the same way.
Edit the record or paste your own, then press Verify. The hashes are computed in your browser by the reference implementation; nothing is sent anywhere.
The specification and the schema
Farm Registry Protocol, version 1.0
The full specification: purpose, terms, record, canonical geometry, hashing, anchoring, overlap check, enrolments, conformance, test vectors and licence. Markdown, CC BY 4.0.
farm-registry-protocol-v1.mdRecord schema
JSON Schema, draft 2020-12, for the record. Validate your own records against it before hashing. The reference implementation ships the same schema and a validator.
farm-registry-record-v1.schema.jsonWhat an implementation must do to claim it
An implementation may extend the attributes, use any ledger and add further checks. It must not change the canonical form, the hashed members, the serialisation, the payload, the thresholds or the result shape, since any of those would make its results incomparable with everyone else's.
- 01Writes records that validate against the published schema, with canonical geometry.
- 02Canonicalises exactly as the specification says, and rejects what it rejects.
- 03Serialises with RFC 8785 and hashes with SHA-256, reproducing every published test vector.
- 04Derives the registry ID from the record's own country field, never from coordinates.
- 05Builds the anchor payload and digest as specified and writes the digest to a ledger with immutable, timestamped entries.
- 06Verifies an anchor from a record and a digest alone, with no access to the registrant's systems.
- 07Runs the overlap check before every enrolment and reports the result without taking the decision.
- 08Appends enrolments and never edits them.
See the registry the protocol runs
Farm registry