--- title: "OTER" path: "/ecosystem/oter" version: "2.3.0" author: "Hydrate" createdAt: "2026-07-03T07:45:37.788Z" updatedAt: "2026-08-09T07:09:10.736Z" --- # OTER | **OTER – Optimistic Truth Engine** | | Optimistic oracle | | [Ecosystem](/ecosystem) (Oracle) | | [Radix](/contents/tech/core-protocols/radix-engine) | | 🟡 Pre-launch (beacon live in production) | | "The truth will out." | | Staked jury, timelock-sealed ballots, single round | | √stake (square root of staked amount) | | 4 hours default, configurable per question | | 48 hours (24 h commit · 12 h reveal · 12 h re-propose) | | Pull-based, atomic – consumers read in their own transaction | | [OTER Beacon](https://random.oter.io/) – BLS12-381, 3-second period | | Staker DAO – same sealed √stake vote as a dispute | | [Tāhuna](/ecosystem/tahuna) (prediction markets) | | [OTER XRD Governance](https://blog.oter.io/posts/xrd-governance-design-disclosure) – announced 8 Aug 2026, unreleased | | [oter.io](https://oter.io) | **OTER** (Optimistic Truth Engine, tagline "The truth will out.") is an [optimistic oracle built on Radix DLT](https://oter.io). Any dApp or person can post a verifiable question – an election result, a price level, a real-world event – with a reward for resolving it. A proposer answers and locks a bond behind the answer; if nobody disputes it before a challenge window closes, the answer stands and settles on-chain. Only contested answers go to a vote, decided by staked jurors casting [timelock-sealed ballots](https://oter.io). The design combines sealed-ballot juries, bonded answers, and atomic settlement. OTER is one of two oracle projects recorded on this wiki alongside [Religant](/ecosystem/religant), and is the resolution layer behind [Tāhuna](/ecosystem/tahuna), a prediction-market protocol also building on Radix. For the general pattern of consuming an oracle from a Radix blueprint, see [Oracle Integration](/developers/scrypto/08-oracle-integration) in the Scrypto tutorials. ## How a question settles The protocol documents a five-stage lifecycle, of which most questions only ever traverse the first three. A question is **asked** with a reward attached; a proposer **proposes** an answer and locks a bond behind it; a public **challenge** window opens, during which disputing the answer costs a counter-bond. Where nobody disputes – the design's expected path, and the reason it is called optimistic – the window closes untouched and the answer stands with no vote and no jury. Only a disputed answer reaches the remaining two stages. Staked participants **vote** using timelock-encrypted ballots, so no ballot can be read while voting is open and no losing vote can be quietly buried after the fact. The verdict then **settles** on-chain, and the losing bond is slashed in full. Per the project's published specification the slash is split **80% to the winner, 15% to the correct voters, and 5% to the protocol**, with voter rewards [paid in rUSDC rather than a platform token](https://oter.io). If a round fails to reach quorum instead, bonds refund and no committed vote is rewarded or slashed. ## The jury draw and the OTER Beacon The jury for each dispute is drawn from a public randomness beacon rather than chosen by the protocol operator. The project runs the [OTER Beacon](https://random.oter.io/), a [drand](https://drand.love)-aligned min-pk BLS12-381 randomness beacon whose output is verifiable natively on Radix. Reading its [public info endpoint](https://random.oter.io/info) on 29 July 2026 returns the scheme `oter-min-pk-g2-pop` – unchained, public keys in G1 and signatures in G2, domain-separated under `oter-jury-beacon:v1` – on a **3-second period**, with the [health endpoint](https://random.oter.io/health) reporting the chain live and current (round 30,835,175, two seconds behind head). The draw itself binds the jury to a beacon round that does not yet exist when ballots lock. Jurors commit timelock-encrypted votes while the round that will seat the jury is already named but unpublished; at reveal time that round's BLS signature is published as one canonical value, the contract verifies the signature on-chain, and the seed is derived as `keccak256(signature)`. Seats are then allocated by `keccak256(seed ‖ voter)`, which the specification says seats roughly [97 of every 100 revealed votes](https://oter.io). Because the signature cannot be served before its round time, no participant can predict or grind the seed in advance, and none can buy a guaranteed seat. OTER states that it [upstreamed the beacon verification into the Radix engine itself](https://oter.io) and describes the beacon as an open public good available to any Radix project, not only to OTER. ## Protocol parameters The following defaults are published in OTER's own protocol specification (marked *rev. 2026-07*) and are subject to change by staker governance. They are recorded here as documented, not as independently verified on-ledger behaviour – the oracle is not yet on mainnet. | 4 hours default, configurable per question | | 48 hours – 24 h sealed commit, 12 h reveal, 12 h to re-propose and dispute | | Next cycle – an escalated question re-enters immediately rather than waiting a full extra round | | 70% supermajority of revealed voting power | | Exponential moving average, easing in at 5% for the cold start then tracking real participation | | √stake – doubling a position buys about 41% more vote, not twice as much | | ~97% of revealed votes seated, drawn from the beacon seed | | Slashed in full – 80% winner / 15% correct voters / 5% protocol, paid in rUSDC | | 25 questions per vote cycle | | 3 attempts – bonds refund and nobody is slashed, then a time-boxed close as invalid | | 7 days | | Yes / No / Draw, plus DAO governance votes; further types plug in as adapters | The square-root curve is the parameter the project argues hardest for. Simulated against a live oracle's real staker distribution, it [reduces the top holder's share of voting weight from 24.1% under linear weighting to 3.6%](https://oter.io), and the top ten holders' combined share from 59.5% to 15.8%. Capital still counts; the claim is that domination does not scale with it. ## Governance OTER's parameters, question types and even its jury beacon are changed by the same machinery that settles a dispute, rather than by a team key. Any stake-ticket holder can bond a rule change, but the target must already sit on the DAO's allowlist and the exact action is bound into the proposal at creation – it cannot be swapped afterwards. Unlike a question, a proposal gets no optimistic pass-through: every rule change is [forced to a vote immediately](https://oter.io), on the same sealed ballots, the same √stake weighting and the same supermajority. Execution is fail-closed. Only a settled *Approve* dispatches, replaying exactly the action that was voted on against the bound target, and the proposer's bond returns with a reward. A rejected proposal executes nothing and forfeits the proposer's bond to the voters who turned it down, which is the protocol's answer to rulebook spam. There is no separate governance token and no second electorate – whoever can judge a dispute judges the rules on identical terms – and an administrator can bootstrap the allowlist but never decide a vote. For how Radix approaches on-ledger governance more broadly, see [Radix Governance](/contents/tech/core-concepts/radix-governance). ## Consumers and use cases Settlement is **pull-based**: a Radix contract reads the settled outcome inside its own transaction, rather than waiting for an oracle callback or a keeper bot to push it. The project argues this removes a class of failure common to push oracles – there is no queue to stall or front-run, and one settled answer can drive any number of dApps at once. This is the same atomic-composability property that [Radix Engine](/contents/tech/core-protocols/radix-engine) provides to asset movements. The documented target applications are prediction markets, parametric cover (releasing a payout once a claim survives the challenge window, with no manual adjuster), cross-dApp settlement of facts including facts about other networks, and price-settled products. For the last of these OTER points at a companion resolver built in the Tāhuna stack that verifies [Pyth signed price updates entirely on-chain](https://oter.io) – signer quorum, emitter check and Merkle inclusion proof – settling up/down candle markets deterministically with no dispute round, on the reasoning that a price feed and a dispute game answer different kinds of question. The project also operates [OTER PoP](https://idos.oter.io), a proof-of-personhood component. ## XRD Governance On 8 August 2026 the project published a design disclosure for **[OTER XRD Governance](https://blog.oter.io/posts/xrd-governance-design-disclosure)**, a voting platform for the [Radix Network DAO](/ideas/radix-network-dao-charter) transition built as a client of the oracle rather than as a separate system, and [announced it the same day](https://t.me/radix_dlt/997470) in the Radix DLT Telegram. The proposing and voting surface is deliberately unchanged from the [Consultation v2](/ideas/dao-governance-app-consultation-v2) app the DAO already uses: one signature, no deposit and no token lock, voting power counted as XRD held, staked and pooled at the snapshot taken when voting opens, and the same Temperature Check → elevation → Governance Proposal workflow, with elections run under Majority Judgment as the [Proposal & Voting Framework](/ideas/dao-proposal-voting-framework) specifies. What the platform changes is what happens once voting closes. The design starts from a constraint the disclosure states plainly and that applies to every platform on the network: *the tally cannot be computed on-chain*. Voting power depends on balances at a historical snapshot, and a Radix component cannot read historical state – XRD does not report a total supply on-ledger at all – so every governance app, including the one in use today, counts the ballots off-chain and publishes the total. A published result is therefore a statement by whoever ran the count. OTER's answer is to make that statement an oracle question: the tally is emitted as a canonical, hash-pinned document carrying its weight rule, source register, snapshot and counting rule, then **posted on-chain as a bonded assertion** with a public challenge window. An unchallenged assertion settles; a challenged one costs a matching bond and goes to the same staked jury, sealed timelock ballots and loser-pays slashing that settle any other OTER question. Three components support the claim that the result is checkable rather than merely published. An **independent verifier** – described as a second implementation in a different language sharing no code with the tally engine – recomputes any published result down to the exact bytes of the document, so a disagreement between the two is mechanical rather than a matter of argument. A **keeper** that anyone can run recomputes every live assertion and publishes its verdict through a public API; its detection half is stated to need no keys, no funds and no permission, which is the project's answer to the honest-challenger assumption every optimistic system rests on. And a settled *Approve* on a binding proposal **executes its own bound action** – a treasury payout, a payment stream, a parameter change – through the governance components after a pre-execution hold fixed into the contract at deployment, with no setter to shorten or disable it. The disclosure also says the security-carrying parameters (the floor on the challenge window, the jury's timing windows, the bounds on the bond-to-value ratio) carry no setter for anyone, and that the operator's remaining powers are enumerated and renounceable. The post is explicit about what it does not claim. The snapshot weighting stays off-chain because the ledger permits nothing else; the optimistic model still assumes one honest challenger per window; and the governance framework itself is pre-ratification and moving, which the platform accommodates by hardcoding none of its numbers. It credits the current DAO app for "the pioneering work of getting DAO governance this far" and names that framework as the standard it measures itself against. **None of this is verifiable on-ledger yet**: as of 8 August 2026 the platform, the verifier and the full technical disclosure are stated as releasing "within the week", and the material recorded here is the project's own design disclosure rather than observed behaviour. ## Reception The disclosure closed by inviting “feedback, scepticism, and challenge”, and drew all three the same evening in the channel it was announced in. [Matus asked](https://t.me/radix_dlt/997473) who runs the first keepers, what the source of snapshot truth is and how the bonds are calibrated, then [followed up](https://t.me/radix_dlt/997477) on the full adversarial model, jury behaviour in failure modes and the upgrade path; [Nicolai of Sentura asked](https://t.me/radix_dlt/997475) whether on-chain settlement is confined to a predefined call set or can execute any transaction on the ledger. None of those questions had a published answer by the end of 8 August 2026. The substantive objection came from [Daffy](/community/daffy), who maintains the [DAO governance framework](https://github.com/Shadaffy/radix-dao), in a [point-by-point reply](https://t.me/radix_dlt/997479) the same evening. He accepted what he called the good half – the hash-pinned tally document, the independent verifier and the permissionless keeper – as a genuine improvement that could have been contributed to the existing [Consultation app](/ideas/dao-governance-app-consultation-v2) as a pull request rather than rebased onto a new protocol, and said parts of it overlap almost point-for-point with an unpublished result-verification requirements document written for a Majority Judgment election newly added to that app. His objection is to the settlement layer. OTER, he argued, models the risk as the operator lying about the tally; but the mandate is non-discretionary and a tally is a total function of a public record, so the verifier on its own is already the complete answer to that risk. The DAO's controls, on his account, are ex ante and legal rather than ex post and economic, and they sit on the treasury side: a verified invoice, a KYC-verified recipient, multi-signature thresholds written into the Operating Agreement, and signers carrying a duty to refuse an unlawful execution. A correctly tallied but unlawful proposal would still settle *Approve* and execute itself, because the jury is only ever asked whether the arithmetic was right – and treasury outflows triggered by the verdict of an anonymous, self-selected, bonded jury would place influence over company assets outside the signer structure, outside the compliance gate and outside the arbitration agreement. The provisions that objection rests on are published, and most of them check out. The **Asset Lock** is real and entrenched: [Charter](https://github.com/Shadaffy/radix-dao/blob/master/Charter/charter.md) §10–§11 bar any distribution to members and require remaining assets to pass to a qualifying successor entity on dissolution, and §12.1 places both beyond amendment by any governance proposal at any approval level. The **annual BOIR** filing is [Operating Agreement](https://github.com/Shadaffy/radix-dao/blob/master/Legal/Formation/Operating-Agreement.md) §8.1, under Marshall Islands DAO Act §712; the **25% test** is §4.6, which classifies any member above a quarter of eligible voting power as an Ultimate Beneficial Owner and gives them 14 days to complete KYC once they cross it (§8.2); and the **multi-signature thresholds** are §7.1 – 3-of-5 treasury signers for a standard transaction, 4-of-5 for one classified high-risk. Two details in the reply do not match the published text. Statutory KYC is Article VIII, not Article X, which covers amendments. And the arbitration clause is not an LCIA clause seated in London: §11.1 and the [Legal Wrapper](https://github.com/Shadaffy/radix-dao/blob/master/Legal/Policy/Legal-Wrapper-and-Representation.md) both specify the International Arbitration Rules of the **ICDR**, seated in the **Republic of the Marshall Islands**, in English, before a sole arbitrator, with Marshall Islands governing law (§11.2). One caveat sits under the whole exchange, and it cuts against both sides of it. The wrapper those gates live in is not operative yet. The Operating Agreement carries a status header reading “Pre-adoption draft – not yet operative” and requires a Governance Process proposal at ≥60% approval and ≥7% quorum to be adopted; the [Certificate of Formation](https://github.com/Shadaffy/radix-dao/blob/master/Legal/Formation/Certificate-of-Formation.md) is a working draft awaiting filing with the Marshall Islands Registrar. Both remain [open transition work](/ideas/dao-incorporate-duna-llc). The compliance gates are therefore proposed rather than in force, and so is the platform they are being weighed against – OTER's own release was stated as within the week of 8 August 2026. One further detail is worth recording for whoever revisits this: §6.5 of the same agreement assigns formal determination of a vote's outcome to the [RAC](/ecosystem/radix-accountability-council) rather than to the Governance Operator, treats the on-chain record as authoritative for raw vote data and the RAC's published result as authoritative for the outcome, and already provides a veto-challenge window for results said to violate the Charter. ## The independent verifier The disclosure rests its case on reproducibility: a result is published as a canonical document whose bytes hash to a value posted on-ledger, and the post argues that "you can recompute it" is only worth as much as the tools to do it. It says a verifier — "a complete second implementation, written in a different language, sharing no code with our engine" — was built and open-sourced, and separately lists the verifier among the things releasing "within the week". The artifact is public and predates the post: [`OTER-Labs/radix-tally-verify`](https://github.com/OTER-Labs/radix-tally-verify), Apache-2.0, created on 4 August 2026 and last pushed on 7 August, the day before the disclosure appeared. The post carries no link to it; the repository's own README describes exactly the design the post claims, on the reasoning that "a verifier that shares an implementation with the thing it verifies agrees with it by construction, including where both are wrong." Being a second implementation by the same organisation, it is independent of the code, not of the party. What it recomputes, from the TypeScript in the repository rather than from the announcement: each voter's weight from [Gateway](/contents/tech/core-protocols/radix-gateway-api) historical state at the snapshot the document pins — XRD plus validator stake units at their redemption rate plus round-trip-verified native pool units — then the verdict, by applying the document's own stated quorum, thresholds and seat rule to those weights, and only then the canonical re-serialization and the `blake2b-256` hash. The README is explicit that the hash check is "the cheap one" and the first two steps are the point. Arithmetic is a 192-bit fixed-point `Decimal` with 18 decimal places and truncating division, with no floating point anywhere: an IEEE-754 double carries about 15 to 16 significant decimal digits, and these values carry 18 after the point alone. The part that distinguishes it from a checksum tool is that it grades its own disagreements. Its four exit codes separate a figure difference (the real signal — someone's arithmetic, weights or ballot set is not what they published) from a serialization difference (figures agree, bytes do not — a spec departure, most often a `Decimal` parsed as a float or keys left in insertion order), and both from *unknown*, which is what an unreachable Gateway or a pruned state version returns. The stated reason for the third is operational rather than cryptographic: "a verifier that reports infrastructure trouble as a discrepancy trains people to ignore it." One rule in it is checkable against the DAO's own text. The verifier settles a Majority Judgment candidate's grade at the *Grade Quantile* the document publishes, and records that the quantile "was the median until 2026-08-05". The Radix DAO's [Proposal & Voting Framework](https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/proposal-and-voting-framework.md) §6.2.4 defines the Grade Quantile as three-fifths, set deliberately to equal the Election Stage 2 approval threshold "so that both mechanisms put the same share-of-turnout test to a candidate", and notes that at one half it would be the median of the literature. Both documents also resolve an exact landing upward, and for the same reason — the comparison `at_or_above × denominator ≥ cast × numerator` is one a challenger must reproduce without ever dividing, which is why the quantile is carried as a fraction and a decimal is refused as malformed. The verifier recomputes each document under the fraction that document carries rather than under today's, so that a result settled under the older rule does not report as a lie. ## Status As of July 2026 OTER is **pre-launch**: oter.io describes the protocol as "Pre-launch · Built on Radix DLT" and offers [a mailing list for "mainnet milestones, testnet access, and protocol deep-dives"](https://oter.io/#signup). The published specification is dated *rev. 2026-07*. The randomness beacon, by contrast, is already running in production and served a healthy response when checked on 29 July 2026. [Tāhuna](/ecosystem/tahuna) is listed as the founding integration and is itself pre-launch, with a testnet targeted for Q3 2026. The project surfaced in the Radix Developer Discussion Telegram in July 2026. On 8 August 2026 the project announced [OTER XRD Governance](https://blog.oter.io/posts/xrd-governance-design-disclosure), a Radix DAO voting platform built on the oracle, with the platform, its independent verifier and a full technical disclosure said to be releasing within the week. ## External Links - [oter.io – official site and protocol specification](https://oter.io) - [OTER XRD Governance – design disclosure (8 Aug 2026)](https://blog.oter.io/posts/xrd-governance-design-disclosure) - [random.oter.io – OTER Beacon (live randomness)](https://random.oter.io/) - [Beacon info endpoint – public key, scheme, period](https://random.oter.io/info) - [Beacon health endpoint – latest round and lag](https://random.oter.io/health) - [OTER PoP – proof of personhood](https://idos.oter.io) - [drand – the distributed-randomness scheme the beacon aligns with](https://drand.love) - [OTER-Labs/radix-tally-verify – the open-source tally verifier (Apache-2.0)](https://github.com/OTER-Labs/radix-tally-verify) ### Related pages - [Tāhuna](/ecosystem/tahuna) – prediction-market protocol resolving on OTER - [Religant](/ecosystem/religant) – the earlier oracle effort on Radix - [Oracle Integration](/developers/scrypto/08-oracle-integration) – consuming an oracle from a Scrypto blueprint - [Radix Governance](/contents/tech/core-concepts/radix-governance) – on-ledger governance across the network