Anchoring and networks

Putting entries on chain means sending them in an Ethereum transaction. It gives a settled upper bound on time: once an entry is on chain, anyone can check against the chain that the ledger held it at that moment.

What anchoring proves

What goes on chain is the entry ID, the SHA-256 of all the entry’s bytes, and the entry in turn records the content fingerprint. The content comes first, then the entry, then the ID. An entry ID that appears in a block therefore proves that the entry, and the content it records, existed by that block’s time at the latest.

Every entry carries the ID of the one before it. Once the latest entry is on chain, every entry before it, and the content each one records, gains the same upper bound.

How early

Anchoring gives the upper bound alone. The content may have been written the day before, or ten years before.

Who the author is

What the chain shows is that this key held the fingerprint of this content at that time.

Whether the content is true

Any file has a fingerprint and any fingerprint can go on chain; what anchoring proves is time.

How to weigh a record is set out in What a record proves.

The pending queue

New entries join the “Pending” queue first. The “Pending N” segment in the Records toolbar lists them, and the “This batch” card below the table gives the entry count and the gas estimate. Press “Put all on chain”, or “Put on chain now” on one entry’s detail page, and the “Put on chain” card opens:

1. The card shows “Entry count” and the “Gas cap”; the gas estimate is under “Details”.
2. Once the estimate is in, press “Confirm and send”: the app signs, sends the transaction and waits for the receipt.

All entries in a batch travel in one transaction for the cost of one transaction; the more entries, the smaller each one’s share.

The gas cap is worked out from the base fee of the latest block: (base fee × 2 + tip) × gas limit. If reading the base fee fails, it is taken as 0.0006 ETH. The transaction goes out once the balance covers the cap; when it falls short, the message gives the amount needed and the balance at hand, with “Copy address” for topping it up.

After sending

• In a block within 30 seconds: the toast reads “Put N on chain”.
• Still outside a block after that: the toast reads “Submitted N, waiting for confirmation”, and the app asks for the receipt again every 15 seconds.
• Quit and reopen the app, and it keeps waiting for that transaction’s receipt; each batch is sent once.
• If the receipt shows the transaction failed, the entries stay in the queue and can be sent again.

On-chain states

Anything that requires “Confirmed”, such as choosing a record when drafting a grant, accepts this session’s check alone.

Auto put on chain. The “Auto put on chain” switch in Settings › Network is off out of the box. When it is on, the write button reads “Send to chain now”, and after writing the app estimates gas and opens the “Put on chain” card straight away. It applies to every kind of write: records, grants, revocations and so on.

Ledger check

The ledger check compares every local entry with the anchors on chain. It runs on the interval in Settings › Notifications, 300 seconds out of the box; straight away whenever the ledger has changed (a new entry written, a batch put on chain); and whenever you press Sync. It needs nodes, chain ID and registry contract all set.

The ledger status line at the top of the Ledger page reads “OK” or “Problems”; click it for the check card, with a light and a count for each item: on chain, not on chain yet, mismatched on chain, imports unproven, unrecognized types, malformed entries and so on. The ledger is “OK” when there is a check result, the chain is intact and every problem item is zero; entries still waiting to go on chain count as fine. When the result is a broken chain, the whole ledger becomes read-only and the broken-chain bar appears at the top of the page, with “Go to Restore”.

Frequency and precision

Entries written between two anchorings all take the later anchoring as their upper bound. Anchor once a month and time is precise to a month; once a day, to a day. More frequent anchoring costs more and dates more precisely. A ledger anchored every few days over several years carries a different weight from one begun yesterday; the readings on the record kit export page give three numbers for this, see Depth.

Networks

Step 3 of the wizard sets this machine’s network. The app comes with two networks, each with two public nodes from different providers so that their answers can be cross-checked:

With “Ethereum mainnet”, when the current data folder still lacks chain settings, the app fills in the chain ID, registry contract, start block and two public nodes for you. Anchoring on mainnet costs real ETH.

Trying it on the testnet. Choose “Custom” in wizard step 3, then in Settings › Network press “Edit nodes…”, enter 11155111=https://sepolia.gateway.tenderly.co 11155111=https://rpc.sepolia.ethpandaops.io and press “Save nodes”; then fill in the chain ID, registry contract and start block and press “Save chain settings”.

Custom. Nodes are written as chain-id=node-url, separated by spaces. Once you have saved your own values, the “Network” row reads “Custom”.

Nodes

The app reads the chain and sends transactions through the nodes you configure. The “Chain reading” row in Settings › Network says how many nodes agree; when a single node responds, it says the reading comes from one source. For https:// nodes the certificate and host name are checked on every connection, and the chain is read once the certificate passes.

Public nodes can see the addresses and contracts you query. If that concerns you, switch to a node of your own.

After anchoring

Anchoring goes one way. What stays on chain is a 32-byte entry ID and the sending address; the content, file names and record names all stay off chain. The sending address is public, and anyone can look up which IDs it has sent.