Pull-native threshold oracle. Any API, threshold-signed, verifiable on Solana, EVM and Starknet from one ceremony. Agent-ready via x402. USDC. No token.
Brebeneskul testnet is live.
AI agents can now buy threshold-signed data on demand.
Pay a few cents via x402. Independent nodes fetch the data. Receive one threshold-signed payload any contract can verify.
No account. No onboarding. No creation step.
npm i @molpha/sdk 🧵
Good news: Molpha got into the Ethereum Security Subsidy Program.
Better news: part of our audit bill is now someone else's problem.
Still on testnet. Nothing unaudited ships to mainnet. Auditors, sharpen your knives.
Thanks @areta_io@0xboo 🫡
We benchmarked Solana tx v1 vs legacy for Molpha settlement.
64-node registry, LiteSVM.
Nodes per settlement tx: 15 → 54 (v0+ALT: 53).
Also −300 CU, −32 bytes. Same fee.
Two gotchas if you're sizing v1 txs:
serde/bincode over-report v1 size by 15 bytes. Measure with wincode.
LiteSVM doesn't count program data toward the loaded-accounts data limit. Validators do (SIMD-0186).
Size the limit for your .so or it passes locally and fails on-chain.
Three of the nastiest attacks on multi-party Schnorr share one requirement.
A coordinator.
- Sign last, steer the challenge, forge anything.
- Abort and retry, extract a private key.
- Aggregate, and quietly decide whose signature counts.
@molpha_oracle has no lead. No aggregation point. No session to hijack. Every selected node derives the same canonical set from nonces committed before the round fires, so nobody signs last, nobody restarts your round, nobody picks the quorum.
You can't attack a role that doesn't exist.
Under the hood №1
Why @molpha_oracle keeps pubkeys in bytecode, not storage.
Verifying an aggregate Schnorr signature means summing every signer's pubkey.
In storage: an uncompressed key is two slots. A cold SLOAD is 2,100 gas.
18 signers → 18 × 2 × 2,100 = 75,600 gas.
Just to read the keys. Before a single curve operation.
Molpha packs each registry version into contract bytecode with SSTORE2 and reads it with EXTCODECOPY.
256-node registry, 18 signers: the entire cold verification tx, with calldata, base cost, key aggregation, Schnorr check, lands at ~57k gas.
Roughly one ERC-20 transfer.
And bytecode can't be edited. Every registry version is immutable; the signed payload carries its registryVersion, so it verifies forever against the exact keys that signed it.
Cheaper reads. History preserved by construction.
One week of x402:
6.99M payments across all chains. 5.86M of them on Solana.
618 buyers generated those 5.86M requests.
That's not retail. That's machine traffic.
So agents learned to pay.
Nobody taught them to verify.
The agent pays, gets bytes, acts on the bytes. No one attested to any of it.
The payment rails exist now. The trust rails don't.
We once treated “one transaction to create a feed” as good DX.
In Brebeneskul, we deleted the transaction.
Source identity is derived from the configuration hash. Quorum travels in the signed payload. Consumers set their own minimum.
The best on-chain state is the state you never write.
@SolanaFndn@raincards "Open to anyone" is the right bar, and it shouldn't stop at the money.
Bought data should carry evidence: source commitment, timestamp and signer quorum, verifiable by the next agent or contract.
We're building that layer with Solana as the canonical state chain.
We stopped measuring oracle portability by chain count.
The harder test: can one signing ceremony produce an artifact that survives different VM architectures?
@molpha_oracle uses plain-sum PoP-Schnorr over secp256k1. Every verifier checks the same relationship:
sG = R + eP
secp256k1 isn’t exposed natively in the same way everywhere. But its arithmetic is well understood and implementable across different runtimes.
That lets the same signed payload verify directly - without a bridge, relayer, or chain-specific re-signing.
Live today:
→ SVM
→ EVM
→ Cairo
Next verifier targets:
→ Soroban
→ Sui
→ FuelVM
→ CosmWasm
Different crypto APIs. Different cost models. Same signed artifact.
One ceremony. Many VMs.
Molpha is a pull-native threshold oracle built to make external data verifiable after it leaves the agent workflow that fetched it.
Trust breaks twice.
Upstream, independent nodes fetch the same API, apply the same deterministic policy, and co-sign the result.
Downstream, the agent passes that attestation to another agent or contract. The recipient verifies the request, freshness, quorum, and signature without trusting the agent or gateway.
Paid per request in USDC through x402. No subscription or human approval.
Agents shouldn’t just fetch facts. They should be able to carry evidence.
The Molpha builder Discord is now open.
If you're building with AI agents, prediction markets, RWAs, DePIN, or any application that depends on external data, we'd love to hear what you're working on.
Join us for:
• Integration support
• SDK & MCP discussions
• Protocol design conversations
• Feature requests
• Early release announcements
• Direct access to the team
Molpha is still early. That means your feedback can genuinely shape the protocol.
🔗 Join: https://t.co/d8Ull7QyoV
The verifier stays stateless.
No stored feeds. No registry sync. No state write before the read.
What it costs us: every payload carries its own proof. Bigger calldata than reading a number someone else already wrote for you.
What it buys: one signing round, verified on three VM families. Solana, EVM, Starknet. Same signature, no bridge, no relayer, no per-chain round.
And every payload we've ever signed stays checkable by anyone, forever. Nothing to trust that we didn't hand you.
That's the one we won't compromise on.
An AI agent just published Aave’s TVL to Solana—from one prompt.
Molpha MCP retrieved the result from DeFiLlama, got it threshold-signed by independent nodes, and submitted the transaction.
Any API. Threshold-signed. Verifiable on-chain.
https://t.co/a9ni7CdBNA
Brebeneskul testnet is live.
AI agents can now buy threshold-signed data on demand.
Pay a few cents via x402. Independent nodes fetch the data. Receive one threshold-signed payload any contract can verify.
No account. No onboarding. No creation step.
npm i @molpha/sdk 🧵
To our knowledge, this is the first threshold oracle to combine threshold signatures with x402-native payments.
The payload is chain-agnostic: one threshold signature verifies on Solana, Sepolia, Arbitrum, Avalanche Fuji, BNB testnet, and Starknet.