Where does gmore.fun get its data?

All data is sourced directly from on-chain Solana accounts. Round data comes from ore::Round and ore::Board accounts, treasury data from ore::Treasury accounts, and bid data from ore::Miner accounts. Price data is fetched from Jupiter's public price API. Every metric can be independently verified on the Solana blockchain.

How accurate is the data?

Our data is as accurate as the on-chain records themselves. We present data exactly as it exists on the Solana blockchain without manipulation or interpretation. There may be brief delays due to RPC polling intervals, but all historical data is permanently recorded and verifiable.

Can I verify the data independently?

Yes, absolutely. All data presented on gmore.fun can be verified by anyone with access to the Solana blockchain. You can use Solana Explorer, Solscan, or any RPC provider to inspect the same on-chain accounts we query. We provide detailed documentation of our data sources in our API documentation.

Is the data permanently stored?

Yes. All ORE mining activity is permanently recorded on the Solana blockchain. This means every round, bid, treasury change, and result is immutable and can be verified at any time, now or in the future. Our platform aggregates and presents this publicly available data.

Do you manipulate or interpret the data?

No. We present data exactly as it exists on-chain without manipulation, estimation, or interpretation. We aggregate raw on-chain data and perform documented calculations, but we never alter the underlying blockchain records or present data in a misleading way.

Do you provide historical data?

Currently, we focus on real-time data for active rounds and current metrics. Historical data exploration, time-series charts, and historical datasets are coming soon. These features will allow you to explore past rounds, analyze treasury evolution over time, and view trends in mining metrics. All historical data will be sourced from the same on-chain accounts and will be fully verifiable.

Why is gmore.fun an important data source?

gmore.fun aggregates and calculates valuable metrics and KPIs that aren't easily available elsewhere. While the raw on-chain data exists on Solana, we read, analyze, and present it in an accessible format, calculating derived metrics like production costs and buyback volumes. We serve as a trusted reference platform for both real-time and historical ORE mining data, making complex blockchain data accessible to the community.

ORE Data-API by gmore.fun

HTTP JSON endpoints backed by live data from the ORE program on Solana

What's ORE

ORE is a crypto mining protocol on Solana that enables decentralized mining rounds where participants deploy SOL to claim spaces on a 5×5 grid board. Each round has a winning tile determined by on-chain randomness, with rewards distributed to miners who selected the winning square.

Visit ORE project →

About gmore.fun

gmore.fun operates as an independent analytics provider for ORE on Solana — we are not part of the ORE core team. Our focus is reliable infrastructure, transparent metrics, and open APIs.

Learn more on our About Us page.

Base URL

https://ore-api.gmore.fun

All endpoints respond with JSON and require no authentication. Values are derived from on-chain accounts and may lag the live network.

Caching & Conditional Requests

Heavy payloads like /bids ship with ETag and Cache-Control: public, max-age=0, must-revalidate. Send the previously returned ETag in If-None-Match to receive 304 Not Modified and skip downloading the JSON when nothing changed. Browsers and CDNs that respect origin caching headers can safely revalidate the snapshot instead of pulling the full body on every poll.

Disclaimer

This service is free of charge and provided on a best-effort basis. We are not affiliated with the ORE program, cannot guarantee accuracy, availability, or timeliness, and may discontinue access at any time. During periods of heavy network activity our backend may lag or fail to respond.

Endpoints

GET/state

Returns a combined snapshot with all available data: treasury balance, active round details, current prices (ORE/USD and SOL/USD), and last round result. This is the main endpoint used by the frontend dashboard.

Example Request

curl https://ore-api.gmore.fun/state

Response Structure

{
  "treasury": { "motherlodeFormatted": "1.000000000 ORE", ... },
  "round": {
    "roundId": "123",
    "mining": { "status": "active", "startSlot": "250000000", ... },
    "totals": { "deployedSol": "1.000000000", ... },
    "perSquare": { "counts": ["10", "5", ...], "deployedSol": ["0.1", ...] }
  },
  "currentSlot": "250000500",
  "orePrice": { "priceUsdRaw": "0.123", ... },
  "solPrice": { "priceUsdRaw": "150.50", ... },
  "roundResult": { "roundId": "123", "winningSquareLabel": "#5", ... }
}

Status Codes

200Success. Returns complete state snapshot.
503Service unavailable. Returned when both treasury and round snapshots are unavailable.

Field Descriptions

Field	Type	Required	Description
treasury.motherlodeFormatted	string	required	Accumulated jackpot amount in formatted ORE. The motherlode value comes from the Treasury PDA's serialized state. Source: on-chain (ore::Treasury account)
round.roundId	string	required	Sequential identifier taken directly from the ORE round PDA. Each increment represents a complete mining round on-chain. Source: on-chain (ore::Round account)
round.mining.status	string	optional	Round status: 'idle' (before start), 'active' (during mining), 'finished' (after end slot), or 'expired' (results available or finished 10+ slots ago). Derived from board PDA and current Solana slot.
round.perSquare.counts	string[]	required	Array of 25 elements, each representing the number of unique miners who placed bids on that tile. Counts come from round.count[i].
round.perSquare.deployedSol	string[]	required	Array of 25 elements, each representing total SOL deployed on that tile. SOL amounts from round.deployed[i]. Sum of lamports converted using 1 SOL = 1e9 lamports.
round.totals.deployedSol	string	required	Sum of lamports deployed across all 25 tiles in the active round. Converted from round.total_deployed.
currentSlot	string \| null	optional	Current Solana slot number. Used for countdown calculations and round status determination. Source: Solana RPC getSlot()
orePrice	TokenPriceSnapshot \| null	optional	Current ORE token price in USD. Fetched from Jupiter's lite price API. Updated periodically.
solPrice	TokenPriceSnapshot \| null	optional	Current SOL token price in USD. Fetched from Jupiter's lite price API. Updated periodically.
roundResult	RoundResultSnapshot \| null	optional	Result snapshot for the most recently completed round. Includes winning square, rewards, and totals. Only available after a round has finished and results are computed.

Note

All fields may be null when data is unavailable. The treasury, round, orePrice, solPrice, and roundResult fields are nullable. Prices and currentSlot are stored at the root level (not duplicated in round object) for efficiency. Supports conditional requests via ETag headers; clients should send If-None-Match to receive 304 when the snapshot is unchanged.

GET/bids

Returns a sorted list of miner deployments for the active round. Each entry represents aggregated SOL deployments on a specific square (0-24). Bids are sorted descending by amount. Updated periodically during active rounds.

Example Request

curl https://ore-api.gmore.fun/bids

Response Structure

{
  "roundId": "123",
  "collectedAt": "2024-01-01T00:00:00.000Z",
  "uniqueMiners": 50,
  "bids": [
    { "square": 12, "amountRaw": "100000000", "amountSol": "0.100000000", "count": 5 },
    { "square": 5, "amountRaw": "50000000", "amountSol": "0.050000000", "count": 3 }
    // ...
  ]
}

Status Codes

200Success. Always returns a valid structure, even if bids array is empty.

Field Descriptions

Field	Type	Required	Description
uniqueMiners	number	required	Count of unique wallet addresses that have placed bids in the current round. Aggregated by scanning all miner PDAs via getProgramAccounts with a memcmp filter on round_id.
bids	BidEntry[]	required	Array of bid entries sorted descending by amount (lamports). Each entry represents aggregated deployments on a specific square (0-24).
bids[].square	number	required	Square index (0-24) representing one of the 25 tiles on the 5×5 grid.
bids[].amountRaw	string	required	Total lamports deployed on this square. Aggregated from all miners who placed the same amount on this square.
bids[].amountSol	string	required	Total SOL deployed on this square, formatted as a decimal string (e.g., '0.100000000'). Converted from amountRaw using 1 SOL = 1e9 lamports.
bids[].count	number	required	Number of unique miners who placed bids of this exact amount on this square. Used for deduplication when multiple miners deploy the same amount.

Note

The bids array is sorted descending by deployed lamports. Data is aggregated by scanning all miner PDAs that reference the current round. If no round is active or no bids exist, the bids array will be empty but the structure is always valid. Responses include an ETag and `Cache-Control: public, max-age=0, must-revalidate`; reuse the last body by sending `If-None-Match` to receive `304 Not Modified` without downloading the payload again.

GET/v3/health

Preferred readiness endpoint. Includes HTTP uptime, RPC fleet health, and a game watchdog that flags stalled rounds.

Example Request

curl https://ore-api.gmore.fun/v3/health

Response Structure

{
  "timestamp": "2025-11-26T23:33:10.812Z",
  "api": { "status": "healthy", "uptimeSeconds": 86400 },
  "rpc": { "status": "degraded", "failoverActive": true, "providers": [ { "label": "helius", "status": "unhealthy" } ] },
  "game": {
    "status": "stalled",
    "currentRoundId": "66650",
    "lastLiveUpdateAt": "2025-11-26T23:31:05.120Z",
    "stalledSince": "2025-11-26T23:31:05.120Z"
  }
}

Status Codes

200Always returns 200 with the current health snapshot.

Field Descriptions

Field	Type	Required	Description
timestamp	string	required	ISO timestamp when the snapshot was generated.
api	{ status: string; uptimeSeconds: number }	required	HTTP process status (currently always `healthy`) and uptime in seconds.
rpc	object	required	Fleet summary plus per-endpoint health details (role, label, http/ws URLs, status flags, latency, last error).
game	object	required	On-chain watchdog that marks the game stalled if live round updates have not advanced for >90 seconds.

Note

Legacy `/health` is still served for simple probes but does not include RPC/game sections. Dashboards should call `/v3/health`.

GET/version

Returns backend build identifier. Clients should poll this endpoint and reload when the version changes, indicating a new backend deployment.

Example Request

curl https://ore-api.gmore.fun/version

Response Structure

{
  "version": "v0.0.90"
}

Status Codes

200Success. Returns version identifier.

Field Descriptions

Field	Type	Required	Description
version	string	required	Backend build version identifier (semantic versioning format).

Note

Returns the backend build identifier. Ideal for lightweight health polling: check the version every few seconds and reload the app if it changes.

Usage Notes

All data is sourced directly from the ORE program—no predictions or off-chain modifications.
Expect occasional gaps or stale responses when the Solana RPC or our monitor is overloaded.
Implement client-side caching and backoff to avoid request bursts during outages.
Any client should gracefully handle missing or invalid status values by normalizing them to safe defaults (e.g., 'idle').
Any client should gracefully handle network issues and may use previous values when current data is unavailable.
All numeric values are returned as strings to preserve precision. Use appropriate parsing for calculations.
Fields may be null when data is unavailable. Always check for null values in client code.
Price data is fetched from Jupiter's lite price API. If price fetching fails, the last successful price is retained.
Round status can be 'idle' (before start), 'active' (during mining), 'finished' (after end slot), or 'expired' (results available or finished 10+ slots ago).
The /bids endpoint always returns a valid structure, even if the bids array is empty.
The /state endpoint is the primary endpoint and contains all necessary data. Use this endpoint for most use cases.
Price data (orePrice and solPrice) and currentSlot are stored at the root level of the state object, not duplicated in the round object.

Data Provenance

All metrics originate from public Solana accounts owned by the ORE program. We run a dedicated monitor that reads those accounts, formats the values, and exposes them over https://ore-api.gmore.fun. Price data is fetched from Jupiter's public price API. No guarantees are provided—our service can lag or be discontinued without notice.

Round data: Sourced from ore::Round and ore::Board accounts via Solana RPC.

Treasury data: Sourced from ore::Treasury account via account change subscriptions.

Bids data: Aggregated by scanning ore::Miner accounts via getProgramAccounts.

Price data: Fetched from Jupiter's lite price API ( https://lite-api.jup.ag/price/v3).