RIG FIELD
MANUAL.

From operator to settlement

1. Connect walletSolana operator account
2. Scan reservoirRead OIL reward reserves
3. Select & deployDepth, amount, wallet approval
4. Drill & resolveBackend WIN or dry well
5. Settle onchainReward / buyback / burn

The control room presents three physical monitors in a persistent 3D environment. A FastAPI backend assesses reserves, records mining sessions, resolves WIN/LOSS outcomes and runs reward, buyback and burn stages. PostgreSQL keeps the session and settlement records.

OIL rewards

A successful drill has a calculated reward-token obligation. Reward amounts use the actual mint’s decimal precision.

Protocol activity

WIN and LOSS allocate part of deployed SOL to token buybacks. Transaction-attributed tokens feed the burn policy.

$RIG dashboard

Market telemetry and a DexScreener embed sit alongside mining tools. The chart reference, public token configuration and reward mint are separate identities.

Preflight → deployment → review

1. Connect a Solana wallet

   Use a supported Wallet Standard account, such as Phantom, Solflare or the available MetaMask connection. Connection shares your public address; deploying is a separate approval.

2. Enter the control room

   Open Mining and use Overview or a monitor’s FOCUS button to orient yourself.

3. Scan reward reserves

   On the left monitor, initiate the reserve scan. The four-second presentation can wait longer for live RPC data.

4. Select a depth

   After a sufficient scan, open depth selection. Compare the multiplier and probability range; each drill has its own outcome.

5. Enter SOL deployment

   Set a positive amount in the right monitor, with up to nine decimal places. Retain SOL for network fees.

6. Review reserve assessment

   Start Drilling first requests a deployment-specific assessment. If reserves are insufficient, the UI stops before asking for a transfer.

7. Authorize SOL deployment

   The wallet submits your SOL transfer to the displayed Vault. The client waits for confirmed transaction data and checks the destination and amount before recording the session.

8. Follow the drilling sequence

   Startup, descent and reservoir analysis run over 15 seconds. Wait for the backend result; the animation does not choose it.

9. Read discovery results

   OIL DISCOVERED is a WIN. DRY WELL is a LOSS and skips the reward transfer stage.

10. Inspect settlement signatures

    Use each Reward, Buyback and Burn link to check its own Solscan transaction. A submitted status is not proof of finalization.

11. Continue when eligible

    Continue Drilling resets the presentation for another reserve scan while capacity remains. After the fourth resolved drill, cooldown applies.

Monitor stations

Dashboard modes

Drilling

Default mode: reserve scanner, drilling operation and deployment console.

Economic

Vault health probability model, economic explanation and a depth-by-depth expected reward/distribution simulation.

Mining Stats

Public leaderboard, production buyback/burn submissions and recent recorded WINs. Refreshes every 30 seconds while open.

$RIG

Full-monitor DexScreener chart, configured-token market telemetry and a lightweight ambient rig illustration.

The three mode buttons sit below Target Depth on the center monitor. BACK TO DRILLING returns to the operational displays. Presentation mode does not reset an active drill, settlement request, selected depth, wallet or camera.

Camera and monitor interaction

Use the bottom station toolbar or each monitor’s FOCUS control. Inputs, links and internal monitor scrolling remain interactive; scroll over the room background to adjust camera zoom.

What the scan reads

The frontend requests readiness and economics together. The Vault service reads SOL balance, reward-token accounts and mint precision through Solana RPC. Without a deployment amount, readiness checks that OIL reserves are positive; it does not reserve a payout.

Readiness versus a session assessment

A sufficient scan unlocks depth selection. Before deployment, a new assessment compares the Vault’s reward value with that specific drill’s rounded reward obligation. Coverage below 1× is insufficient. Reward reservations are not tracked, so a reading is a snapshot rather than a guarantee of future availability.

Compare all supported depths

Code-reference depth defaults below; these are not a live deployment assessment.

500 M pairs a 1× WIN reward multiplier with a 15%–60% configured range. A larger multiplier is paired with a lower maximum chance.

Read the assessed probability

The range is not one universal WIN rate. Vault coverage positions the drill within its depth’s range. The deployment flow requests an assessment before the wallet transfer, and a session records the probability used for resolution. Repeated drills do not inherit a guaranteed result from previous attempts.

Scrub the operational timeline

Resolution is a server event

The frontend requests resolution after the session’s 15-second minimum. The backend uses the persisted probability and stores one resolved outcome. Retrieving an already resolved session returns the existing result. The outcome is not revealed early by the visual timeline, and API latency can extend the wait.

A four-drill cycle

WINs and dry wells both consume capacity when resolved. During cooldown, configuration is locked. Once the backend cooldown expires, capacity can reset to four. The frontend keeps a per-wallet cooldown deadline in browser storage to preserve the visible countdown across refresh.

What refresh can recover

Reconnect the same wallet to load backend capacity, cooldown and an unresolved session. The client also retries recording a pending deposit if it was saved after transfer verification. Resolved-session settlement can be looked up by its session ID, but the current wallet-state endpoint does not list completed sessions; automatic recovery of every completed result is not guaranteed.

Coverage is relative to this drill

Coverage Ratio = available reward value ÷ the session’s required reward value. The denominator is the configured OIL obligation after downward rounding to the mint’s atomic precision, valued at the configured reward-token price. It is not the entire SOL deposit or an arbitrary global reserve target.

coverageRatio = availableRewardValueUsd / requiredRewardValueUsd
vaultHealth = clamp((coverageRatio - coverageMin) / (coverageMax - coverageMin), 0, 1)
probabilityFactor = 0.25 + 0.75 * vaultHealth
winProbability = depthMaxProbability * probabilityFactor

The implementation uses a 0.25–1 probability factor. The coverage thresholds come from configuration. With 1× and 10× thresholds, health is clamp((coverageRatio − 1) / 9, 0, 1): health 0%, 50%, 100% corresponds to factors 0.25, 0.625, 1.

Explore every depth

The production calculation

Loading configured economics…

depositValueUsd = deploySol × configuredSolPriceUsd
rewardValueUsd = depositValueUsd × winRewardShare × depthMultiplier
rewardTokens = rewardValueUsd / configuredRewardTokenPriceUsd
rewardAtomic = floor(rewardTokens × 10**mintDecimals)
payableOil = rewardAtomic / 10**mintDecimals

The commonly configured WIN reward share is 60%; the current feed supplies the deployed value. Pricing is backend-configured rather than an automatically refreshed spot quote. The current settlement runner calculates the transfer with the active server economics at settlement time, so an earlier estimate is not a fixed-price payout promise.

An interactive calculation

Decimals are a unit conversion

Atomic units are the smallest indivisible units of a mint. A hypothetical mint with eight decimals turns 64,864 atomic units into 0.00064864 tokens—not 64,864 whole tokens. The actual transfer reads the actual mint precision; eight is only an example, not a hardcoded OIL assumption.

Estimated reward

A simulation using selected inputs and the currently available economics configuration.

Calculated obligation

The reward calculation rounded down to the mint’s indivisible atomic units.

Submitted payout

A persisted reward transfer with a submitted status and a real transaction signature.

Confirmed transfer

A separate onchain outcome supported by transaction status and execution details. Submission alone does not prove it.

Compare WIN and LOSS

The intended WIN split is 60% reward value, 30% buyback + burn and 10% Vault. LOSS skips a reward and uses 80% buyback + burn and 20% Vault. The selector reads the deployed shares from economics. The backend rounds nominal reward/buyback allocations down in lamports, then assigns the remainder to the Vault allocation.

How the Vault fits

The reward Vault funds the token obligation. Higher depth multipliers can create reward value greater than the nominal reward share of a single deposit. Buybacks use their own allocation; burning the acquired tokens is not a second SOL charge. These mechanics do not establish profitability, reserve sustainability under every condition, or guaranteed token appreciation.

WIN and LOSS sequencing

WIN

1. Reward transfer
2. 5s gate
3. Buyback
4. 5s gate
5. Balance check
6. 10s gate
7. BurnChecked

LOSS

1. Buyback
2. 5s gate
3. Balance check
4. 10s gate
5. BurnChecked

These are persisted eligibility gates, not exact completion guarantees. A normal request waits through eligible stages in one API call. Preparation, RPC visibility and submission can add time. On WIN, the reward-to-buyback gate is set when the signed reward is persisted; the buyback-to-balance gate uses its persisted buyback timestamp.

Purchase, attribute, then burn

PumpPortal Local

Builds the token-purchase transaction using the configured buyback mint and the session’s SOL allocation. The service signs and submits it.

Transaction attribution

The balance check uses the buyback transaction’s token balance changes. It does not treat an unrelated entire Vault balance as tokens acquired by this drill.

RPC visibility window

Unavailable transaction data is retried every two seconds for up to 30 seconds within the request. An expired lookup window returns a pending state; it does not submit another buyback.

BurnChecked

Reads the actual token program and mint decimals, verifies source-token-account availability, and constructs checked burn instructions after the burn gate.

The five-token execution policy

burnAtomic = max(0, acquiredAtomic - 5 * 10**buybackMintDecimals)
// A zero amount returns insufficient-burn-amount; no invalid burn is built.

The deduction is five whole buyback tokens—not five atomic units. It is RIG’s current execution policy, not a universal Solana requirement. The reward-token mint and buyback-token mint may differ.

Public production activity

Leaderboard rules

Only resolved mining sessions count as drills. Ranking uses known submitted OIL payouts on WIN sessions, then WIN count, then drill count, then a stable wallet-address ordering. The global rank continues across pages. Retries do not create extra reward entries for the same settlement.

Missing historical reward precision is not guessed. Such payouts are omitted from the known reward sum and counted in reward_amount_unavailable_count. A displayed known total of zero can therefore coexist with recorded WINs.

Winners and submitted events

Winners are resolved oil_discovered sessions ordered by resolution time, newest first. A WIN can appear before a reward is submitted. Public buyback/burn activity includes production records with submitted status and a recorded signature, excluding debug operations and uncertain prepared-only states.

Submitted burn totals are grouped by mint and decimals. The singular total is unavailable if mints differ or amounts are unknown. Missing submission times use an explicitly marked settlement-record timestamp, not a fabricated transaction time. The UI refreshes every 30 seconds while this mode is active and supports loading additional records.

Main token and mining reward

The main project token is RIG. Mining rewards are paid in OIL using the backend’s configured reward mint. Both public identities are defined separately in the shared token configuration; neither is the DexScreener pair address.

XsaHND8sHyfMfsWPj6kSdd5VwvCayZvjYgKmmcNL5qh

The configured buyback target is a third identity and can differ from both tokens. Burn activity uses the mint attached to each transaction record. The chart link below uses the preserved pair reference, while the project market link above uses the main token contract.

Chart and market telemetry

The chart fills its physical monitor and remains interactive. Available chart/trade panels are supplied by DexScreener. The chart uses its own pair reference; telemetry looks up Solana pairs for the configured token contract, preferring that reference when it belongs to the configured base token. Otherwise it selects a matching liquid pair.

Telemetry can show USD price, market capitalization, FDV, liquidity, 24-hour volume/change and buy/sell counts. Missing fields stay unavailable. Polling runs every 30 seconds while the panel is mounted. Liquidity, market cap and FDV are distinct measures.

No supply, tax, governance, utility entitlement or security-audit claim is implied by this manual or the market panel.

System map

Persistence and idempotency

Wallet Standard handles the deployment approval. Next.js and React Three Fiber render the room and call FastAPI. The API stores sessions and per-wallet capacity in PostgreSQL. Reward transfer construction uses the reward mint’s token program and actual decimals; PumpPortal Local provides the buyback construction path; BurnChecked handles the checked token burn.

Settlement signs and persists transaction bytes and a deterministic signature before broadcast. Subsequent requests reuse existing operation identity and avoid building duplicate transactions for a persisted signature. Persistence is not proof of broadcast or success: an uncertain send can require reconciliation, and a repeated request does not guarantee that every stalled stage can automatically resume.

Contract conventions

Financial human-readable amounts are decimal strings unless a field explicitly identifies atomic units or lamports. Timestamps are ISO-8601. Public statistics require no connected wallet. A wallet parameter identifies a session owner; do not treat a supplied public address as a cryptographic proof of identity.

Endpoint index

GET /api/economics

{
  "status": "ok",
  "prices": {
    "sol_usd": "<configured_decimal>",
    "reward_token_usd": "<configured_decimal>",
    "source": "configured"
  },
  "probability": {
    "policy": "vault_adaptive",
    "global_current_probability": null,
    "depths": [
      {
        "meters": 1000,
        "multiplier": 2,
        "min_win_chance": "<fraction>",
        "max_win_chance": "<fraction>"
      }
    ]
  },
  "drilling": {
    "duration_seconds": 15,
    "max_drills": 4,
    "cooldown_seconds": 120
  }
}

GET /api/vault

{
  "vault_address": "<public_vault_address>",
  "sol_balance_lamports": 0,
  "sol_balance": "0",
  "oil_mint": "<reward_mint>",
  "oil_balance": "0",
  "oil_decimals": 8,
  "status": "ok",
  "checked_at": "<ISO-8601 timestamp>",
  "reserve": {
    "status": "empty",
    "coverage_ratio": null,
    "health_policy": "<reserve_policy>"
  }
}

GET /api/mining/readiness

{
  "status": "unavailable",
  "vault": {
    "oil_balance": "0",
    "available_oil": "0"
  },
  "readiness": {
    "sufficient": false,
    "reserve_status": "empty",
    "reward_vault_value_usd": "0",
    "available_reward_value_usd": "0",
    "coverage_ratio": null,
    "reservations_tracked": false,
    "health_policy": "<reserve_policy>"
  },
  "probability": {
    "policy": "vault_adaptive",
    "dynamic_policy_configured": true,
    "coverage_minimum": "<configured_decimal>",
    "coverage_maximum": "<configured_decimal>",
    "global_current_probability": null
  },
  "assessment": null,
  "assessment_id": null,
  "checked_at": "<ISO-8601 timestamp>"
}

GET /api/mining/wallet/{wallet_address}

{
  "wallet": "<wallet_address>",
  "status": "ready",
  "current_session": null,
  "drilling": {
    "used": 0,
    "remaining": 4,
    "max": 4
  },
  "cooldown": {
    "active": false,
    "ends_at": null,
    "remaining_seconds": 0
  }
}

POST /api/mining/start

{
  "session_id": "<session_id>",
  "status": "ready",
  "wallet": "<wallet_address>",
  "depth": 1000,
  "deploy_amount_lamports": 1000000,
  "deploy_amount_sol": "0.001",
  "deposit_signature": "<deposit_signature>",
  "started_at": "<ISO-8601 timestamp>",
  "resolved_at": null,
  "drilling_duration": 15,
  "result": null,
  "success": null,
  "probability": {
    "policy": "vault_adaptive",
    "effective_win_chance": "<assessed_fraction>",
    "vault_health": "<health_fraction>",
    "factor": "<probability_factor>"
  },
  "drilling": {
    "used": 0,
    "remaining": 4,
    "max": 4
  }
}

GET /api/mining/session/{session_id}

{
  "session_id": "<session_id>",
  "status": "ready",
  "wallet": "<wallet_address>",
  "depth": 1000,
  "deploy_amount_lamports": 1000000,
  "deploy_amount_sol": "0.001",
  "deposit_signature": "<deposit_signature>",
  "started_at": "<ISO-8601 timestamp>",
  "resolved_at": null,
  "drilling_duration": 15,
  "result": null,
  "success": null,
  "probability": {
    "policy": "vault_adaptive",
    "effective_win_chance": "<assessed_fraction>",
    "vault_health": "<health_fraction>",
    "factor": "<probability_factor>"
  },
  "drilling": {
    "used": 0,
    "remaining": 4,
    "max": 4
  },
  "cooldown": {
    "active": false,
    "ends_at": null,
    "remaining_seconds": 0
  }
}

POST /api/mining/resolve

{
  "session_id": "<session_id>",
  "status": "resolved",
  "wallet": "<wallet_address>",
  "depth": 1000,
  "deploy_amount_lamports": 1000000,
  "deploy_amount_sol": "0.001",
  "deposit_signature": "<deposit_signature>",
  "started_at": "<ISO-8601 timestamp>",
  "resolved_at": "<ISO-8601 timestamp>",
  "drilling_duration": 15,
  "result": "dry_well",
  "success": false,
  "probability": {
    "policy": "vault_adaptive",
    "effective_win_chance": "<assessed_fraction>",
    "vault_health": "<health_fraction>",
    "factor": "<probability_factor>"
  },
  "drilling": {
    "used": 1,
    "remaining": 3,
    "max": 4
  },
  "cooldown": {
    "active": false,
    "ends_at": null,
    "remaining_seconds": 0
  }
}

POST /api/mining/session/{session_id}/settlement

{
  "settlement_id": "<settlement_id>",
  "session_id": "<session_id>",
  "stage": "balance_check",
  "resume_at": null,
  "reward": {
    "status": "not_required",
    "signature": null,
    "amount": null,
    "amount_atomic_units": null,
    "decimals": null
  },
  "buyback": {
    "status": "submitted",
    "allocation_lamports": 800000,
    "signature": "<actual_buyback_signature>"
  },
  "balance_check": {
    "status": "pending",
    "amount": null
  },
  "burn": {
    "status": "pending",
    "signature": null,
    "amount": null
  },
  "error": null,
  "continue_drilling": true
}

GET /api/mining/session/{session_id}/settlement

{
  "settlement_id": "<settlement_id>",
  "session_id": "<session_id>",
  "stage": "reward",
  "resume_at": null,
  "reward": {
    "status": "pending",
    "signature": null,
    "amount": null,
    "amount_atomic_units": null,
    "decimals": null
  },
  "buyback": {
    "status": "pending",
    "allocation_lamports": 300000,
    "signature": null
  },
  "balance_check": {
    "status": "pending",
    "amount": null
  },
  "burn": {
    "status": "pending",
    "signature": null,
    "amount": null
  },
  "error": null,
  "continue_drilling": false
}

GET /api/stats/leaderboard

{
  "items": [],
  "total": 0,
  "limit": 20,
  "offset": 0
}

GET /api/stats/buyback-burn

{
  "items": [],
  "total": 0,
  "limit": 20,
  "offset": 0,
  "summary": {
    "total_buyback_submitted_sol": "0",
    "total_burn_submitted_tokens": "0",
    "burn_submitted_by_mint": [],
    "buyback_count": 0,
    "burn_count": 0,
    "burn_amount_unavailable_count": 0,
    "verified_onchain": false
  }
}

GET /api/stats/winners

{
  "items": [],
  "total": 0,
  "limit": 20,
  "offset": 0
}

Submission and read-only calls

Use GET settlement to inspect a record. POST settlement can execute financial stages and may remain open while gates and transaction visibility retries run. A successful HTTP response is not a confirmation guarantee; inspect the returned stage/status/error fields and transaction evidence. Operator-only debug routes are not part of this public reference.

Wallet authorization

Connecting a wallet and approving a transfer are separate actions. The normal deployment flow asks Wallet Standard to sign and send a SOL transfer, then checks confirmed transaction data for the intended destination and amount. Later settlement transfers are performed by backend transaction services. This manual never requests a wallet signature.

Execution vocabulary

Prepared / submitting

Signed transaction bytes and a signature can already be persisted before any successful RPC broadcast.

Submitted

The service recorded the transaction submission. This does not establish successful execution or finalization.

Available

Required transaction data, such as token balance changes, is visible to the balance-check stage. It is not a blanket finality claim.

Confirmed / verified

A separate conclusion supported by onchain transaction evidence. The public activity feed currently labels submitted intent and does not assert verification.

Failed

A stage reported an error. Inspect the response and existing signature before deciding what needs recovery.

Reconciliation required

A broadcast result is uncertain. A stored signature must be investigated; automatically constructing a replacement could duplicate financial intent.

Inspection and interrupted operations

Open each real signature at Solscan and inspect its status and instruction details. GET settlement reads the persisted state; an explicit retry of the normal settlement flow may progress eligible work while reusing existing signatures. A signature can also be stuck in an uncertain state that requires investigation. Neither the UI’s complete stage nor Continue Drilling is proof of onchain finality.

Frequently asked questions