Admin Basics
The admin areas operators use day to day
Phoenix Prediction admin is where operators shape the iframe experience, manage the listing catalog, and monitor market operations.
Most operator teams use it for two kinds of work:
- Commercial and content work: deciding what markets to show, how they are grouped, and how the player-facing experience appears.
- Operational work: pausing, closing, resolving, reviewing settlement status, and helping support teams investigate player questions.
Common Workflows
| Workflow | What you do |
|---|---|
| Review listing feed | Inspect published listings, visibility, and the markets inside them |
| Create listings and markets | Create player-facing listing pages and attach tradable binary markets |
| Close markets | Stop trading before resolution |
| Resolve markets | Declare outcomes and trigger settlement |
| Read comments | View the player comment feed on a listing |
| Review stats | Track volume, GGR, settled payout, players, markets, orders, and positions |
| Manage admins | Invite, update, and remove admin users |
Roles and Access
Admin access has two independent axes: a principal (where you can act) and a role (what you can do).
The principal scopes which operators you can touch:
| Principal | Scope |
|---|---|
| Platform admin | Any operator |
| Client admin | Operators owned by your client |
The role is orthogonal to the principal and sets the capability within that scope:
| Role | Capability |
|---|---|
| admin | Read and write |
| viewer | Read-only |
Use the narrowest principal and role that let a teammate do their job.
Embed Appearance Changes
The embed has no saved profile or stored layout. Appearance comes from the iframe URL params (mode, accent, radius, colorblind, sizing, density, and the yes/no outcome colors), derived by the palette engine. Per-user UI policy such as deposit or profile button visibility comes from the operator-signed launch JWT cfg claim. Fixed identity, branding, legal links, currencies, and allowed parent origins live on the operator row and are served by GET /embed/api/config.
Embed appearance changes affect what players see inside the embedded product, so treat changes carefully:
- Review in
sandboxbefore changingprod. - Confirm the iframe opens correctly from the operator site.
- Test a visitor view and a logged-in player view after changes.
- Keep compliance and support links current on the operator row.
Listing and Market Changes
Listings control discovery. Markets control trading. Operators should review both before publishing.
| Change | Check before saving |
|---|---|
| Discovery placement change | The listing still appears where players expect it |
| Visibility change | The listing should be public, unlisted, or private for the intended use |
| Market wording change | Claim labels and resolution rules still agree |
| Close time change | Trading still stops before the outcome is knowable |
| Limit or tick-size change | The market remains understandable and risk stays within policy |
Avoid making production catalog changes just to satisfy an internal reporting need. If players cannot find or understand the listing, the iframe experience degrades even when the admin data looks tidy.
Suggested Daily Checks
| Check | Why it matters |
|---|---|
| Open markets | Confirm the live catalog matches what players should see |
| Markets near close | Know which markets are approaching the end of trading |
| Markets awaiting resolution | Avoid delays between close and settlement |
| Settlement health | Catch delayed wallet movement before support tickets arrive |
| High-volume markets | Watch liquidity, exposure, and player demand |