Verify on Solana

On Solana you can consume Molpha data three ways:

Pattern	Use it when
Read a `Feed` account	Someone keeps a feed current and you want the latest value cheaply
Submit, then read	You hold an attestation and want it on-chain as the feed’s new value
Verify directly	Your program or service needs to check an attestation without writing a feed

Program ID: MoLF3pgVA9MENSuEujxNNSMaTo71aLyewaH5nrWfUZs on devnet (see Deployments). Accounts, instructions and epoch settlement are documented in Solana program.

Read a feed

A Feed account holds the latest attestation one submitter wrote for a source and quorum. The program verified it before writing, so reading it is safe as long as you check the account’s address and its age. Field meanings are in Solana feed account.

From TypeScript

const feed = await sdk.solana.readFeed(sourceId, signaturesRequired, submitter);
if (!feed) throw new Error("feed not created yet");

const ageSeconds = Math.floor(Date.now() / 1000) - Math.floor(feed.timestamp.toNumber() / 1000);
if (ageSeconds < 0 || ageSeconds > 60) throw new Error(`stale feed: ${ageSeconds}s`);
// feed.value is the 32 signed bytes; decode with the source's encoding

submitter defaults to the SDK’s wallet. To compute the address yourself, use feedPda(deriveSourceId(apiConfig), signaturesRequired, submitter, MOLPHA_PROGRAM_ID) from @molpha/sdk and fetch it with Anchor and MOLPHA_IDL.

From your program

Pass the Feed PDA into your instruction and constrain its seeds, so a caller can’t substitute a look-alike account. Every field has a fixed size, so offsets after the 8-byte discriminator are constant.

use anchor_lang::prelude::*;

pub const MOLPHA_PROGRAM_ID: Pubkey = pubkey!("MoLF3pgVA9MENSuEujxNNSMaTo71aLyewaH5nrWfUZs");

#[derive(Accounts)]
#[instruction(source_id: [u8; 32], signatures_required: u8, submitter: Pubkey)]
pub struct UseMolphaFeed<'info> {
    /// CHECK: constrained to the canonical Molpha feed PDA below.
    #[account(
        seeds = [b"molpha_feed", source_id.as_ref(), &[signatures_required], submitter.as_ref()],
        bump,
        seeds::program = MOLPHA_PROGRAM_ID,
    )]
    pub molpha_feed: AccountInfo<'info>,
}

pub fn use_molpha_feed(ctx: Context<UseMolphaFeed>, _source_id: [u8; 32], _k: u8, _submitter: Pubkey) -> Result<()> {
    // Layout after the discriminator:
    // source_id[32] | value[32] | value_kind:u8 | submitter[32] | timestamp:u64 LE
    // | signatures_required:u8 | signers_bitmap[32] | registry_version:u32 LE | bump:u8
    const VALUE: usize = 8 + 32;
    const TIMESTAMP: usize = VALUE + 32 + 1 + 32;

    let data = ctx.accounts.molpha_feed.try_borrow_data()?;
    require!(data.len() >= TIMESTAMP + 8, MyError::InvalidFeed);

    let value = &data[VALUE..VALUE + 32];
    let timestamp_ms = u64::from_le_bytes(data[TIMESTAMP..TIMESTAMP + 8].try_into().unwrap());
    let age = Clock::get()?.unix_timestamp - (timestamp_ms / 1000) as i64;
    require!((0..=60).contains(&age), MyError::StaleData);

    let _ = value; // decode per your source's encoding
    Ok(())
}

Account integers are little-endian Borsh. For typed access, use Anchor’s declare_program! with the Molpha IDL.

Submit an attestation

submit_attestation is permissionless: any keeper, backend or user can submit, and the program verifies before writing. Each submitter writes its own Feed, created on the first submit.

const { signature, feed } = await sdk.solana.submitAttestation(attestation);

The program accepts the write only if:

the registry version is current, or superseded but still inside its grace period;
timestamp / 1000 is within the settlement window and no more than 60 seconds ahead of the cluster clock;
signaturesRequired is at least the protocol min_signers;
the signers are inside the derived selection set and the aggregate signature verifies;
for an existing feed: the same quorum, a strictly newer timestamp, and a registry version no older than the stored one;
with raw_value: at most 256 bytes and hashing to the signed value.

Accounts are the submitter (payer), the Registry PDA for the payload’s version, the Feed, ProtocolConfig and the system program, then one signer Node account per set bit of signersBitmap in ascending bit order. A legacy transaction fits up to 19 signers; larger sets need a v0 transaction with an address lookup table. To submit several attestations of one feed in one transaction, use submitAttestations.

Verify directly with molpha-verifier

The molpha-verifier crate is the same verification code the program uses, without the program around it.

[dependencies]
molpha-verifier = "0.3.0"
# features: "borsh", "anchor" (Attestation as an instruction argument), "solana" (account readers)

Function	Use it when
`verify`	You already resolved the signers’ `(x, y)` keys, in ascending bitmap order
`verify_attestation_resolved`	You have a `RegistryView` and one `NodeEntry` per signer
`solana::verify_attestation`	You have the `Registry` and signer `Node` accounts as `AccountInfo` (feature `solana`)
`verify_aggregate_over_hash`	You verify an aggregate signature over an arbitrary message hash

Each has a *_with_coalition_key variant that takes the precomputed sum of the signer keys; coalition_key(&signers) computes it.

use molpha_verifier::{verify_attestation_resolved, Attestation, NodeEntry, RegistryView};

verify_attestation_resolved(&attestation, &registry_view, &node_entries)?;

What the crate leaves to you:

Quorum. It does not reject signaturesRequired = 0. Enforce your own minimum.
Time. It takes no clock: no freshness, registry activation or grace-period checks.
Replay. It keeps no state.
Accounts. With default features it reads no accounts: you owner-check and deserialize them and order the node entries. With feature solana, solana::verify_attestation checks the owner, discriminator and length of the Registry and Node accounts and binds each signer to its registry position; you still check that the registry account is the PDA for the payload’s version.

Errors

Common errors from submit_attestation:

Error	Code	Meaning
`ConstraintSeeds`	2006	An account (for example the `Registry` for the wrong version) is not the expected PDA
`FeedNotNewer`	6030	`timestamp` is not newer than the stored one
`SignaturesRequiredMismatch`	6031	Quorum differs from the feed’s quorum
`RegistryVersionMismatch`	6056	Registry version is older than the feed’s
`RegistryNotActive`	6011	Registry version is not active at cluster time
`InvalidRegistryVersion`	6010	The verifier found a registry version or account mismatch
`AttestationTooStale`	6059	`timestamp` is older than the settlement window
`AttestationInFuture`	6060	`timestamp` is too far ahead of the cluster clock
`SignaturesBelowMinSigners`	6027	Quorum is below the protocol `min_signers`
`QuorumBelowThreshold`	6034	Fewer signers than the quorum
`CreditedExceedsSelection`	6043	More signers than the selection allows
`MissingSignerAccount`	6032	A signer `Node` account is missing or can’t be read
`InvalidNodeAccount`	6004	A signer `Node` account doesn’t match its registry position
`UnexpectedSignerAccounts`	6076	More remaining accounts than signers
`SignersNotSubsetOfSelection`	6028	A signer is outside the selection set
`InvalidCoalitionKey`	6077	`coalition_key` is not the sum of the signer keys
`InvalidAggregateSignature`	6029	Schnorr verification failed
`InvalidRawValue`	6044	`raw_value` is over 256 bytes or doesn’t hash to the signed value

Get started

Concepts

Access and payments

MCP server

Verify and publish

Protocol

Resources

Verify on Solana

Read a feed

From TypeScript

From your program

Submit an attestation

Verify directly with molpha-verifier

Errors

​Read a feed

​From TypeScript

​From your program

​Submit an attestation

​Verify directly with molpha-verifier

​Errors

Read a feed

From TypeScript

From your program

Submit an attestation

Verify directly with molpha-verifier

Errors