Skip to main content
There are two Solana-side consumption paths:
  1. Push then read — submit the signed payload through submit_data_update, then read the maintained Feed account.
  2. Verify directly — use the framework-independent molpha-verifier Rust crate with caller-supplied registry/node data.
Do not use an SDK simulation path as the primary Solana verification model. The on-chain program verifies when it writes, and direct verification belongs in Rust code through molpha-verifier.

Read the latest result

The Feed account holds the latest value accepted by submit_data_update. The Molpha program re-verifies the aggregate signature before writing, so a valid Feed account is the canonical maintained state. Gateway settlement records payments in round receipts; it does not write the feed. With the SDK:
Prefer sdk.solana.readFeed for the maintained account. For a raw Anchor fetch without the SDK facade:

Pattern A — off-chain (TypeScript + Anchor)

Derive the feed PDA and fetch it. If you know the owner, apiConfigHash, and quorum, you can compute the feed address with no on-chain lookups:
Always apply a staleness guard before using the value:

Pattern B — from your Solana program

Pass the Feed PDA into your instruction and read it. Prefer typed deserialization: value is a Borsh Vec<u8> (4-byte length prefix + bytes), so fixed byte offsets after the discriminator are brittle.
Account scalars (registry_version, canonical_timestamp) are little-endian Borsh. value is a length-prefixed byte vector (raw payload when ≤32 bytes, or a keccak digest when longer). Validate the PDA with seeds::program = MOLPHA_PROGRAM_ID so a caller can’t substitute a look-alike account. last_updated_slot is emitted on the FeedUpdated event, not stored on the Feed account.
If you prefer typed access, depend on the Molpha program crate, or use Anchor’s declare_program! against the IDL for typed CPI and account helpers.

Push then read

Use this when you want the Solana Feed account to become the source of truth.
submit_data_update checks:
  • aggregate Schnorr signature validity,
  • signer bitmap and registry version,
  • deterministic signer selection,
  • monotonic canonical_timestamp,
  • feed value encoding.
The submitter is not trusted. Any keeper, gateway, or user can submit; the program verifies the payload before accepting the write.

Verify directly with molpha-verifier

Use this when your Solana program, native Rust service, CLI, or test harness needs to verify a signed payload without writing it to the Molpha Feed account. Install:
For pre-resolved signers:
For Solana-program-style registry resolution:
The crate does not read accounts for you. Your program or service owns:
  • account owner checks,
  • account deserialization,
  • node entry ordering,
  • registry version selection,
  • mapping DataUpdateError into your own error type.

Read vs. verify

Reading the Feed gives you the last accepted on-chain value. Direct verification checks a payload you already have. In both paths, your application still enforces freshness, replay protection, expected feedId, quorum, and value bounds.