How to read root64's on-chain proofs

What can you verify about root64 on-chain?

Two things: the actual movement of cash in root64’s loan pool, and the result of each external check run against that pool. The transparency layer records both as on-chain entries — a cash-transaction record for every money movement, and a verification record for every check against an outside source.

This is the first phase of root64, the real-world-asset (RWA) platform built by 8percent. The platform’s design principle is “transparency before tokenization”: make the underlying Korean loan assets independently checkable first, and tokenize later. This post is the practical companion to that idea — not why transparency comes first, but how to read the records once you are looking at them.

One honest caveat up front: this transparency layer is being built out phase by phase, and the public explorer entry point publishes together with the platform (see the last section). So treat this as a reader’s guide to the record formats — what each field means and what it proves — rather than a click-here-now walkthrough.

How do you read a cash-transaction record?

A cash-transaction record captures a single movement of money in the pool, and it is designed so that one line tells you what happened without any outside context. Each record carries:

• Transaction type — what kind of movement it was (an investor deposit, an investor withdrawal, an internal transfer between the special-purpose company’s accounts, and so on).
• Amount, with a sign — the sign is the direction. A positive amount is money flowing into the pool; a negative amount is money flowing out. You do not need a separate “direction” field; the sign carries it.
• Balance after — the account balance immediately after this transaction, so each record is self-locating in the running total.
• Counterparty type — who the other side was, by category (investor, borrower, trustee, bank, and so on).
• Time of occurrence — when the transaction actually happened.

Two properties make these records trustworthy to read.

First, the log is append-only. Under the hood, each root64 record is an Ethereum event log — a special data structure that a smart contract emits and that is then written into the block. The Solidity language documentation describes the mechanism precisely: when an event fires, the arguments are “stored in the transaction’s log… incorporated into the blockchain, and stay there as long as a block is accessible,” and “The Log and its event data are not accessible from within contracts (not even from the contract that created them)” (Solidity documentation — Events, as of 2026-06-15). Two consequences follow for a reader. Once written, an entry cannot be edited or removed — so the history cannot be quietly rewritten after the fact, and what you read today is what was written then. And because not even the emitting contract can read its own logs back, these records exist purely as an external audit trail — something built to be read by you, off-chain, rather than re-used by the system internally.

Second, the counterparty is pseudonymized, not hidden. The counterparty type is published in the clear — so you can filter and total by category — while the specific identity is committed as a cryptographic hash rather than a plain name. That combination is deliberate: it keeps individual borrowers and counterparties private while still letting you verify that a real, consistent counterparty stands behind each entry. Privacy and verifiability are meant to coexist, not trade off.

Whose signature is on a cash-transaction record?

Each cash-transaction record carries a signed claim, and the signature follows a specific Ethereum standard: EIP-712, the finalized standard for hashing and signing typed, structured data. EIP-712 exists to solve a concrete problem. The standard’s own motivation notes that, without it, a signed message is “an opaque hex string displayed to the user with little context about the items that make up the message” (EIP-712 specification, Final status, as of 2026-06-15). EIP-712 instead lets the data be presented with its schema, so the signer reviews the actual fields — the amount, the counterparty, the timestamp — rather than a meaningless blob before approving. It also carries a domain separator, which per the specification “prevents collision of otherwise identical structures” by binding each signature to a specific contract and chain (EIP-712 specification, Final status, as of 2026-06-15) — so a signature created for root64’s cash-flow contract is bound to that context and is not interchangeable with an identical-looking structure signed for a different application. In root64’s case that domain is named RWA-CashFlow and pins the signature to the specific cash-flow contract on a specific chain.

A note on who signs. The EIP-712 signature is issued by an independent trustee on a registered trustee wallet — not by the platform on its own — so the signed claim does not originate from root64 alone. Reading a record tells you that a structured, schema-checked claim was signed by that trustee and is tamper-evident; what it does not, on its own, establish is that the off-chain world matches the claim — which is exactly what the verification records (below) are for. Signing proves a claim was written and cannot later be altered; checking it against external sources root64 does not control is a separate step.

How do you read a verification record?

A verification record is the on-chain result of checking the pool’s data against an independent outside source. Where a cash-transaction record says “this is what we recorded,” a verification record says “and here is the result when we checked it against someone we don’t control.” Each one carries:

• Target — what was checked: an asset, or a cash transaction.
• Channel — the external source it was checked against: a property registry (for real-estate collateral), the Korea Financial Telecommunications & Clearings Institute (KFTC), which operates the central record-keeping system for Korean online-investment-linked-finance (P2P) transactions at p2pcenter.or.kr, or a bank (for cash movements).
• Result — one of three outcomes: match, mismatch, or inconclusive.

The most important thing to understand when reading these is what happens on a mismatch. The point of an honest transparency layer is not to show only clean numbers — it is to make the act of checking auditable, including when something does not line up. So a mismatch is written to the chain just like a match, and when it is later worked out, a separate resolution record is logged against the same verification. You can read not just the final clean state but the path to it: a check failed, and here is the record that it was resolved.

Reading a verification record alongside the cash-transaction record it covers is how you move from “root64 says this is true” to “an independent channel was checked, and here is the logged outcome.”

What does each on-chain record prove?

The table below maps the two record types to what they contain and what reading them establishes.

On-chain record	What it contains	What it lets you establish
Cash-transaction record	Transaction type; signed amount (sign = inflow/outflow); balance after; counterparty type (identity hashed); time of occurrence; EIP-712 signature	That a specific money movement happened, in which direction, against which category of counterparty, leaving which balance — written once, never edited, with a schema-checked signature attached
Verification record	Target (asset / cash transaction); channel (property registry / KFTC / bank); result (match / mismatch / inconclusive)	That the pool’s data was checked against an independent outside source, and what the result was — including mismatches and their later resolution

Source: root64 CashFlowLedger and VerificationLog contract specifications, as of June 2026.

Read together, the two record types answer two different questions. The cash-transaction records answer “did the money actually move, and how?” The verification records answer “and was that backed by something outside root64’s own books?” Neither alone is the whole picture; the transparency layer is the pair.

Where do you go to check it yourself?

The public entry point — an Ethereum block explorer such as Etherscan, pointed at the address where root64 publishes its proofs — will be published together with the platform. We are deliberately not circulating an address ahead of that, because publishing a stable, named publisher address is itself a trust signal, and it should go out once, correctly, rather than be guessed at early.

It helps to know the concrete reader gesture ahead of time, so it feels routine once the address is live. On Etherscan, you read a contract’s records by opening a transaction’s Logs tab; each emitted event there is split into Topics and a Data section. The first topic, Topic0, “is essentially a Keccak256 hash of the event signature, composed of the event’s name and its input parameters’ types,” and it tells you which kind of record fired (Etherscan Information Center — What is Event Logs?, as of 2026-06-15). For root64 that means Topic0 distinguishes a cash-transaction record (CashFlowRecorded) from a verification record (VerificationCompleted) at a glance. Per the Solidity documentation, you “can add the attribute indexed to up to three parameters,” which adds them to the topics structure as additional filters, while everything else is ABI-encoded into the Data section (Solidity documentation — Events, as of 2026-06-15). In root64’s cash-transaction record the indexed fields are the flow id, the pool id, and the counterparty type — so you can pull, say, every entry for one pool, or every entry against one category of counterparty, and read the rest (amount, balance after, timestamp) from the Data section.

When it does publish, the records you read there will have exactly the shape described above: append-only cash-transaction entries and verification results, each field meaning what this guide says it means. The goal of putting the entry point in public hands is that verification does not depend on taking 8percent’s word for it — you read the ledger directly.

What can’t the chain prove on its own?

Recording an entry proves that a signed claim was written and cannot later be altered; it does not, by itself, prove the off-chain world matches. This is not a root64 quirk — it is a recognized limit of all on-chain proofs. The industry’s proof-of-reserves principles make the same point: publishing a record on-chain establishes that the data was published and is tamper-evident, but credible transparency depends on independent verification that retrieves data “directly from trusted sources, like custodians or auditors” (Chainlink — 7 Key Principles for Proof of Reserves, published 2025-05-02). Two further limits are worth carrying into how you read any such proof. First, such a record “reflects a specific point in time” (Chainlink — 7 Key Principles for Proof of Reserves, published 2025-05-02) rather than a continuous guarantee. Second, a reserves snapshot on its own says nothing about liabilities — demonstrating that assets actually exceed liabilities is a separate exercise, which the same body of work treats as a distinct, complementary proof-of-solvency step (Chainlink — 7 Key Principles for Proof of Reserves, published 2025-05-02); for broader background on proof-of-reserves mechanics and verification, see Hacken — Proof of Reserves Explained: From Key Mechanics To Verification (as of 2026-06-15). For real-world assets specifically, bridging the gap between a physical or legal asset and its digital record requires an external channel — the chain cannot confirm off-chain existence on its own.

That is exactly why root64’s design is two record types rather than one. The cash-transaction record is the tamper-evident published claim; the verification record is the independent external channel — a property registry, the KFTC record-keeping system, or a bank — checked against it. Reading both, including the mismatches, is the whole point: it is how an on-chain record stops being merely “written and unalterable” and becomes “written, unalterable, and checked against something root64 does not control.”