Feed for the last maintained value (free, low-latency). Verify a payload when you must prove freshness inside your own transaction (high-value, point-in-time decisions). Both are permissionless — no subscription required to read or verify.
Read the latest result
TheFeed account holds the latest verified value for a job. With the SDK:
Pattern A — off-chain (TypeScript + Anchor)
Derive the feed PDA and fetch it. If you know the owner and theapiConfigHash, you can compute the feed address with no on-chain lookups:
Pattern B — from your Solana program
Pass theFeed PDA into your instruction and read it. The most decoupled approach (no dependency on the Molpha crate) validates the PDA and reads fields by offset after the 8-byte Anchor discriminator:
Account scalars (
registry_version, canonical_timestamp, last_updated_slot) are little-endian Borsh; the oracle value is a big-endian 32-byte word matching the cross-chain signed-message encoding (see Values and decoding). Validate the PDA with seeds::program = MOLPHA_PROGRAM_ID so a caller can’t substitute a look-alike account.declare_program! against the IDL for typed CPI and account helpers.
Verify on Solana
When you need to prove that a value is fresh at the moment of your transaction (pull model), useverify_data_update. You supply a signed payload and the registry-index accounts for each signer. The instruction:
- Re-derives the node selection set for
(job_id, registry_version, canonical_timestamp). - Reconstructs the coalition public key from the signers’
RegistryIndexaccounts. - Verifies the aggregate Schnorr signature.
- Reverts on any failure, or returns 72 bytes of return data on success.
| Bytes | Field | Encoding |
|---|---|---|
[0..32] | value | raw 32-byte word |
[32..40] | canonical_timestamp | i64 big-endian |
[40..72] | reserved | zero |
With the SDK
With raw Anchor (simulation)
The accounts are theRegistryState PDA plus one RegistryIndex account per set bit in signers_bitmap, passed as remainingAccounts in bit order:
From your own program (CPI)
CPI intoverify_data_update and read the result with get_return_data immediately after the call returns. Because the instruction reverts on an invalid signature, a successful CPI is itself proof that the value is authentic.
Read vs. verify
Reading theFeed gives you the last submitted value. For high-value, point-in-time decisions where you must prove freshness inside your own transaction (settlements, liquidations triggered by a single read), use stateless verification instead. See the Solana Program reference for the full account model and error table.