NO MAGIC. JUST INFRASTRUCTURE.

You sign in by signing a one-time nonce message (no transaction, no cost). The nonce expires in 5 minutes and can be used once.

On launch, 404 pins your image and Metaplex-format metadata to IPFS, then builds a Pump.fun create_v2 transaction using the official @pump-fun/pump-sdk (program IDs come from the SDK — nothing is hard-coded). With a dev buy, the SDK's createV2AndBuyInstructions puts create and buy in the same atomic transaction.

The server simulates the exact transaction against mainnet and reports the wallet balance change. Your browser checks the transaction hash before signing; the mint keypair is generated in your browser and signs locally. On submission the server rejects any transaction whose message differs from the one simulated, then sends, rebroadcasts until the blockhash expires, confirms, and independently verifies the mint, the Pump bonding curve and its on-chain creator before creating your server.

A server is a managed website environment: its own immutable website versions, primary and secondary deployments, IPFS backups, health checks, incidents and failover log. It is not a dedicated physical machine or VPS.

Server IDs are allocated inside the provisioning database transaction from a row-locked counter, so they are sequential and unique (404-000001, 404-000002 …). Each token can have exactly one server; duplicate confirmation events are idempotent.

Content is plain text validated on the server and HTML-escaped into a static page with a Content-Security-Policy that forbids all scripts. Every publish creates a new immutable version with a SHA-256 checksum. Restoring an old version publishes a new version with the old content — history is never rewritten.

Each version is gzip-compressed and uploaded to IPFS through Pinata (Pinata gateways refuse to serve raw HTML, so snapshots are stored as an opaque archive). The returned CID is then fetched through the dedicated gateway and an independent public gateway and unpacked and hashed. Only a SHA-256 match with the published HTML marks a backup VERIFIED. Backups are re-verified every 6 hours; after 5 consecutive failures, or if the pin disappears, the backup is FAILED and the owner is notified.

The worker measures each live deployment about every 60 seconds (timeout 8s, one retry on network error). A check is healthy when it returns HTTP 2xx and the body's SHA-256 matches the deployed version.

PROVISIONING  server exists, no live primary deployment yet
ONLINE        routed to PRIMARY, primary healthy, latency ≤ 3000ms
DEGRADED      primary healthy but slow (> 3000ms)
              OR serving from SECONDARY / IPFS because primary failed
              OR primary failing but below the failover threshold
OFFLINE       no healthy route is serving the website
FAILED        provisioning failed: no primary deployment after 5 attempts

Uptime is the share of healthy primary checks among real measurements. Hours with no measurements are shown grey and never counted as up.

Visitors use /go/<SERVER_ID>. After 3 consecutive failed primary checks the route moves to the first healthy fallback: independent SECONDARY host → verified IPFS backup (served via /backup/<SERVER_ID>, which re-checks SHA-256 before serving) → archive. Returning to PRIMARY requires 3 consecutive healthy checks and at least 5 minutes on the fallback, preventing rapid switching. Every change is logged as a failover event. Thresholds are configurable.

Failover is not zero-downtime: detection takes roughly threshold × interval (≈3 minutes by default). If no secondary provider is configured, the server is labelled SECONDARY NOT CONFIGURED and is not described as protected by failover.

Simulated resolver test: runs the failover decision with the primary marked down using live probe results. Nothing changes for visitors.

Independent provider test: flips only this server's route to the secondary host for at most 5 minutes, requests /go to confirm the redirect, fetches the secondary and compares SHA-256, then restores the primary and confirms the resolver points back. Requires a healthy independent secondary.

Measures infrastructure resilience only — never token quality or investment potential.

Primary hosting health      25   healthy 25 · slow 15 · down 0
Secondary hosting readiness 20   healthy 20 · slow 12 · down/not configured 0
Verified IPFS backup        20   sha256 verified on retrieval
Backup freshness            10   verified ≤24h 10 · ≤72h 5
Recent monitoring           15   15 × healthy ratio (24h) × min(1, checks/60)
Recovery capability         10   passed independent blackout test (30d) 10
                                 untested fallback route exists 5
─────────────────────────────────
                           100   no secondary ⇒ max 75