ARU · Canton Network

Physical metal, held in reserve.Issued as a token on Canton.

ARU's Canton registry is a set of Daml contracts that mint, move and redeem tokens against attested physical reserves. Below: what the ledger says right now, how the protocol works, and what it will refuse to do.

Live on the ledger

What is attested, and what is in issue.

Read from the participant on every refresh. Attested is the quantity the instrument's attestor has signed for; in issue is the figure the dually‑signed supply record carries. The bar draws one against the other on a single scale, so supply that exceeded reserves could not look like a full bar.

Why Canton

A ledger that enforces the rules, and shows them to nobody else.

Canton is not a public chain and not an EVM. Four properties of it are the reason the reserve logic can be written as contract code rather than as an application nobody can inspect.

Daml
Rules live in the contract. A Daml template names its signatories and its choices, and the network will not record a transaction that breaks one of its conditions. A guard in ARU's code is not a check an application performs before submitting; it is a condition the ledger itself refuses to violate.
Privacy
A participant stores only the contracts it is a stakeholder on. A holder sees their own holdings. The issuer sees every movement in its own registry, because it signs every holding. Anyone else sees nothing—there is no public explorer to read a counterparty's position off. It is also why the operator band at the bottom of this page is gated.
Synchronizer
Each institution runs its own participant node, and they agree on ordering through a shared synchronizer rather than by replicating one global state. That is what lets two parties settle a trade without publishing it.
Token standard
ARU implements the Canton Token Standard—holdings, transfer instructions and holdings‑change events—in both V1 and V2. A wallet that has never heard of ARU can list a balance and send one, and a wallet following the event log can learn that a holding appeared, moved or went away.

Who holds which key

Four roles. None of them can issue a token or release metal alone.

That is the entire design. Everything below is a consequence of it.

IssuerRegistry admin
Price a mint, price a redemption, and sign every holding in the registry.
Mint. Execute is the reserve holder's choice. Nor change the supply record or the required attestor, which take two signatures.
AttestorIndependent
State what metal is held, how much, and as of when.
Anything else. It never touches a holding, and signing an attestation does not mint against it.
Reserve holderCustody side
Execute a mint and execute a redemption—the two moments reserves are committed or released.
Set a price. ApproveNav and ApproveProceeds belong to the issuer, and neither choice can be skipped.
HolderAnyone
Hold, send, accept, request a redemption, and withdraw that request up until the issuer prices it.
Mint, or spend a locked holding. A lock is refused as a transfer input.

The sharp edge. Anyone on the network can sign a reserve attestation, the issuer included—ReserveAttestation has one signatory, so nothing prevents it. What makes attestation mean anything is requiredAttestor, a field on the dually‑signed supply record that the issuer cannot change by itself. A mint checks the attestation it is given against that field, so an attestation the issuer signed for itself is refused at execution. The attestor named in the facts at the top of this page is that field's value, read from the ledger.

Flow 01 · Issue

A mint takes three parties and four steps.

01 ATTESTOR signs for the metal ReserveAttestation 02 ISSUER proposes the mint MintBatch 03 ISSUER approves the NAV navApproved = true 04 RESERVE HOLDER executes the mint Holding · supply up ATTESTOR ISSUER RESERVE HOLDER DUAL CONTROL
The copper line is the whole point: the party that prices the mint is never the party that executes it. Execute is controlled by the reserve holder and checks eight things about the attestation and the supply record before it creates a single token.

The ledger refuses, in its own words

  • only allocated metal may back this mint
  • the batch names an attestor the instrument does not
  • supply would exceed attested reserves
  • declared supply does not match the ledger
  • attestation is stale
  • NAV has not been approved by the issuer

Flow 02 · Transfer

A send locks the amount rather than handing it over.

01 SENDER instructs the send inputs archived 02 LOCKED held for the receiver lock = receiver, admin the sender cannot spend it 03 RECEIVER accepts Holding → receiver RECEIVER OR SENDER rejects or withdraws returns unlocked
Between the two steps the tokens sit in a holding the sender still owns and cannot move, with the receiver named on the lock. Either side can end it early and the amount comes back unlocked. When the receiver authorises alongside the sender, there is no lock and no instruction—the transfer settles in one step, as the standard recommends.

The ledger refuses, in its own words

  • an input holding is locked
  • the input holdings do not cover the transfer
  • an input holding is not in the sender's account
  • only the receiver can accept
  • the execution window has already closed

Flow 03 · Redeem

The same control, read backwards.

A mint asks whether an independent attestor has said the metal is there. A redemption asks whether the issuer has priced the exit and the reserve holder has agreed the metal may leave. So it is the same two parties in the same order, and anyone who has read the mint path already knows how to read this one.

01 REDEEMER requests, and the amount locks RedeemRequest · not yet burned 02 ISSUER approves the proceeds must clear the redeemer's floor 03 RESERVE HOLDER executes the burn Holding gone · supply down REDEEMER ISSUER RESERVE HOLDER DUAL CONTROL
The redeemer names a floor when they ask—the least they will accept—so a price that has moved against them cannot be imposed silently. Before the issuer prices it they can withdraw and get the amount back; after the window closes, either the redeemer or the reserve holder can expire it. The tokens are locked throughout, never taken, until the burn.

The ledger refuses, in its own words

  • the approved proceeds are below the floor the redeemer set
  • the issuer has not priced this redemption
  • this redemption has already been priced and can no longer be withdrawn
  • supply has moved since the proceeds were approved
  • more is being redeemed than is in issue
  • the redemption window has not closed yet

Stated plainly

What is modelled, and what has not been built.

The cash leg does not move on‑ledger yet.

A redemption records which settlement asset it will be paid in (—), the floor the redeemer accepts and the proceeds the issuer approved, and the burn executes against those terms. Paying the redeemer in the same transaction is cross‑registry delivery‑versus‑payment, which on Canton means the token standard's allocation machinery. The terms are modelled now so the payment can settle against them without re‑shaping anything here—and so the money path gets audited once, atomic, rather than twice.

Only allocated metal backs a mint.

The code distinguishes two reserve classes: metal already allocated in custody, and cash received but not yet converted. Today a mint accepts the first and refuses the second, in those words.

Settlement assets are names, not links.

An instrument's accepted settlement assets are recorded as the settlement registry names them, and adding one takes both signatures on a configuration contract rather than a new version of the package. Nothing yet verifies that the named registry exists on the network it is deployed to.

Not every network carries the current package.

The package id in the facts at the top of this page is the one actually on this network, read off a live contract rather than from a build. DevNet and TestNet carry the version described here, redemption included. MainNet carries an earlier one.

Operator

Who holds what, and what is waiting.

Holder positions, mint batches awaiting execution and transfers awaiting acceptance. This band is served only to an authenticated request: those are the facts the token standard's privacy model keeps from other holders, so the server does not put them in the public response at all.

Read-only. This page exercises no choice and holds no key that can move an asset; every request it makes is a query. It reads as the admin party, which is a signatory on every holding, so it can see holder positions—which is why the operator band is gated in the server rather than hidden in the page, and why a screenshot of that band should be treated the way the band itself is.

connecting…