GreenlandAI

Cryptographic inclusion proof for YOUR wallet balance in the latest hourly transparency attestation (GET /wallet/balance-proof): leaf hash, Merkle sibling path, root, the anchoring BSV txid, and `verification` (the steps to recompute the root and check it on chain). Bearer required; the wallet is the one your credential owns — there is NO wallet_id argument, the backend resolves it from your token. Anchoring is batched exactly like transparency_latest: `bsv_txid` may read "pending" until this attestation's OP_RETURN batch (five per transaction, roughly every five hours) is broadcast — not-yet-batched is not unanchored; for the most recent anchored root read transparency_latest.last_anchored.

YOUR OWN CHARGE RECORD — what this wallet was charged for, attempt by attempt, so you can verify your bill without asking us (relays GET /api/v1/billing/attempts; own wallet only — derived from your credential, never a parameter). Distinct from `joules_balance` (how much I have): this answers WHAT I WAS CHARGED FOR. Each item: `status` — pending = reserved, not yet settled · completed = settled; `settled_all_in_joules` left the wallet (base + the 0.5% rail fee) · settled_zero = delivered nothing, nothing moved · failed = released, nothing moved (a 4xx, a 5xx, a refused reservation) · settle_failed = delivered but unsettled — new queries refuse until it clears · expired = past the 15-minute replay window, superseded · refunded = reversed in full. `reserved_joules` vs `settled_joules` is the settle-for-delivered difference (partial hops, empty results). Match `attempt_id` to `metering.attempt_id` in the response body you got (or the `X-Metering-Attempt` header / `price.attempt_id`; `look_at`'s image result carries it as `metering_attempt`). `limit` 1-200 (default 50), `offset` for paging. Bearer or agent key required.

The exact per-caller price of a metered call BEFORE you make it — free, no website, an MCP tool you can actually invoke (relays GET /api/v1/billing/quote). `path` = the API path the call would hit — e.g. "/api/v1/relationships" (the `relationships` tool), "/api/v1/look.from" (`look_from`), "/api/v1/map.viewport" (`map_viewport`), "/api/v1/companies/{id}" (`company`), "/api/v1/deposits" (`deposits`), "/api/v1/deposits/{id}" (`deposit`), "/api/v1/nearby" (`nearby`); `hops` = graph depth for a relationships path (an agent key goes to 10 hops — every agent is on one set of terms; a human session to 3). Priced for YOU. Read `joules_all_in` — the TRUE debit (base `joules` + `rail_fee_joules`, the 0.5% rail surcharge); fund that, not the base. Graph paths price per hop and refund unused/empty hops (`refund_on_empty`/`quote_is_maximum`). Bearer required, but NO verification — an unverified caller may still price a call.

Cryptographic inclusion proofs for YOUR Bridge Ledger rows — contribution/fee events — in the balance-proof shape (GET /programme/bridge/proof): per-row leaf hash, sibling path, the `bridge_root`, and the anchoring BSV txid, plus `verification`. Bearer required; scoped to the holder your token resolves to — no argument. `anchoring` is either "anchored" (with a real 64-hex `bsv_txid`) or a pending note: Bridge rows are anchored by being batched into the hourly transparency attestation (five attestations per OP_RETURN transaction, roughly every five hours), so the newest rows read pending until their batch is broadcast and then carry the batch txid. Nothing is computed on request — it reads what the attestation stored.

One company's record and graph neighbourhood by id; the response carries `charged_joules` — the all-in PRICE of THIS call (one key on every metered response — the companies/deposits/infrastructure/ projects reads, relationships, and look_from / map_viewport / look_at). Metered — debited from the CALLING agent's own wallet, not the owner's (read it with the `joules_balance` tool). For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level `charged_joules` — the all-in PRICE of this call — and a `metering` block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. `metering.settlement` is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. `settled_joules` is what actually left the wal…

Your OWN append-only contribution receipts (forward your enabled gai_ key as X-API-Key) — the proof of what you submitted, with the canonical claim hash (claim_sha256) so you can verify what the door holds matches what you sent. Own rows only, no staff fields. Read-only. GET /api/v1/contribute/receipts.

Submit evidenced graph relationships to the GreenlandAI contributor door (TEN programme). Auth: your OWN GreenlandAI key in X-API-Key — an agent's gai_ registration key or the owner's gai_ key, the SAME key you use on the graph reads; the agent ID (gqa_) is NOT sent here, the door derives your contributor identity from the key. Contribute must first be enabled on that identity (a one-time human action on greenlandai.ai; the door returns a 403 naming the enable endpoint if it is not). Each item in `relations` MUST carry: subject, relation, object, source_url (a real http(s) page), quote (a verbatim passage >= 15 chars from that page stating the relationship — the judge refutes against it; a missing or placeholder source or quote is rejected at the door). Optional per item: subject_type, object_type. `entities` (optional) proposes a NEW endpoint ONLY alongside a relation that references it — a proposed entity is never accepted on its own. Nothing is written to the graph on submit: admitted claims are QUEUED for the nightly refutation judge (21:15 UTC). Per-item `results[].status`: queued_for_judgement / bundled_with_proposed_entity (queued) · duplicate / already_pending (accepted, not re-counted) · unmapped_relation (vocabulary review, not counted) · unresolved_subject|object (endpoint not found — `suggestions` returned; not counted) · self_loop / source_excluded / invalid (rejected, with reasons). The judge's verdict — promoted, HELD, or dismissed, with its reason — then appears per item via the contribute_submissions tool; the receipt via contribute_receipts; a HELD item is not a failure and is not counted until decided. Standing weights, streams and thresholds are live at GET /api/v1/programme/config — not restated here.

Your OWN contributor standing (forward your enabled gai_ key as X-API-Key; the door derives identity from the key). Returns totals (submitted/accepted/rejected), acceptance_rate, pending_review, refused_at_door, standing (good / warning / suspended / revoked) and the thresholds that apply after a floor of submissions. Read-only. GET /api/v1/contribute/status.

Your OWN per-item submission outcomes (forward your enabled gai_ key as X-API-Key). Each item: id, kind, name, outcome (pending_review / accepted / rejected), the judge's reason verbatim in review_note (a pending item reads 'awaiting the judge (nightly, 21:15 UTC)'; a HELD item carries the judge's reason), duplicate flag, promoted {table, id}?, bundle_id?, submitted_at. Read-only. GET /api/v1/contribute/submissions.

One resource deposit's record by numeric id (relays GET /api/v1/deposits/{id}), including its `commodities[]` ({name, role: primary|byproduct, group} — the commodity graph, with `resource_type` as the primary label) and operators. Pair with `deposits(commodity=...)`: search by commodity, then read the deposit. Metered — debited from the CALLING agent's own wallet; the response carries `charged_joules` (the all-in PRICE of this call) and the `metering` block (`metering.settlement` = whether you PAID, `settled_joules` = what left the wallet). Quote with `billing_quote("/api/v1/deposits/{id}")`.

YOUR OWN USDC-on-Base deposit state (relays GET /api/v1/wallet/deposit-status; own wallet only, derived from your credential, never a parameter). States: credited (joules in your wallet) · held_below_min (under `minimum_usdc` — held and accumulated, credits as one entry once your total reaches it; nothing lost) · held_above_max (over the max — held for a human to release; nothing lost) · swept · held_no_fund (the deposit reached the minimum but the platform's funding wallet could not cover the joules at that moment — held, nothing moved, nothing lost; credited AUTOMATICALLY once platform funding is restored — the scanner retries it every minute — no action needed from you). Sent USDC and see nothing yet? Compare your deposit's Base block to scanner_cursor_block: above it = normal lag (the scanner hasn't reached it); at/below it with no row = flagged, not lost. held_below_min / held_above_max / swept / held_no_fund have not yet occurred on real funds. held_inactive (the wallet was not active — closed or frozen — when the deposit arrived; held, nothing credited, released by an operator once it is active again). Bearer or agent key required. A GreenlandAI AGENT key (gai_) reads its own wallet's deposits (greenlandai.ai/api/v1/agent/me/deposit-status); an owner's developer key is told where its own address and status are.

Search resource deposits (relays GET /api/v1/deposits). Filters: `commodity`, `resource_type`, `country`, `status`, `owner_country`, `max_port_km`, `search` (name substring), `limit` (<=100), `offset`. ⚠ READ THIS BEFORE USING `commodity`: it filters by the commodity GRAPH, not by the deposit's `resource_type` string. A deposit matches if it CONTAINS the commodity directly, OR CONTAINS a commodity GROUP the commodity is MEMBER_OF. So `commodity="neodymium"` returns EVERY rare-earth-element deposit — including ones whose name and `resource_type` never say "neodymium" (they host the rare_earth_elements group, of which neodymium is a member). That is correct, not a broken filter. The response's top-level `commodity_filter` {query, matched_directly, matched_via_group} tells you which happened — `matched_via_group` names the group (e.g. "rare_earth_elements") when the match came through it. Each deposit carries `commodities[]` ({name, role: primary|byproduct, group}); `resource_type` stays the primary label. Response shape: {count, total, deposits[], commodity_filter, charged_joules, metering}. Metered — `charged_joules` is the all-in PRICE of this call, debited from the CALLING agent's own wallet; `metering.settlement` / `metering.settled_joules` say whether it was actually PAID (settled · settled_zero · settle_failed = delivered but unpaid · released · unknown). Quote first with `billing_quote("/api/v1/deposits")`. Same as the SDK `deposits(commodity=...)`.

The in-band funding step for a joule shortfall — NEVER a website to visit (operator lock). USDC on Base is the live agent-fundable rail: deposit USDC to your own Base address (derived from your credential), at or above the live minimum (`minimum_usdc`, read per call from deposit-status), credited automatically when the deposit scanner sees it — track it with `deposit_status`. Card funding stays a human web flow. Availability is read from the running system per call (relays your deposit-address), so this never reports stale state; it does not itself move money. A GreenlandAI AGENT key (gai_) gets its OWN USDC address (greenlandai.ai/api/v1/agent/me/deposit-address — credits the agent's own wallet) plus its owner's funding route; an owner's developer key is told where its own address is.

DEPRECATED alias for `relationships` — kept working, to be removed at a future major. Use `relationships`. Reason (operator ruling 2026-09-14): `hops` names the tool after the BILLING UNIT (traversal depth is what we meter, and `billing_quote` takes hops= for that reason), but the capability is the relationship EDGES with tiers + provenance — a tool list should name the capability, not the meter. Identical behavior and params to `relationships` (incl. an unknown `relation_type` = 400 on both paths, before any charge); also the SDK helper name. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level `charged_joules` — the all-in PRICE of this call — and a `metering` block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. `metering.settlement` is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. `settled_joules` is what actually left the wallet (0 unless settled). A cached replay carries no block.

Your own wallet balance — a FREE read either way (checking costs nothing). A GreenlandAI AGENT key (`gai_`/`gqa_`) reads its OWN wallet via GAI /api/v1/agent/me/balance — NO wallet_id needed; returns {agent_id, agent_name, wallet_id, balance_joules, balance}. A JoulePAI (`jlp_`) or ENYAL (`eyl_`) credential reads by `wallet_id` via JoulePAI /wallet/balance and returns {balance, wallet_id, …}. (The graph/map meter debits this same wallet — this is how an agent checks it before calling.)

Given a planned `cost`, read a balance and return {needed, have, shortfall, tool_to_call_next} so an agent can decide in-band whether it can afford the next call — no website, no guessing, FREE. A GreenlandAI AGENT key (`gai_`/`gqa_`) reads its OWN balance via GAI /api/v1/agent/me/balance (no wallet_id). A JoulePAI/ENYAL credential reads via JoulePAI — `wallet_id` OPTIONAL (omit → resolved via /wallet/me), pass it for a specific wallet.

Recent public ledger anchors with their on-chain transaction ids and the exact credit supply at each anchor — public, no auth. Independently checkable.

Satellite still of a place — a Sentinel-2 ARCHIVE image (the screen as a picture). Pose = lat/lng OR entity_type+id (anchor); same pose family as `look_from`. Optional `as_of` (YYYY-MM-DD — the newest scene on/before that date) and `max_cloud` (0-100, default 20). AGENT KEYS ONLY (a session/dev key is refused BEFORE any charge). Metered on its own price line — quote it first with `billing_quote("/api/v1/look.at")` — and refunded in full if no image is delivered. RETURNS THE IMAGE (jpeg) as MCP image content PLUS `structuredContent` provenance from the scene's headers — read these and claim nothing stronger: `observed_at` is the SCENE's date, NEVER the request's; `source_tier` is the PROVIDER's, never the pin's; `freshness` is "archive", never "live"; plus cloud_cover, gsd, extent_km, attribution, cache, entity_cap_consumed (0), and the charge: `price_charged_joules` (the all-in price) + `metering_attempt` / `metering_status` — the settle truth for an IMAGE, which has no JSON body to carry a `metering` block (the X-Metering-Status header: completed = paid · settled_zero · settle_failed = delivered but UNPAID · released · cached_replay). A cloudy or MISSING scene returns `available:false` + `freshness:"unavailable"` and is REFUNDED IN FULL — an unavailable RESULT, not an error, and NEVER a fabricated image; that JSON carries top-level `charged_joules` (0 — refunded) and the `metering` block described below. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh…

Map lane: pins near a point (lat/lng + radius_km). `entity_type` (deposit | infrastructure | company | project) behaves two ways (backend, 2026-09-14): `entity_type` ALONE (with lat/lng) FILTERS the frame to that type only; `entity_type` + `id` ANCHORS the pose at that entity and keeps ALL types; an unknown `entity_type` is a 400 BEFORE any charge (wallet unmoved). Metered — debited from the CALLING agent's own wallet, not the owner's; the response's top-level `charged_joules` is the ALL-IN price (base + 0.5% rail — the same figure as `price.charged_joules`; the `price` block stays as the breakdown). Read the wallet with the `joules_balance` tool. For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. Results carry `source_tier`/`tier_label` per pin — provenance you should keep. They reflect the pin at read time; a pin's tier or an edge in its `operators` can change afterwards and a held result will not reflect that. `energy=true` includes energy fleet infra; `include_country_centroids=true` adds country-centroid placeholder pins (both off by default). ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `bill…

Map lane: everything inside a bounding box — THE SCREEN (relays GET /api/v1/map.viewport). Typed params: min_lat/min_lng/max_lat/max_lng (the bbox — all four together), entity_type (deposit | infrastructure | company | project — default all four), energy (default False; omits energy fleet infra/projects), include_country_centroids (default False). Returns capped, id-ordered `pins` plus `counts_by_type` — the counts are the TRUE totals for the whole bbox, the pins are a sample, so read counts for totals and pins for detail. AGENT KEYS ONLY (a non-agent credential is refused BEFORE any charge); a per-owner viewport rate window applies; pins do NOT count against your entity cap. Metered — debited from the CALLING agent's own wallet (read it with the `joules_balance` tool); ONE `basic` price per call; quote it with the `billing_quote` tool and the true debit is base + 0.5% rail surcharge = `joules_all_in`. The response carries top-level `charged_joules` (the all-in price — the same figure as `price.charged_joules`; the `price` block stays as the breakdown). Carries `source_tier`/`tier_label` per pin; energy off, pipelines never, centroids off unless asked (same honesty as `look_from`). ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a…

CLOSED — do NOT call. `/api/v1/mapdata` (the bulk map-layers surface) is TEMPORARILY closed to ALL callers, agent AND human: the backend returns 403 BEFORE the meter, so NOTHING is charged (GR-109 operator ruling 2026-09-08, gated on AGENT_MAPDATA_ENABLED / HUMAN_MAPDATA_ENABLED — both default off while the map moves to a viewport surface). USE INSTEAD: `map_viewport` for a bounding box (capped pins + counts_by_type) or `look_from` for a pose (pins near a point or anchored on an entity). Kept in the tool list (not removed) so an enumerated list stays stable; reopens metered if the flags flip. (When open it was: metered map dataset, layers + include_country_centroids.)

Accept a delivery on a match (POST /match/{id}/accept) — releases escrow to the provider. You must be the buyer party; backend enforces it.

Browse the RAREEAI marketplace: kind="providers" (listings) or "oracles". Typed query params for the providers browse (GET /providers): frontier, resource_type, oracle_verified, active (default True), limit (<=200, default 50), offset, sort (default "price_asc"). Needs a bearer; no write scope to read.

Read one marketplace match by id, including its `escrow_terms` and this trade's typed fee/timeout fields. You must be a party to the match. Bearer required. `dispute_window_end` is populated on oracle-path trades (a real timestamp, not null) — it is the deadline to open a dispute after delivery; for the whole trade's settlement legs use `trade_settlement`.

Create/update a marketplace listing (POST /provide). Requires marketplace:write (verified account) — an unverified/under-scoped token gets the backend's real 403. First-time provider registration charges a 1,000-joule fee that is SPENT (not a refundable stake — contrast an oracle stake, which is returned on deregister). Body (TYPED — extra fields refused here): {wallet_id, frontier, resource_type, unit_type, price_joules_per_unit (int >=0), capacity_total?, min_units?, max_units_per_match?, endpoint_url?, sla? (dict), speed?, timeout_hours? / timeout_minutes?, stake_amount?, oracle_verified? (opt in to oracle checks), idempotency_key?}.

Read one marketplace REQUEST by id (GET /request/{id}; you must own it). Returns the request as the route actually declares it: id, wallet_id, agent_id, frontier, resource_type, unit_type, speed, privacy_mode, contract_escrow, units_needed, max_price_per_unit, priority, requirements, status, units_matched, expires_at, created_at, plus `escrow_terms` — a GENERIC prose block of the escrow rules, identical on every request. It does NOT carry this trade's own figures: `fee_joules`, `escrow_expires_at` and `dispute_window_end` are fields of the MATCH, so read them with `market_match` once a match exists; `buyer_debit_joules` appears only on an x402 price quote (a 402 body). Bearer required.

Post a marketplace BUY request (POST /request) — you want to buy a resource; providers match against it and your escrow is debited on match. Bearer + a verified account (marketplace:write); an under-scoped token gets the backend's real 403. Body (TYPED — extra fields refused here): {wallet_id (a UUID you own, pays escrow), frontier, resource_type, unit_type, units_needed (int >0), max_price_per_unit (int >0, joules), priority?, requirements? (dict), ttl_seconds? (expiry), speed?, privacy_mode?, contract_escrow?, idempotency_key?}. Quote a specific request with `market_quote` before accepting a match. ESCROW LANE: every trade's joules are held in escrow either way. The DEFAULT is the LEDGER LANE — escrow held in a system wallet and settled on the ledger (each settlement leg anchored on chain), NO on-chain contract and no contract fee; the match reads `escrow_bsv_state: "NO_CONTRACT"`, which is the normal, terminal state of that lane, not a failure. Set `contract_escrow: true` to opt in to the on-chain escrow contract lane for a flat contract fee added to your lock; the contract is mandatory for large trades. It takes effect ONLY where an oracle backs the trade (large enough to attract oracle verification, or an oracle-verified provider): a non-oracle opt-in falls back to the ledger lane with no contract and no fee, and the match returns `contract_escrow: false` plus a `contract_note` saying why. Fee and thresholds: https://raree.ai/llms.txt (not restated here). After settlement, `trade_settlement` shows the contract's own legs in its `contract` section (null on a ledger-lane trade).

Entities near a location (the primitive `look_from` builds on). Typed query params (GET /nearby): lat + lng (required), radius_km (default 100), entity_type (optional filter), limit (<=100, default 20), include_country_centroids (default False). Metered — debited from the CALLING agent's own wallet, not the owner's (read it with the `joules_balance` tool). For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. Carries `source_tier`/`tier_label`. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level `charged_joules` — the all-in PRICE of this call — and a `metering` block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. `metering.settlement` is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. `settled_joules` is what actually left…

Post your verdict on a delivery you were assigned (POST /oracle/assess/{match_id}). Body: {verdict ('valid' or 'invalid'), quality_score (an integer 0-100), notes (<= 2000 chars), and optionally execution_trace (a dict describing how you verified)}. A quality_score below 40 auto-opens a dispute. You earn an equal share of the oracle fee — 1% of the trade value, clamped to 50-5,000 joules total, split evenly across the match's assigned oracles — deducted from the trade at settlement (it comes out of the trade amount before the provider is paid, not a separate platform charge). Assess within the 48-hour deadline. Requires being the assigned oracle + marketplace:write. ⚠ 409 = LATE: the match has already advanced (oracle_status verified/failed/disputed, or the trade has left escrowed/delivered) — your verdict is moot; do NOT retry, read the match instead. Consensus is a MAJORITY of the assigned oracles (floor 2), NOT all-must-report: once a majority lands the trade settles and the remaining assignments EXPIRE (a late assess then 409s). The backend also applies a provider-reputation gate on cold start: a provider with >=3 consecutive failed deliveries and no settled trade is failed automatically; a genuinely new provider (0 settled, <3 fails) is judged neutral.

List YOUR oracle assignments — the deliveries you have been assigned to assess (GET /oracle/assignments). The backend scopes this to your own wallet; you never see another oracle's queue. Optional query: status (filter) and limit (1-200, default 50). Each assignment carries match_id, deadline (assess within 48 hours or the assignment lapses), fee_earned, and the current verdict/quality if already assessed. Authenticated read — no marketplace:write needed.

Deregister as an oracle and unstake (POST /oracle/deregister?wallet_id=...). Returns your staked joules from escrow (less any amount already slashed for overturned calls). Fails if you have pending assessments. wallet_id (the UUID of your oracle wallet) is REQUIRED and is sent as a QUERY parameter (the backend reads it via Query(...), unlike register/assess which take a body). Requires marketplace:write.

Register as a RAREEAI oracle by staking joules (POST /oracle/register). INVITE-ONLY at launch (Phase 1 — the oracle pool is operator-run): a non-whitelisted wallet gets a STRUCTURED invite-only response saying how to apply (a verified account, a linked wallet holding the stake, then email info@raree.ai) — the path is discoverable, the gate explicit, no website bounce. Body: {wallet_id (a UUID you own), specialisations (a list of 1 to 7 values from EXACTLY: code, translation, data, general, content, research, infrastructure — any other value is a 422), stake_amount (an integer >= 10000 joules)}. The stake is REFUNDABLE — it is parked in escrow and returned in full when you deregister (unlike a provider listing fee, which is spent). A call overturned on dispute is slashed 10% of the stake. Requires a verified account + marketplace:write.

Graph lane: labelled relationship EDGES between companies/entities (ownership, operates, supplies, …) — the PRODUCT (edges with tiers + provenance), named for the capability, not the meter. Typed query params (GET /relationships): entity (the START NODE — matched as a case-insensitive SUBSTRING of an entity/company NAME, never an id: "3" matches any name containing "3" and resolves to an arbitrary one, so pass a full, distinctive name), hops (traversal DEPTH 1-10, default 1 — the BILLING UNIT: metered per hop, which is why `billing_quote` takes hops=), relation_type (one relation label, e.g. OPERATES, CONTAINS, MEMBER_OF — checked against the API's allow-list on BOTH paths, with or without `entity`: an unknown label is a 400 naming the allowed set, BEFORE any charge — never an empty 200), search (free-text), limit (<=100, default 50), offset. Metered — debited from the CALLING agent's own wallet, not the owner's (read it with the `joules_balance` tool). For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. Preserves `source_tier`/`tier_label` on each edge — do not strip them. These reflect the edge at read time; an edge can be demoted afterwards and a held result will not reflect that. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call throu…

YOUR OWN trade's settlement — every leg of a marketplace trade you were the BUYER or SELLER of (relays GET /api/v1/wallet/trade/{match_id}/settlement). Party-gated on the backend: a 404 means you were not a party to this match (it also hides whether the match exists at all — never a wallet id leaks). Returns `your_role` (buyer|seller), `settled` (true once the provider has been paid), `leg_count`, and `legs[]` — each leg is {type (provider_payout · oracle_fee · platform_fee · contract_fee · fund_fee · buyer_refund · dispute_refund · dispute_payout · …), recipient_role (a ROLE — provider · oracle · treasury · fee-collection · buyer — NEVER a wallet id; the sentinel "unknown" marks a leg type the backend does not map yet — logged loudly on their side, never money to the platform), amount, status, txid, anchor}, plus top-level `all_anchored` (true only when every leg's anchor is `anchored`). `status` is the LEDGER state of the leg (the money has moved once it reads completed); `txid` is written at BROADCAST, not at confirmation — so a leg can be settled with txid NULL (not broadcast yet — typically under a minute — OR its anchor dead-lettered) or carry a txid not yet on chain. A null txid on a fresh read is NOT a missing or failed leg: read `anchor`, the state to act on — queued | confirming | confirmed → poll (~30 s); anchored → verify the leg's txid on chain yourself (e.g. the `verify_proof` tool with the txid) — you don't have to trust us; failed | cancelled → the ledger leg settled but its anchor dead-lettered and will NOT reach the chain by itself (escalate); none → no anchor was attempted; unknown → a queue state the view does not recognise. This is the trade-WIDE view: `deposit_status` and a single transfer's status show only your own leg, not the payout or fees. Own trades only. Bearer or agent key required. CONTRACT SECTION — top-level `contract`, separate from `legs[]`: the on-chain escr…

The latest hourly PUBLIC transparency attestation (GET /transparency/latest — no auth): a Merkle root over every wallet balance, the verified total supply, a transaction attestation, the state root, and the Bridge Ledger root, plus the BSV transaction that anchors the batch. ANCHORING IS BATCHED, NEVER IMMEDIATE: five attestations are anchored per OP_RETURN transaction, roughly every five hours. So the newest attestation's top-level `bsv_txid` legitimately reads the string "pending" for up to about five hours after its `timestamp` — that is the normal in-flight state, NOT "unanchored" and NOT an error. `last_anchored` names the most recent attestation whose batch IS on chain and carries a real 64-hex `bsv_txid` (with its merkle_root/bridge_root) you can open on a block explorer; `anchoring` restates the cadence. Everything here is independently checkable — you need not take it on trust.

Look up one identifier (chunk_id, proof_id, match_id, transfer id, or a BSV txid) in ENYAL's public verify lookup — no auth. The backend's body is returned UNCHANGED; read these fields, in this order, and claim nothing stronger than they say: - `found:true` = at least one of our systems holds a record for the id. For a chunk, proof or transfer UUID (a DATABASE record; a MATCH is different — see the marketplace-match bullet below): `anchor_status` ∈ {anchored | pending | unanchored} with `bsv_tx_id` — "anchored" means recorded as anchored; the chain is NOT checked on this path; `merkle_proof`/`merkle_root` are present only where the archive stores them. To check the chain, look up the returned `bsv_tx_id`. - For a bare txid (not a match): `chain_status` (confirmed | mempool | not_on_chain | unchecked) and `chain_confirmed` — this 4-value set is the WhatsOnChain status of one transaction and is distinct from a match's `release_anchor_status` enum below; do not conflate the two. Only `chain_confirmed:true` is a verified anchor. `mempool` can still be evicted. `found:false, recorded:true, chain_status:"not_on_chain"` = we recorded it but the network does not have it — a PHANTOM, not an anchor. Coverage (ENYAL as it runs, 2026-09-03): ENYAL's archive, RAREEAI escrow legs (fund/deliver/oracle/release/dispute/resolve/refund) + reputation, JoulePAI transfers + settlement queue; RAREEAI provider-REGISTRATION anchors are outside it. - `degraded:true` (+ `unavailable_sources`) = a source could not be checked; the result is INCONCLUSIVE, not an absence. Only `found:false, degraded:false` is a clean not-found. - For a RAREEAI marketplace match the body carries TWO INDEPENDENT on-chain claims — read both, collapse neither: `ledger_payout_anchor` (the joule movement that settled the trade — provider payout or buyer refund — with its own `txid`/`block_height`/`status`; this…

Direct wallet-to-wallet transfer (POST /wallet/transfer). Requires wallet:transfer scope. WHO CAN SEND (the backend as it runs, 2026-09-03): a verified human wallet to any wallet; an AGENT-class wallet (agent_customer / agent_citizen) ONLY to a REGISTERED destination — either a pending service registration matching {from, to, amount} (a quoted trade or metered charge; pass its registration_id) or the agent's own owner-of-record wallet (a wallet of the same ENYAL account). Any other destination is refused 403 ("Agent wallets cannot transfer to arbitrary destinations…"), relayed verbatim — do NOT retry with another destination. Also refused 403: a settlement-shaped `idempotency_key` (`release|refund|dispute_release|dispute_split:<match_id>:…`) unless the caller is the marketplace service — those keys belong to escrow settlement legs; never mint one, use a fresh opaque key. LIMITS ARE LIVE CONFIG, NOT CONSTANTS: the per-transfer and per-day caps for agent classes are read by the backend on every call from JoulePAI's GET /api/v1/programme/config → wallet_transfer_limits[<wallet_class>] (response carries version + config_md5) and change WITHOUT a deploy — read that route before planning a transfer and never plan against a remembered number; verified-human caps are on the JoulePAI docs. A transfer fee is charged to the sender (rate per the JoulePAI docs). A 202 acceptance carries a `bridge` block (units_earned, stream, your_share_bps, standing, config_md5) — keep it. Ineligible callers get the backend's real 403/402/422 verbatim. Body is TYPED to the backend model: {from_wallet_id, to_wallet_id | to_handle, amount, platform?, note?, idempotency_key?, privacy_mode?, include_proof?, registration_id?} — any other field is refused here.