docs: rewrite propose/dispute UI pages for the Explorer dapp - #31
droplet-rl wants to merge 2 commits into
Conversation
Phase 1 of the oracle.uma.xyz -> explorer.uma.xyz deprecation. - Rewrite "Proposing via the Oracle Dapp" as "Proposing via the Explorer Dapp": Explorer lifecycle tabs and filters, the propose acknowledgement + wallet + bond-approval flow, outcome presets vs raw int256, and the MOOv2 proposer-whitelist button states. - Rewrite "Disputing Oracle Data" as "Disputing via the Explorer Dapp". The old page was stale beyond the dapp swap: it pointed at oracle.umaproject.org, testnet.oracle.umaproject.org, Görli and a Görli mock oracle. Replaced with the Explorer dispute flow, the challenge window difference between OOv2 and MOOv2, and the post-dispute Under dispute / Final answer states. - Both pages state that the Explorer only serves Polymarket, Predict.fun and Outcome, and that other OO requests are UI-unsupported after the Oracle dapp is retired. - Rename both files to explorer slugs, add .gitbook.yaml redirects from the old slugs, and repoint the inbound oSnap link. - Drop the three old Oracle dapp screenshots; they no longer match the UI. Content verified against UMAprotocol/mcp-otb oracle/ui at the commit currently deployed to explorer.uma.xyz (28e1bd89). Co-Authored-By: Claude <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a7443e9876
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 3. The **Dispute this proposal** dialog confirms that disputing escalates the request to UMA's dispute resolution and requires posting a bond. Review the proposed outcome and the **Bond required**. If your balance is short, the dialog shows _"Insufficient balance to cover the bond."_ and blocks submission. | ||
| 4. Submit and confirm in your wallet. Where your existing token allowance does not already cover the bond, your wallet will request an unlimited token approval for the oracle contract first — only the required bond is transferred, and the approval applies only to that oracle. The button narrates progress as **Preparing…**, **Switching network…**, **Approving unlimited allowance…**, then **Submitting dispute…**. | ||
|
|
||
| If the dispute window has already closed, the button is replaced by a disabled **Dispute window closed** state — the proposal is past its challenge window or under extended review and can no longer be disputed. |
There was a problem hiding this comment.
For a flagged MOOv2 proposal, “under extended review” means the challenge period has been extended specifically so participants can still dispute it, as documented in protocol-overview/how-does-uma-resolve-prediction-markets.md:24; the MOOv2 explanation immediately below also says proposals remain disputable until settlement. Saying that extended review closes the window may cause users to abandon a still-actionable invalid proposal, so distinguish extended review from an actually closed dispute state.
Useful? React with 👍 / 👎.
| Disputing through a UI is done on the **Explorer dapp** at [explorer.uma.xyz](https://explorer.uma.xyz). The Explorer replaces the legacy Oracle dapp (`oracle.uma.xyz`), which is being deprecated. | ||
|
|
||
| {% hint style="warning" %} | ||
| **The Explorer only serves Polymarket, Predict.fun and Outcome requests.** Optimistic Oracle requests from any other integration are not shown in the Explorer and will be unsupported through a UI once the Oracle dapp is deprecated. Disputers on other requests will need to dispute programmatically by calling `disputePrice` on the oracle contract directly. |
There was a problem hiding this comment.
For an unsupported integration using Optimistic Oracle V3, calling disputePrice cannot dispute its assertion: OOV3 exposes disputeAssertion(bytes32,address), as documented in developers/optimistic-oracle-v3/data-asserter.md:137. Because this warning covers requests from any other integration, users can follow an invalid transaction procedure during a time-limited challenge window; the fallback instructions need to branch by oracle version rather than universally prescribing disputePrice.
Useful? React with 👍 / 👎.
|
|
||
| #### Proposer whitelist on Managed Optimistic Oracle V2 | ||
|
|
||
| MOOv2 requests enforce a proposer whitelist. Risk Labs manages the default whitelist — see [Default Proposer Whitelist](default-proposer-whitelist.md) for the criteria and update cadence. |
There was a problem hiding this comment.
For a MOOv2 request whose manager sets isEnforced to false, any address may propose, so the categorical claim that all MOOv2 requests enforce a whitelist is incorrect. using-uma/proposing-programmatically.md:13-15 documents both the per-request enforcement flag and the request-manager override; describe the default and effective request setting instead, otherwise eligible users may incorrectly conclude that they cannot propose.
Useful? React with 👍 / 👎.
| ## Disputing Proposals  | ||
|
|
||
| If the oSnap request does not meet the Rules, it should be disputed. Disputed requests can not be executed no matter how UMA resolves the dispute. This [section](../../using-uma/disputing-oracle-data.md) outlines the steps to dispute an invalid oSnap request, or any other invalid assertions to UMA's Optimistic Oracle. | ||
| If the oSnap request does not meet the Rules, it should be disputed. Disputed requests can not be executed no matter how UMA resolves the dispute. This [section](../../using-uma/disputing-via-the-explorer-dapp.md) outlines the steps to dispute an invalid oSnap request, or any other invalid assertions to UMA's Optimistic Oracle. |
There was a problem hiding this comment.
For a reader trying to challenge an oSnap request, this link does not provide the promised procedure: its destination explicitly says the Explorer only supports Polymarket, Predict.fun, and Outcome, and its UI steps cover only MOOv2/OOv2 requests. Replace this with oSnap-specific programmatic or legacy-UI instructions rather than sending users to an unsupported flow while claiming it outlines the steps.
Useful? React with 👍 / 👎.
|
I've used my 1 automated round on this PR, so I'm ignoring further automated-reviewer activity. To re-activate me: have a human @-mention |
- Dispute fallback now branches by oracle version. The blanket
"call disputePrice" was wrong for assertion-based integrations:
OOv3 exposes disputeAssertion(bytes32,address). oSnap is on OOv3.
- Stop presenting "under extended review" as a closed dispute window.
Flagged MOOv2 proposals get an *extended* challenge period precisely
so participants have more time to dispute, and stay disputable until
settled — the previous wording could have led a reader to abandon a
still-actionable invalid proposal.
- Describe the MOOv2 proposer whitelist as per-request rather than
categorical. Requests default to defaultProposerWhitelist unless the
requestManager overrides, and the whitelist carries an isEnforced
flag; when false, any address may propose.
- Repoint the oSnap dispute section at the OOv3 disputeAssertion flow
instead of the Explorer-only guide, and state plainly that oSnap is
not served by the Explorer.
- Also document the third no-action button state ("Proposing/Disputing
unavailable"), which both pages had omitted.
Co-Authored-By: Claude <noreply@anthropic.com>
|
All four Codex findings were valid. Fixed in P1 — P1 — extended review ≠ closed window. Also correct, and it contradicted my own page. P2 — whitelist enforcement is per-request. Correct. P2 — oSnap link. Agreed, and this is the item I flagged for a reviewer myself. Now resolvable rather than deferrable, because finding #2 supplies the right destination: oSnap is the Optimistic Governor, migrated to OOv3 ( One thing I found independently while checking the quoted strings: both pages described only two of the three no-action states. The UI also renders a disabled Proposing unavailable / Disputing unavailable button when a request is neither read-only nor link-outable ( Two items I deliberately did not fix, both needing a human decision:
I also re-verified the unchanged claims rather than assuming: both Polygon addresses respond to Note on process: the automated round fired on Codex's "Running" placeholder, ~5 minutes before the findings actually landed, so I polled until the review posted rather than replying to an empty comment. Per the one-round limit I won't re-summon it. If the two open items above need iteration, assign me to the PR and I'll pick them up. |
1 participant
Phase 1 of deprecating the Oracle dapp (
oracle.uma.xyz) in favour of the Explorer dapp (explorer.uma.xyz). Requested by @lee in Slack.What changed
using-uma/proposing-via-the-oracle-dapp.md— "Proposing via the Oracle Dapp"using-uma/proposing-via-the-explorer-dapp.md— "Proposing via the Explorer Dapp"using-uma/disputing-oracle-data.md— "Disputing Oracle Data"using-uma/disputing-via-the-explorer-dapp.md— "Disputing via the Explorer Dapp"Both pages now lead with the scope limit: the Explorer only serves Polymarket, Predict.fun and Outcome, and OO requests from other integrations are UI-unsupported once the Oracle dapp is retired.
Proposing — rewritten end to end. The old page was three screenshots of the Oracle dapp sidebar describing only the MOOv2 deltas. It now covers the Explorer lifecycle tabs and filters, the acknowledgement checkbox → connect wallet →
Propose a pricedialog flow, outcome presets vs rawint256, the bond/approval semantics, and the four MOOv2 proposer-whitelist button states.Disputing — rewritten end to end. This page was stale well beyond the dapp swap: it pointed at
oracle.umaproject.org,testnet.oracle.umaproject.org, Görli and a Görli mock oracle, and referenced a "Proposals" tab that no longer exists. It now covers finding proposals under the Proposed tab, the dispute acknowledgement + bond flow, and the post-dispute Under dispute → Final answer states.It also documents a difference worth knowing: OOv2 disputes revert once the challenge period lapses, whereas MOOv2 proposals stay disputable until they are actually settled.
Housekeeping
.gitbook.yamlredirects added from both old slugs, so existing links keep working.resources/osnap/osnap-proposal-verification.mdrepointed to the new path.image (38|40|41).png) are no longer referenced — they were only used by the proposing page and no longer match the UI. The asset files are left in place.Verification
Copy was taken from
UMAprotocol/mcp-otboracle/uiat28e1bd89— the commit currently live onexplorer.uma.xyz(Vercel projectotb-oracle) — and every quoted UI string was confirmed present in the deployed JS bundles rather than only inmaster.Two things for the reviewer
oracle/uihas a "Propose on-chain" / "Propose privately" method selector for Managed Oracle requests, gated onVITE_SIGNED_PROPOSAL_ENABLED/VITE_SIGNED_PROPOSAL_SUBMISSION_ENABLED(both defaultfalse). I could not read the production env, so I left it out rather than document a path that may not be visible. Happy to add a section if it is live.Remaining Oracle dapp references elsewhere in the docs (
faqs.md,resources/network-addresses,default-proposer-whitelist.md, oSnap,developers/optimistic-oracle/getting-started.md) are itemised in the Slack thread and deliberately left for a follow-up PR.🤖 Generated with Claude Code