PegWatch
Solvency monitoring on GenLayer

How PegWatch works

A frontend for SolvencyOracle, a reusable proof-of-reserves attestation primitive on GenLayer - not a product with its own trust model, just a window onto real consensus.

No single party's claim

Proof-of-reserves today mostly means trusting an exchange's own attestation page, or a single auditor's report. Nobody independently re-derives the number. Registering an asset here just means pointing at its public reserve pages - clicking "Attest now" triggers a real GenLayer validator committee, each of whom independently fetches those pages themselves and extracts the figures. The verdict - SOLVENT or UNDERCOLLATERALISED - only lands if they agree.

Reusing a hard-won design, not re-deriving it

Agreement is a precise, uniform relative-tolerance check on the raw extracted numbers - the same design the sibling Ballpark project only got right after two real steward rejections (the first for allowing too loose a tolerance to mean anything, the second for a rounding "fix" that silently didn't enforce what it claimed to). SolvencyOracle inherits the corrected version directly rather than repeating that mistake.

A real limitation, shown honestly, not hidden

Every validator here has to fetch a live web page and run an LLM extraction within the same consensus round - meaningfully heavier, in real-world latency, than a pure-LLM call. On GenLayer Studio Next (this deployment) every demo attestation so far has reached clean consensus on the first try, in well under a minute. That wasn't true everywhere: an earlier deployment of this same contract on GenLayer Bradbury genuinely needed a retry on one attestation, and separately hit a transaction that stayed unresolved for hours - both documented, not hidden, in CONTRACT.md, which is part of why this deployment moved networks. If you click "Attest now" and still see a message about consensus not being reached, that's this kind of thing, not a broken app - click "Try again."

What multiple sources actually prove

An asset can register up to three source pages. They are not extracted separately and compared against each other - every validator concatenates all of an asset's pages into one evidence set and runs a single extraction against the combined text. What multiple sources buy is a broader evidence base for that one extraction, and on-chain proof (a hash per page) that every page was genuinely fetched - not that the pages agreed with each other. The real cross-checking here is validator-to-validator: multiple independent validators each redo the same combined fetch-and-extract and must land on the same reading. Detecting disagreement between sources would need a different design (a separate extraction and agreement check per page), which this version doesn't attempt - see SolvencyOracle's README.

What's stored, and what isn't enforced

The stored figure is the raw extraction, never rounded - the tolerance that verified it is stored alongside it as an explicit, checkable bound. An asset's "backing standard" is descriptive text, not something the contract verifies independently; what it does check is whether the reserve and liability numbers a page reports meet the registered threshold. Registration is permissionless and immutable - anyone can add an asset, and its source URLs never change afterward.