This file gives an evidence-based startup and recovery sequence for Phoenix perpetuals. It describes pure checks and manual validation without packaging a particular application's monitor, service layout, or trading policy.
TL;DR
- Validate identity, metadata, signer health, and raw account ownership before interpreting reads or writes.
- Binding loss and capability restriction are different conditions.
- Unknown checks retain uncertainty; they do not prove recovery.
- Reconcile inherited signed intents before creating conflicting new work.
- Public smoke is unauthenticated and read-only; transaction validation is a separate authorized workflow.
1. Startup sequence
Validate canonical base58 authority/PDA/delegate and explicit deployment/indices. Read current market metadata for quantization. Query signer health and compare expected identity; authentication refusal is a configuration issue, not a reason to wait forever.
Read the raw trader header independently. Verify Solana owner program, discriminator, authority, and indices. A configuration mismatch cannot be repaired by trusting an indexer view. Delegation loss or uninitialized capability state produces a clear write block; frozen/reduce-only flags remain separately reported restrictions.
Inspect signer inflight/stale intent counts. The pure startup-hold helper exposes whether inherited unresolved work remains; retry intervals and waiting windows are caller settings. New work must not conflict with earlier signed intents that may still land.
Finally read consistent state/equity and spendable fee-payer SOL. Exchange status reports activity, gating, and withdrawal availability as information. An indexer status alone is weaker evidence than raw transaction acceptance and must not be silently treated as a universal policy for all operations.
2. Ongoing binding and health
Periodically compare signer identity and raw header. Unknown RPC/signer results cannot be described as confirmed loss or restoration. The binding gate preserves its last proven verdict, while returning current availability separately.
Track capability restrictions, fee-payer balance freshness, trusted account reads, and unresolved signatures independently. Alert thresholds and polling cadence belong to the caller; the toolkit does not import a monitor's tuned counters.
A user-facing application action can change delegation. The header is the source of truth. The precise action that changed it cannot be inferred solely from a mismatching position authority.
3. Restart and intent recovery
The experimental signer persists signed work before broadcast and restores it after restart. Resolve each signature, retaining stale unresolved work. A process timeout or reboot does not invalidate an existing transaction or reset the blockhash's lifetime.
Review exact echo and slot-gate state before deciding that a placement vanished or a cancel failed. Indexer catch-up requires new reads; an already running read may have started before the operation. See api-and-reads.md §3 and signing-and-sidecar.md §3.
4. Verification boundaries
Public smoke validates metadata, market prices, exchange status, and transaction-key shape. It uses no wallet/account lookup, signing key, simulation of a user account, or order submission.
Offline fixtures are regenerated from synthetic bytes and generated keys. Do not scrub a real transaction blob: account identities can remain in instruction bytes, logs, or return data.
When live transaction testing is within the user's authorized scope, use a dedicated account and small valid lots. Check posted identity, effective exact-ID cancellation, IoC return data, transaction slot, and a caught-up position read. A reduce-only test must separately check placement, subsequent position changes, and eventual matching rather than generalize one stage to all stages. Stop when outcome becomes unknown and resolve it before another conflicting action.
Exact dependency versions, lockfiles, and signer syntax/offline tests are prerequisites for evaluating the experimental package. A build passing does not prove current-chain packet acceptance.
5. Diagnostic evidence
Collect current market status/grid/band, raw header identity/capabilities, signer outcome/signature, RPC transaction metadata, return data, effective-cancel logs, and stable state/view slot evidence. Redact all personal identities from material intended for publication.
Classify no-send, preflight refusal, landed failure, successful no-fill/no-post, successful post/fill, and unknown separately. If a new protocol observation conflicts with an older statement, add its date and explicitly narrow or supersede the prior claim.
Pitfalls
| What breaks | Why | Correct approach |
|---|---|---|
| Application starts with foreign binding | Only signer was checked | Parse raw header independently |
| Restored delegate remains blocked | Recovery inferred from a failed read | Recheck confirmed binding |
| Restart repeats a signed order | Inflight journal ignored | Resolve preserved signature |
| Public artifact contains an encoded account | Live blob was scrubbed | Generate synthetic fixture bytes |
| Live test is called smoke | Test requires a funded account | Keep public smoke separate |
Open questions / not verified
- Live validation of packaged experimental signer and unsigned delegation builder.
- Delegate overwrite causes, isolated-account delegate operations, and idle snapshot-slot semantics.
- Current access/onboarding conditions;
gatedalone is not an invitation verdict.
Sources
Accounts; WS/API best practices; API overview; Phoenix terms of use; Rise public source. Identity checks and operational helpers describe toolkit safeguards. Eligibility and terms must be checked on the current official page; no workaround is provided.
© markpaper authors. Licensed under CC BY 4.0: when publishing or adapting this material, credit “markpaper — Phoenix knowledge base” and link to the original and the license.