ORVYN WHITEPAPER · VERSION 1.0 DRAFT · 23 SEPTEMBER 2026

The oracle marketplace, powered by x402

Publish a feed, set a price, and be paid in USDG every time a smart contract or an AI agent reads it. Every answer is a signed report that a contract on Robinhood Chain can check without trusting Orvyn.

Important notice

This whitepaper describes Orvyn as it runs on 23 September 2026 and the plan for its token. It is information. It is not investment advice, not an offer to sell any asset, and not a solicitation to buy one. Nothing in it promises a return.

Orvyn’s contracts have not been audited by a third party. They hold real USDG on Robinhood Chain. Read them as unaudited code that holds funds, and size any exposure to that.

$ORVYN is not a share in Orvyn, a claim on its revenue, or a right to its treasury. The buyback described in section 16 is a policy funded from platform fees Orvyn actually receives. It is not paid from providers’ earnings, and it is not a tax on transfers.

Values marked TBD are not decided yet. Each one is published before the token launches.

1. Executive summary

Orvyn is an oracle marketplace on Robinhood Chain. Anyone can publish a data feed, set a price, and be paid in USDG every time a smart contract, an application or an AI agent reads it. Every answer is a report signed under EIP-712, and any contract can check that signature against Orvyn’s on-chain signer registry without trusting Orvyn’s servers.

Payment runs over x402, the open protocol that uses HTTP status 402 to quote a price in a form software can read. A client asks for a report, receives the price, signs a USDG authorization, and receives the signed report. It needs no account, no subscription and no API key, and it pays no gas.

Discover an oracle. Pay per request. Check the answer.

Orvyn has been live on Robinhood Chain since 22 September 2026, paid for in real USDG. When it opened under this name it listed 87 feeds from two providers.

Orvyn takes a platform fee of 10% of each payment, locked for each provider when that provider registers. 80% of the fees Orvyn receives buy $ORVYN on the open market and burn it. The other 20% pays for development and operations. Prices and payments stay in USDG: nobody needs $ORVYN to buy, sell or check an oracle report.

2. What Orvyn is

Orvyn is not one oracle. It is a market in which many providers sell signed observations under one set of rules: one registry that records who may sign for which feed, one verifier any contract can call, one payment path, and one place to compare feeds by price, method, freshness and measured reliability.

It works as two things at once:

1. An oracle marketplace, where feeds are published, priced and found.
2. A verification protocol, where a report that was bought can be checked on chain.

x402 is how a report is paid for. It is the payment layer of the marketplace, not the product.

3. The problem

Oracle access is fragmented

Onchain applications run on outside facts: prices, rates, settlement values, reference data. Getting one usually means integrating a particular oracle network, negotiating with a data vendor, or trusting an HTTP endpoint. Specialised and long tail data rarely reaches a chain at all, because no network finds it worth running.

Oracle networks are not marketplaces

An oracle network decides which feeds exist. A provider with a useful dataset has no way to sell it to contracts on its own terms, and a buyer has no way to compare two sources of the same fact.

Data payments are not built for machines

Accounts, monthly plans, API keys and invoices assume a person at a keyboard. An agent or a contract cannot open an account. It can sign a bounded payment.

Access does not prove integrity

A JSON response over HTTPS says nothing a contract can check: who produced it, when it was observed, whether it changed on the way, or whether the signer is allowed to speak for that feed.

4. Design principles

Orvyn is built on a short list of binding rules. Each one closes a known way that products of this kind lose money or trust, and each one is enforced in code rather than promised.

1. Never settle below the floor. A payment is settled only when it is large enough to cover the gas of settling it. One settlement on Robinhood Chain costs about $0.015 in gas, so at a 10% fee the floor is $0.20. A feed priced under the floor is sold in packs.
2. The provider’s vault is the only recipient. Every payment goes straight from the buyer’s wallet to the provider’s own vault, at an address fixed in advance. Orvyn’s relayer pays the gas and never holds the money. No function lets Orvyn move a vault’s balance.
3. Fail closed in both directions. The gateway checks the payment signature, obtains and checks the signed report, settles on chain and waits for the receipt, and only then answers. No report means no charge. A failed settlement means no report.
4. Nothing unsigned is sold. Every paid response carries a signed report, and the gateway checks its signature against the on-chain signer set before answering.
5. A report is a fact, not a message to one chain. Its signing domain carries no chain id and no contract address. Replay across time is stopped by the observation time and the sequence number.
6. Signing keys never live where the web is. Orvyn signs managed reports only on its worker server. The web hosting holds no signing key. Each feed has its own derived key, so rotating one feed touches no other.
7. Trust is labelled honestly. Every report states which kind of key signed it. A report Orvyn signs from a provider’s API reads “Signed by Orvyn from the provider’s API”. Only a report signed with the provider’s own key reads “Signed by the provider”.
8. Staleness is enforced. The gateway refuses to sell a report older than twice its feed’s heartbeat, and does not charge for the refusal. On chain, every freshness check requires the caller to state a maximum age.
9. Reliability is measured, not declared. Uptime, latency and freshness on a feed page come from Orvyn’s own probes and request log. A provider writes its methodology. It cannot write its uptime. A feed younger than seven days shows “not enough history”.
10. Operator power is bounded by the contracts. Orvyn runs on one owner key, and the contracts limit what that key can do (section 19).

5. Participants

Providers

Anyone who registers. A provider owns its feeds, sets their methods and prices, chooses its payout address, and either runs its own signing key or lets Orvyn sign from its API. Providers answer for the accuracy, the method and the rights of what they publish. A provider can be a data company, an analytics platform, a researcher, a protocol, a sensor operator or an agent.

Consumers

Smart contracts, applications, lending and derivatives protocols, prediction markets, tokenized asset platforms, research tools, AI agents and individual developers. Each one sets its own limits: the price it will pay, the kinds of signer it accepts, the maximum age of a report and the minimum number of sources.

Signers

Kinds 1 and 3 say “Orvyn signed this”, so a signer of those kinds needs a signature from Orvyn’s attester. Without it, a provider could register its own key as a managed signer and pass as Orvyn’s notary to every consumer that accepts managed reports.

Relayers

Orvyn’s relayers submit payment authorizations on chain and pay the gas. Each holds a small ETH float and nothing else. They never receive payment funds.

Orvyn

Orvyn runs the marketplace, the gateway that sells reports, the worker that signs managed reports and measures every feed, the provider dashboard, and the SDKs.

6. Feed lifecycle

1. Register. Registering as a provider creates a provider record, locks the current platform fee into it for good, and fixes the address of its vault.
2. Create a feed. A feed is created with its first signers in one transaction, up to 16 of them. Its identity (provider, slug, decimals, mode and schema) is fixed from then on; a changed definition is a new feed. Before a feed is published the provider must attest that it has the rights to the source, and name that source.
3. List. Name, description, methodology, sources, heartbeat, price and packs live off chain, so editing them costs no gas.
4. Operate. Reports are signed on the feed’s heartbeat. Orvyn records observation and publication times and counts late and missed reports.
5. Pause and archive. A provider may pause a feed at any time. It may not archive a feed while buyers hold unexpired packs on it; it can archive the feed once the last pack runs out.
6. Takedown. Orvyn can hide a listing and stop selling it, for example after a rights complaint. The chain keeps the feed and its signers. Packs outstanding on a feed that is taken down are lost, and the terms and the pack purchase screen say so before anyone pays.

7. Request and payment

1. The consumer finds a feed on the marketplace and requests its latest report.
2. The gateway answers 402 Payment Required with the payment requirements: scheme exact, network eip155:4663, the USDG contract, the amount, the recipient and a validity window. The recipient is always the provider’s vault.
3. The client checks the offer against its own rules: the network, the USDG address, an amount that matches the listed price, a recipient equal to the vault the registry derives for that provider, and its remaining budget.
4. The client signs an EIP-3009 transferWithAuthorization off chain. Signing costs no gas.
5. The client repeats the request with the signed payment attached.
6. The gateway checks the authorization, obtains and checks the signed report, settles on chain and waits for the receipt, in that order.
7. The response carries the signed report, its payload, the signer, the report encoded for a contract call, and the settlement with its transaction hash.
8. The consumer checks the report before using it.

A payment proves that a report was bought. The signature check decides whether it can be used.

8. The x402 payment layer

x402 turns an ordinary HTTP endpoint into one that software can pay. That fits an oracle market, where a consumer often wants one report and not a subscription. It gives Orvyn prices per request, quotes a machine can read, purchases without accounts, spending an agent can bound, and stablecoin settlement, all over plain HTTP. Any x402 v2 client can buy from Orvyn: a stock client with no Orvyn code in it pays and reads.

x402 does not produce data, choose providers, check a signer, decide freshness or make a source accurate. Orvyn keeps each of those jobs in its own layer:

A successful payment does not make a bad report good, and a good signature does not prove that anyone paid.

9. USDG settlement

Every price on Orvyn is in USDG, a dollar stablecoin with 6 decimals. Providers can price without watching a token chart, buyers and agents can budget in dollars, and every feed can be compared with every other on the same scale.

Buyers pay with EIP-3009 authorizations, so they need no ETH for gas: “No ETH needed. You pay in USDG only.” Orvyn’s relayer submits the authorization and pays the gas.

A transaction that succeeds has not necessarily paid. On Robinhood Chain, USDG accepts a replayed authorization without reverting: the transaction succeeds and moves nothing. Orvyn therefore confirms every payment by the authorization’s state and the Transfer log, never by the receipt’s status alone, and a client that settles on its own should do the same.

The vault

Each provider has one vault, a minimal contract with no owner and no operator, at an address fixed by CREATE2 from the provider id. Payments arrive there directly. When anyone calls withdraw(), the vault pays the provider’s share of everything received since the last withdrawal to the provider’s payout address and sets the platform fee aside. sweepFees(), also open to anyone, sends the fees set aside to Orvyn’s treasury. USDG can leave a vault in no other direction, and rounding favours the provider.

USDG is an upgradeable token whose issuer has powers over balances, including freezing addresses. That is outside Orvyn’s control. The vault is written so that a shortfall caused by the issuer reads as nothing pending instead of blocking every later withdrawal.

10. Floor, packs and keys

The settlement floor

Settling one payment costs about $0.015 in gas. Divided by the 10% fee, that is $0.15, rounded up to a floor of $0.20. A provider whose locked fee is lower gets a higher floor: the gateway uses the larger of the configured floor and the live gas cost divided by that provider’s fee. A price per call under the floor is allowed only when the feed sells packs that cost at least the floor; the pricing form refuses anything else, and the gateway never offers a single payment below it.

Call packs

A feed priced under the floor is sold in packs: one payment on chain, then many calls spent off chain.

• A pack belongs to the wallet that bought it.
• It lasts 30 days from purchase.
• It is not refundable, because the money is already in the provider’s vault. The purchase screen says: “Packs are non-refundable and expire after 30 days.”
• A wallet spends its packs through a signed-in session.

API keys for agents

A wallet can issue API keys that spend calls from its packs. A key cannot sign a payment, move USDG, buy a pack, control the wallet or withdraw provider revenue. If one leaks, what it exposes is the calls left in that wallet’s packs, not the wallet.

11. Agent access

Orvyn’s MCP server lets an AI agent search the marketplace, compare feeds, buy a report within a budget and check its signature, through standard tools. The payment client inside it receives the 402, checks the quote, signs, retries and returns the checked report, so to the agent a purchase is one tool call. When the budget runs out, the agent is stopped.

The client in the SDK and the MCP server enforces these limits:

• a hard spending budget for the session, which cannot be raised from inside it
• the network and the payment asset, pinned in the client rather than taken from the gateway
• an amount equal to the listed price times the calls bought
• a recipient equal to the provider’s vault as the registry derives it, when the client is given an RPC endpoint to read the registry
• a maximum age for every report, twice the feed’s heartbeat unless the caller sets its own
• a cap on any single payment, a pack included
• the providers, categories and signer kinds it may read from
• the fewest upstream sources a report may rest on

The provider, category, signer and source limits are checked against the feed before any call is spent, and the signer kind and source count again on each report. Search results leave out the feeds an agent may not read. None of these limits can be changed by anything the agent reads.

The consumer SDK, the signer SDK for providers, the MCP server and the Solidity package are built and tested end to end. They are published to npm in the next phase (section 20).

12. Signed reports

An Orvyn report is one signed observation of one feed, the unit a consumer buys and a contract checks.

Reports are signed under EIP-712 with the domain {name: "Lumoracle", version: "1"}, with no chain id, no verifying contract and no salt. The name is Orvyn’s earlier one, which the contracts on Robinhood Chain were deployed under. A supplemental JSON payload is canonicalized and hashed, and its hash is part of what is signed, so a consumer can confirm the payload was not changed.

What a consumer checks

1. The signature recovers to the declared signer.
2. That signer is authorized for this feed in the registry.
3. Its kind is one the consumer accepts.
4. The feed id is the one expected.
5. The decimals match the registry.
6. The report is young enough, and its observation time is not in the future.
7. It is not older than the last report the consumer accepted.
8. The payload hash matches the payload.
9. The source count, the confidence and the value are within the consumer’s own bounds.

OrvynConsumer enforces the maximum age, the signer kinds, a value range and the rule against going back to an older report. Bounds on the source count and the confidence are left to the consumer’s own code.

What a signature proves, and what it does not

A valid signature proves who signed the report and that no signed field changed. It does not prove that the upstream source was right, that the method suits every use, or that the provider was honest. Consumers choose their feeds and set their own acceptance rules.

13. Smart contracts

• OrvynRegistry holds what verification and payment attribution depend on: providers, feeds, signer sets and fee terms. It is also the factory of provider vaults. Names, descriptions, methodology, heartbeats and prices live off chain.
• OrvynVault is the per-provider vault described in section 9.
• OrvynVerifier checks a report against the registry. verifyFresh also checks its age, and has no form without a maximum age.
• OrvynConsumer is a base contract a consumer inherits to read reports safely: the feed it expects, how old is too old, which signers it trusts, which values make sense, and never going back to an older report.

Deployment on Robinhood Chain

Deployed on 21 September 2026. The platform fee for providers registering today is 10% (1,000 basis points).

14. Marketplace economics

Let G be the gross USDG payment, f the provider’s locked fee rate, F Orvyn’s platform fee and P the provider’s proceeds.

F = G × f · P = G × (1 − f)

For a payment of 1 USDG at the current 10% fee:

The 8% and 2% hold only at a 10% fee. A provider’s fee is locked when it registers and never changes for it. Orvyn can change the fee only for providers who register afterwards, and never above 20%, a limit written into the registry as a constant.

15. The $ORVYN token

Launch and liquidity

Orvyn deploys the token itself. There is no presale and no launchpad. The whole supply is placed in one ORVYN/USDG pool as a single-sided position above the starting price, so buyers buy from the pool and no USDG is needed to open it. The starting price and the range are TBD.

The pool position is held by Orvyn’s treasury. Whoever holds a pool position can withdraw its liquidity, and at launch that is every token not yet bought. The address that holds it is published before launch.

What the token is for

Its link to the marketplace is the buyback. More paid oracle calls bring more platform fees, which fund larger buybacks, which burn more $ORVYN. The link does not promise a price.

Oracle reports are priced and paid in USDG, not in $ORVYN. That keeps prices stable for providers, budgets predictable for agents, accounting simple, and the marketplace usable by anyone who holds a dollar stablecoin. Holding $ORVYN gives no access, discount, vote or share. If that ever changes, it will be announced only once the contract that does it is deployed.

16. Buyback and burn

What funds it

• Platform fees Orvyn actually receives: fees swept from provider vaults to the treasury, from payments that settled, pack purchases included.
• The pool position’s trading fees. The USDG side buys $ORVYN; the $ORVYN side is burned directly.

Provider proceeds, failed settlements and unpaid quotes never count.

The split

When it runs

Weekly, and only once the buyback balance has reached $250. Below that the balance rolls over to the next week, so gas and slippage do not eat small purchases.

Fees have been accumulating in the treasury since Orvyn went live, waiting for the token. The first buyback uses 80% of all of them, and 20% goes to development and operations.

How it runs

A splitter contract becomes the registry’s treasury address. The registry lets its owner point the treasury at a new address without touching the registry, the vaults or the verifier, so nothing already deployed changes. The splitter divides what is swept to it 80/20, buys $ORVYN on the pool and calls burn(). Each purchase and each burn is a transaction anyone can check.

The splitter is being designed now. Its source, its tests and its address are published before the first buyback, and until it is the treasury, no buyback runs.

What the policy is not

• not a tax on $ORVYN transfers
• not taken from providers’ proceeds
• not 80% of all marketplace payments, only of the platform fee
• not a dividend, and not a claim on Orvyn’s revenue
• not a promise of any price, amount or schedule beyond the rule above

Any change to the policy is announced before it applies, and never applies to fees already received.

17. Transparency

Everything the buyback does happens on chain. A public page will show, for every week:

• paid oracle calls and gross payment volume
• provider proceeds and platform fees received
• the 80/20 split, with the transactions that made it
• $ORVYN bought, the average price, and the purchase transactions
• $ORVYN burned, the burn transactions, and the total supply after them
• the pool position’s fees and where they went

Vault balances and totals are single contract reads, so anyone can reproduce these numbers without Orvyn’s database.

18. Security model

What the design is meant to hold

• A report signed by an unauthorized key is never accepted.
• A buyer is never charged more than it signed for, nor charged for a report it did not receive.
• An unexpected network or asset is refused.
• Provider funds cannot be redirected, by Orvyn or anyone else.
• An API key cannot move money.
• A stale report can always be refused, and a changed payload is always detectable.
• Every buyback and burn can be checked on chain.

How it was tested

The four contracts are covered by 95 Foundry tests with 100% line, statement, branch and function coverage. They include fuzz tests at 2,000 runs each, six invariants (among them: a vault always holds what it owes, money leaves only to payout addresses and the treasury, a provider’s fee is locked and capped, and a feed’s identity never changes), and fork tests against the real USDG contract on Robinhood Chain. End-to-end suites run the whole path on a local chain: payment, settlement, refused replay, packs, on-chain verification, withdrawal, a forged notary refused, an unmodified x402 client, the provider path, an agent stopped at its budget, and twenty buyers paying in the same instant.

An adversarial review of the contracts and the gateway found twelve problems. All twelve are fixed, each with a test that proves the fix. The review was done by the people who wrote the code, which is weaker than a review by strangers.

Keys

19. Operations and control

Orvyn is run by its team through one owner key. There is no multisig and no token vote. That is a deliberate choice for a small team, and the contracts are written so that the key’s power is small.

Revocation exists because a managed key is Orvyn’s key on Orvyn’s machine. If one leaked, waiting for every provider to act would leave forged “Orvyn signed this” reports passing checks. A revoked key can never be added back.

Off chain, Orvyn keeps a denylist that hides a listing and stops the gateway selling it. Orvyn does not describe itself as decentralized. If control is ever widened, it will be described here only after it is deployed.

20. Roadmap

Phase 1 · Protocol · done

• Four contracts deployed on Robinhood Chain, 21 September 2026
• Gateway, worker, marketplace and provider dashboard in production, paid in real USDG
• Consumer SDK, signer SDK, MCP server and Solidity package built and tested end to end

Phase 2 · Orvyn · done

• Renamed from Lumoracle; orvyn.me live on 22 September 2026
• Launch catalog of 87 feeds

Phase 3 · Developer surface · next

• The SDKs, the MCP server and the Solidity package published to npm
• Outside providers onboarded, and more categories

Phase 4 · Token preparation

• Total supply set (TBD)
• The ERC-20 deployed with no owner, and its source published
• The splitter contract designed, tested and set as the treasury
• The pool’s starting price and range set
• Every disclosure in section 23 published

Phase 5 · Token launch

• The contract address announced and the pool opened
• The first buyback, using the fees held since Orvyn went live

Phase 6 · Buyback in operation

• Weekly buybacks above $250
• The pool position’s fees routed to the buyback
• The public transparency page

Phase 7 · Oracle quality · later

• Aggregate feeds: a median across providers, with quorum, outlier exclusion and published confidence
• Provider reputation from measured uptime, latency and deviation. The score is not a token
• An optional per-feed verification fee, paid to the provider’s vault

Phase 8 · Delivery · later

• Parameterized reports, answering a question with parameters
• Pay per call under the floor, through x402 upto or a voucher escrow
• A push adapter exposing AggregatorV3Interface, so contracts written for Chainlink can read Orvyn feeds unchanged
• Streaming delivery for pack holders
• A Python SDK, provider alerts, CSV exports and a status page

No phase has a date. Each later item gets its own design note before work starts.

21. Risks

22. Legal and compliance

A provider cannot publish a feed without attesting that it holds the rights to the source and naming that source. A takedown address and process are live, and a listing that is taken down stops selling at once. The terms state what a buyer of each kind of report receives.

The token’s legal position is TBD, as is the list of places where the token is not offered. Orvyn is independent of Robinhood. Building on Robinhood Chain implies no endorsement by Robinhood.

23. Before the token launches

Orvyn publishes all of the following before the token launches:

1. The total supply
2. The token contract address, with its source and proof that it has no owner
3. The pool address, the starting price and the range
4. The address that holds the pool position
5. The splitter contract address, its source and its tests
6. The treasury history: every address the registry’s treasury has pointed to
7. The fees held for the first buyback
8. The launch date
9. The places where the token is not offered

The owner key and the attester are already listed in section 13.

24. Conclusion

Orvyn is an oracle marketplace paid per call over x402. Providers publish and sell signed observations. Smart contracts, applications and AI agents buy exactly the reports they need, in USDG, with no account, and check every one of them on chain without trusting Orvyn.

It is live, its rules are enforced by its contracts, and its limits are stated rather than hidden: one owner key with bounded power, no third-party audit, and a token that is not needed to use the product. $ORVYN connects the marketplace’s real usage to a buyback anyone can check: 80% of the platform fees Orvyn receives buy $ORVYN and burn it, and 20% keeps Orvyn running. Its credibility will rest on paid usage, reliable providers, and every buyback and burn being there on chain for anyone to see.