Registration vs. verification: root64's multi-layer data verification model

What is the difference between registering an asset and verifying it?

Registration is recording the data; verification is independently checking it. On root64, these are two separate roles held by two separate parties, and that separation is the whole point. The party that registers an asset — the originator that supplied the loan, or the special-purpose company’s (SPC) fund administrator that records cash movements — is never the party that verifies that the data is true. Verification is done against an external channel that the registrant does not control.

This is a deliberate design principle, not an implementation detail. A platform that lets the same party both assert a fact and confirm it has not actually checked anything — it has asked an interested party to mark its own homework. root64’s data-trust model is built to make that impossible by construction.

The principle is familiar from internal-control practice under names like separation of duties or the “four-eyes” principle: for any consequential action, the party that creates a record should not be the only party that confirms it. The U.S. accounting-scandal reforms of the early 2000s made this a baseline expectation for financial reporting, precisely because self-confirmation is where errors and manipulation hide. root64 applies the same logic to on-chain asset data.

Why isn’t “the data is on a blockchain” enough?

Because putting data on a blockchain proves only that the data was recorded — not that it is true. A blockchain guarantees that an entry, once written, is hard to alter and easy to inspect. It guarantees nothing about whether the entry matched reality at the moment it was written. If an originator simply writes “this loan exists and is performing” to a public chain, an investor has gained immutability of a claim, not evidence of a fact.

This is the gap root64’s model is built to close, and it is the same gap explored in why root64 publishes proofs before issuing tokens: a token, or any on-chain record, is only as trustworthy as the verification underneath it. Registration produces the record. Verification produces the trust. Treating them as one step — “we put it on-chain, so it’s verified” — is the mistake the whole design is meant to avoid.

The point generalizes beyond root64. The U.S. accounting regulator, the Public Company Accounting Oversight Board (PCAOB), has warned that even formal crypto “proof of reserve” reports “are not equivalent or more rigorous than an audit” and that investors should exercise caution unless reserve data is independently checked against an outside source (PCAOB Investor Advisory, March 2023). “It’s on-chain” and “it’s verified” are different claims, and conflating them is exactly what an honest verification layer has to refuse to do.

Who registers, and who verifies?

The two roles are assigned to different parties by asset type. For asset data, the originator registers and an external public channel verifies. For cash data, the SPC’s fund administrator registers and a bank channel verifies. In every case, the verifier is independent of the registrant.

Some terms first. An originator is the lender that supplied the loans — in root64’s initial pool, 8percent, the FSC-licensed Korean P2P (online investment-linked finance) lender behind the platform. The SPC is the Korean special-purpose company that holds the right to receive principal and interest (원리금수취권) on those loans in a bankruptcy-remote structure; how that holding works is covered in how root64 holds Korean loan assets. The fund administrator is the third party that keeps the SPC’s books and records its cash transactions.

The split looks like this:

Data type	Registered by	Verified against (independent channel)
Asset data (loan, collateral)	Originator (e.g. 8percent)	Property registry; Korea’s P2P central record-keeper (KFTC)
Cash transactions	SPC fund administrator	Bank API

Source: root64 data-verification model, per its product strategy, as of June 2026.

Two details matter here. First, Korea’s P2P central record-keeper is the Korea Financial Telecommunications and Clearings Institute (금융결제원, KFTC) — the institution that maintains the official central record of online investment-linked finance loans under Korea’s Online Investment-Linked Finance Act. It is an external authority, not something the originator can edit, which is exactly why it works as a verification channel. Second, the registrant is always the party closest to the asset, because that party has the data first and most accurately; the verifier is always a party with no incentive to confirm a false entry. Registration optimizes for accuracy at source; verification optimizes for independence.

What does the on-chain verification record actually capture?

It captures the check, not just the data. In the designed model, each verification writes an on-chain entry recording what was verified, which channel it was verified against, and the result — and the result is one of exactly three values: match, mismatch, or inconclusive. This is the layer that makes the act of verification itself auditable.

Recording the check rather than only the data is the second half of the separation principle. Separating registration from verification means nothing if the verification then happens invisibly off-chain, because an investor would once again be trusting that someone, somewhere, did the check honestly. By writing the verification result to the chain, root64 makes the check a public, append-only fact: an investor can see that the data was checked, against what, and with what outcome.

Concretely, each verification entry records its target (asset data or cash flow), the channel used, the result, a timestamp, and a hash of the supporting evidence. The evidence hash is produced by extracting the core fields of the external channel’s response, serializing them in a canonical form, and hashing the result — so that an auditor holding the original response can later reproduce the same hash and confirm the on-chain entry corresponds to a specific, real check, without the raw response itself having to live on a public chain. The mechanics of how an outside party reproduces and inspects these records are covered in how to verify root64’s on-chain proofs.

This is verification, not an audit, and root64 is careful about the distinction. Verification establishes that a specific piece of data was checked against an independent channel and what the result was. An audit is a broader, standards-governed examination of an entity’s financial statements. The model is designed to reduce reliance on periodic external audits by making routine checks continuous and on-chain — not to replace the concept of an audit or to claim the authority of one.

What happens when the data doesn’t match?

The mismatch is recorded on-chain as a mismatch. It is not hidden, smoothed over, or quietly corrected before anyone sees it. This is the single most important consequence of the design, because the value of a verification layer is measured by what it does when something is wrong, not when everything is right.

A system that only ever shows clean results has told you nothing about its honesty — you cannot distinguish “nothing was ever wrong” from “problems were never recorded.” root64’s model resolves that ambiguity by making mismatch and inconclusive first-class outcomes, written to the chain with the same permanence as a match. An inconclusive result — where the external channel could not confirm or deny the registered data — is recorded as inconclusive rather than rounded up to a pass.

When a mismatch is later investigated and resolved, the resolution is itself recorded on-chain, carrying a reference back to the original verification entry and a hash of the supporting evidence for the fix. The result is a complete, append-only trail: the original mismatch stays on the record, linked to its resolution, so the history shows both that data once failed to line up and how it was reconciled. Nothing is overwritten; corrections are added on top, the way a proper ledger handles an error.

This is what separates a transparency layer from a marketing dashboard. A dashboard shows you the state someone wants you to see. An append-only verification log, including its mismatches, shows you the state the assets are actually in — and the record of every time the platform had to reconcile its own data with the outside world.

How does this connect to the rest of root64?

The registration-versus-verification split is the load-bearing principle beneath everything else root64 plans to build. The platform’s roadmap moves from a transparency layer, to tokenization, to onboarding additional originators — and each later stage inherits its trustworthiness from this base layer rather than re-establishing it.

The multi-layer model matters most as the platform scales beyond a single originator. When 8percent registers its own assets, an investor might reasonably extend it some benefit of the doubt. When a third-party originator registers assets onto the platform, that benefit of the doubt evaporates — and the independent-verification layer becomes the only thing standing between an investor and an unchecked claim by a party they have never met. A design that requires every originator’s data to clear an external channel, and that records the result publicly, is what lets the platform add originators without each one having to be individually trusted. This is the practical mechanism behind how foreign investors access Korean loan assets on root64: not a promise to trust the operator, but a structure that reduces how much trust is required at all.

It is worth being clear about scope. This verification layer is root64’s planned first phase — it is being built and is not yet live in production — and it is designed to operate on a pool of Korean private-credit loans; for the asset class itself, see Korean private credit explained. Token issuance through a Hong Kong vehicle is a planned second phase, contingent on regulatory clearance, and that vehicle is not yet formed. And separately: verification does not make the underlying loans risk-free. They are loans, and they carry credit risk. What the model does is make the state of those loans independently checkable — registered by the party who knows them best, verified by a party with no reason to lie, and recorded where anyone entitled to look can see both the checks and the mismatches.

When the on-chain entries that record those verification results are written, they are signed by an independent trustee — completing the separation: the party closest to the asset registers it, an independent channel verifies it, and an independent party commits the result to the chain. No single actor, including 8percent, is the sole source of truth. That, more than any single technology choice, is what the multi-layer model is for.