AXK Network
A verified-state platform for commodity trade.
Read by Banks, buyers, cooperatives, and regulators who each hold a different copy of the same trade.
- Cooperative
- Bank
- Buyer
- Regulator
Four parties, one record, no shared trust anchor.
The problem
A single shipment of a physical commodity touches a cooperative, a buyer, a bank financing the trade, and often a regulator, and each of them keeps its own record of what happened.
Commodity tradeA single shipment of a physical commodity touches a cooperative, a buyer, a bank financing the trade, and often a regulator, and each of them keeps its own record of what happened. A delivery note lives in one filing system, a custody transfer in another, a settlement instruction in a third. None of those records was built to be read by the other parties.
When a dispute surfaces, over quantity, timing, or who held the goods at a given point, resolving it means reconciling documents that were never designed to agree with each other. The parties don't distrust each other out of malice; they simply have no shared, tamper-evident account of the same sequence of events to point to.
What we built
AXK Network
Afrikabal designed the protocol model and built the platform on top of it: a verified-state system that records the real-world events of a trade, delivery, custody transfer, settlement, as structured, auditable entries that every party can read from the same source.
- 01
Schema-typed trade event records — delivery, custody transfer, and settlement each modelled as a distinct, validated record type rather than free text.
- 02
Settlement rails connecting the recorded events to the parties responsible for acting on them.
- 03
A shared audit surface so a bank, a buyer, a cooperative, and a regulator can each read the same underlying record instead of reconciling separate copies.
Engineering notes
Why schema-typed records
A free-text delivery note can say almost anything, which means two parties' notes about the same shipment can drift apart without either side making an error. Typing each event, its fields, its allowed values, what must reference what, turns reconciliation from a manual reading exercise into a structural comparison. Two typed records either match or they don't, and where they don't, the mismatch points at a specific field, not a general disagreement.
Ordering custody, not just recording it
Custody transfer is a chain, not a single fact: a shipment moves through a sequence of hands, and the record has to preserve that order, because a mismatch in ordering is often the actual dispute. That pushed the design toward append-only, ordered event records rather than a single mutable record that gets overwritten each time custody changes.
Designing for parties who don't share a trust anchor
A bank, a cooperative, and a regulator don't necessarily trust the same operator to hold the canonical copy of a trade record. The protocol model has to work without assuming any one participant is the trusted keeper of the truth, a constraint that shaped how settlement events reference and confirm each other rather than relying on a single party's say-so.
Building something like this?
The first conversation is a fit assessment: what you are trying to enable, where we could plug in, and whether the shapes match. No sales script.