The asset data
The notes are the liability side. This page is the asset side: what secures them, how it is recorded, and who can read what.
61 tokens
The demo pool holds twenty electric vehicle leases. Each one produces three tokens, and the pool itself produces one.
| Family | Count | Contains |
|---|---|---|
| Auto | 20 | Vehicle identity, model, mileage, current and residual value |
| Battery | 20 | Manufacturer, chemistry, capacity, state of health, charge cycles |
| Obligor | 20 | Anonymized borrower, country, region, and the loan record |
| Pool | 1 | Aggregates, references to all the others, and the deal contract |
Each token is on chain with its own IPFS address. You can count them on the explorer: auto, battery, obligor, pool.
How the tokens are linked
Three mechanisms, stacked.
The VIN joins the vehicle side. The auto, battery and obligor tokens of one vehicle all carry the same vehicle identification number. It is the key the physical world already uses, so nobody has to invent one.
The pool token holds hard references. Its metadata contains a table mapping every VIN to the content addresses of its three child tokens, plus the addresses of the four token contracts and of the deal contract. A content address is a hash of the file. Change one byte of a battery record and its address changes and no longer matches what the pool token recorded. That is what makes the reference worth something.
The deal points back. The pool token names the abs-deal contract, so the
asset side and the liability side reference each other rather than being two
disconnected stories.
Batteries will move to their own identifier, the BIN, rather than the vehicle's VIN. A battery outlives the car it was fitted to. It gets swapped, replaced, and eventually reused in a stationary installation, and its passport should follow it. The EU battery regulation requires a unique battery identifier for the same reason. The vehicle VIN stays as a cross reference to whichever car it is in today.
What is public and what is sealed
Not everything belongs in the open. A metadata document can carry a
confidential section, and the backend seals it before storage with AES-256-GCM.
The rest of the document stays readable.
On the obligor token, the anonymized identifier, the country and the region stay public. The credit band, the employment status, the outstanding principal, the rate and the arrears status are sealed. That is the split real deals make: pool aggregates are published, loan level detail goes to an authorized data room.
The design is deliberately small, because a key management system nobody maintains is worse than none:
- One key for the deal, in the environment, not a key server.
- One place in the code where sealing happens, so it cannot be forgotten. Sealing a document with a confidential section and no key configured fails rather than publishing it in clear.
- The content address still addresses the whole document, so the pool token's references and every integrity check work exactly as before. Only the content is opaque.
An authorized reader gets the clear view through a token protected endpoint. The public gateway keeps serving the sealed bytes.
Erasure
Data on a content addressed store cannot be deleted, which is a problem when somebody exercises their right to be forgotten. The answer is to destroy the key. The sealed sections become permanently unreadable, and the requirement is met. Here that means removing one line from the environment.
The 61 tokens minted so far are in clear, because the demo pool is synthetic and contains no personal data. Sealing applies from the next mint.