Skip to main content

​
Production checklist

A PressChain integration is production-ready when it can explain its authority, survive infrastructure failure and recover without compromising user signing or protocol meaning. Use this checklist before treating a testnet prototype as launch-quality software.

​
Network and deployment

  • Verify the expected Chain ID at runtime.
  • Load addresses from an approved environment-specific deployment manifest.
  • Verify every ABI against the deployed contract version.
  • Keep testnet and future mainnet configuration physically separate.
  • Reject unknown networks for write actions.
  • Record deployment start blocks for indexers.

​
Identity and authorization

  • Use window.presschain for PressChain-native browser authorization.
  • Never ask the user to paste a private key or recovery phrase.
  • Respond to account, chain and lock changes.
  • Re-read role, bond and relationship state before signing.
  • Distinguish platform roles from protocol role IDs.
  • Keep outlet authority separate from generic protocol role.

​
Capsule publishing

  • Use canonical bytes32 Capsule identifiers.
  • Normalize content before hashing.
  • Build metadata with the active schema version.
  • Verify durable source and media URIs.
  • Hash canonical cover media where required.
  • Track the publication transaction to a receipt.
  • Read the resulting Capsule back from authoritative state.
  • Preserve revision history instead of overwriting it.

​
Evidence

  • Distinguish official, community and dispute paths.
  • Verify evidence artifact hashes.
  • Treat external content as untrusted input.
  • Display submitter and relationship provenance.
  • Handle inactive and finalized state explicitly.
  • Prevent predictable duplicate vote attempts in the UI.

​
Economics

  • Resolve fee class from current action policy.
  • Resolve amount from the active network economics configuration.
  • Keep bond, protocol fee, funded value and gas visually separate.
  • Store token quantities as integer base units.
  • Respect treasury floors and budget controls.
  • Revalidate settlement eligibility.

​
RPC and transactions

  • Set timeouts for RPC reads.
  • Retry only safe operations with bounded backoff.
  • Persist transaction hashes immediately after submission.
  • Reconcile ambiguous timeouts before resubmitting.
  • Decode domain reverts where possible.
  • Monitor RPC error rate and latency.

​
Indexing

  • Store block number and block hash with the cursor.
  • Store transaction hash and log index with events.
  • Make event application idempotent.
  • Implement reorganization rollback.
  • Reconcile important mutable state with contract reads.
  • Monitor head lag, failed events and reconciliation mismatches.
  • Keep enrichment fields separate from canonical fields.

​
API

  • Do not assume planned routes exist.
  • Honor API version and response contracts.
  • Enforce authentication and scope for future protected surfaces.
  • Keep current read-only boundaries read-only.
  • Return structured errors that distinguish unavailable state from empty state.

​
External content

  • Enforce fetch timeouts and size limits.
  • Prevent access to internal network ranges from server-side fetchers.
  • Use MIME allowlists for previews.
  • Isolate PDF and document rendering.
  • Cache verified artifacts by content hash when possible.

​
Observability

Monitor at minimum:
  • RPC availability and latency
  • chain head height
  • indexer head and lag
  • API health
  • transaction failure rate by action
  • bounty engine evaluation and settlement failures
  • PressKey authorization errors in the client
  • external artifact verification failures
Do not log sensitive signing material.

​
Recovery drills

Before launch, rehearse:
  1. RPC outage
  2. indexer rebuild
  3. API state unavailable
  4. signer lock during a prepared action
  5. ambiguous transaction submission timeout
  6. duplicate event replay
  7. failed evidence artifact fetch
  8. economic action blocked by treasury policy
  9. contract or application pause procedure
The mainnet readiness policy already requires a complete testnet launch rehearsal. Use the rehearsal to prove recovery behavior, not just the happy path.

​
Final launch question

For every important screen, ask: if our application database disappeared tonight, could we reconstruct the canonical protocol state from authoritative sources and explain where our application-only data came from? If the answer is no, the boundary between protocol state and product state still needs work.