Midas Proof

Midas Proof applies the LlamaGuard Proof model to Net Asset Value reports for Midas tokenized investment products. It links each reported NAV to authenticated source evidence, records the attestation hash on Ethereum, and publishes a separate verification result.

The first deployment covers mHYPER. Its fund manager submits a structured NAV report by email; the attestation workflow verifies the email evidence and can compare the reported value with an independent 1token snapshot.

Deployment

Property	Value
Product	mHYPER
Network	Ethereum mainnet
Registry	`MidasSaveRegistryWithClaim`
Attestor	Midas through Chainlink CRE
Independent verifier	LlamaRisk through Chainlink CRE
Document storage	IPFS
On-chain data	Attestation and verification hashes

Attestation lifecycle

Submit the NAV report

The fund manager sends a structured email containing the product, report time, total NAV, and denomination to a designated address.

Vlayer captures the message through the Gmail API and produces a TLS Notary proof. This proof binds the email content to the server response used by the workflow.

Register the source claim

The source evidence and email data are compressed, uploaded to IPFS, and registered through setClaim() on MidasSaveRegistryWithClaim. The resulting NewClaim event starts the attestation workflow.

Build the attestation

The Chainlink CRE workflow fetches the claim, verifies the Vlayer proof, and extracts typed claims from the email. When cross-verification is enabled, it compares the reported NAV with a 1token snapshot near the report time.

The completed SAVE attestation is signed, compressed, stored on IPFS, and registered on-chain through setAttestation().

Verify the attestation

A separate CRE workflow starts when the registry emits AttestationSet. It fetches the attestation, checks the signature and claim references, repeats the source-proof checks, and produces a per-claim verification report.

The report is stored on IPFS and its hash is registered through setVerification().

Claims

Claim ID	Type	Value	Purpose
`fund_manager_claim`	Inline	Object	Email headers, body, and TLS Notary proof
`fund_manager_total_nav`	Source-backed	Numeric	Total NAV extracted from the email
`fund_manager_email_sender_verification`	Source-backed	String	Expected sender check
`fund_manager_email_receiver_verification`	Source-backed	String	Expected receiver check
`one_token_snapshot`	Inline	Object	Independent 1token snapshot when available
`one_token_nav`	Source-backed	Numeric	NAV extracted from the 1token snapshot
`nav_deviation_percent`	Inline	Numeric	Difference between reported and independent NAV
`attestation_source`	Inline	String	Records whether the attestation used one or two sources

Optional cross-verification

The 1token claims are present only when cross-verification is enabled and an eligible snapshot is available. The attestation identifies whether it was built from the email alone or from both sources.

NAV cross-verification

The workflow looks for a 1token snapshot close to the timestamp in the fund manager's report. It first checks the latest snapshot before the report and calculates deviation = |emailNAV - snapshotNAV| / snapshotNAV.

If the deviation is within the configured 5% threshold, the workflow adds both NAV sources to the attestation. If the first comparison fails, it can check the next snapshot after the report time. When no eligible independent value is available, the workflow can still produce an email-only attestation and records that source mode explicitly.

An email-only attestation proves the origin and processing of the reported value. It does not claim that an independent NAV source agreed with it.

On-chain registry

MidasSaveRegistryWithClaim groups claims, attestations, and verification reports under a proof ID:

proof ID
├── latest source claims
├── latest attestation and publisher
└── verification reports and verifiers

The registry stores content hashes rather than the full documents. A reader can resolve a hash to an IPFS CID, fetch the document, recompute its hash, and run the same verification logic locally.

Common reads include:

Function	Returns
`proofIdToLatestAttestation(proofId)`	Latest attestation hash, publisher, and timestamp
`getAllVerifications(proofId)`	Verification records for the proof
`getClaimsForProofId(proofId)`	Registered source claims

Execution boundaries

The attestation and verification workflows are separate. Each runs across Chainlink DON nodes and publishes through its authorized registry path. The registry checks the authenticated report before accepting a write.

This separation lets a verification report disagree with an attestation without changing the attested document. Consumers can inspect both records and decide which verification policy they require.

Query the records

Use the API reference to retrieve indexed proofs, attestations, and verification reports. The same records can be reconstructed directly from the registry and IPFS without relying on the API.

On this page