We've reached a real milestone. After months of building quietly, POXY WORLD is moving into its testing phase. The foundation is done: the platform, the security layer, the economy, and the visual identity all sit on solid ground, and now it's time to make sure everything holds up before we open the doors.

Testing is where a product stops being an idea and starts being a thing you can trust. We're checking how boxes open, how the figure generation feels, how the collection and passport screens behave on real devices, and how the account and security flows hold up. Nothing ships until it feels calm, fast, and right.

Why share this now? Because the people who pay attention early are the ones who shape what POXY becomes. We'd rather bring you in while it's still forming than present a finished box and hope you like it. If you're reading this, you're early, and that matters here.

The next big step is opening POXY to the public. When testing is done and the first season is ready, we'll announce the launch and the moment the world becomes something you can actually step into. Keep an eye on this page.

V2.4 Specification

Protocol Roadmap

The strategic deployment timeline for POXY WORLD infrastructure, detailing mainnet integrations and ecosystem expansion phases.

lightbulb I. The Asset Philosophy

Every POXY is an immutable cryptographic entity. From the precise nanosecond of its generation, each asset carries a permanent, unalterable chain of custody — a digital fingerprint that follows the asset through every transaction, trade, and transfer in perpetuity.

Ownership is not a permission granted by a platform. It is a verifiable mathematical fact recorded on an immutable ledger. Your POXY belongs to you in the most absolute digital sense possible.

lock II. Cryptographic Ownership Model

At the core of every POXY asset is an ED25519 keypair generated server-side at mint time. The public key is permanently embedded in the asset record and used to verify all downstream events. No key is ever reused.

# Asset identity generation (pseudocode)
private_key, public_key = ed25519.generate_keypair()
poxy_hash = sha256(f"{serial_id}:{public_key.hex()}:{timestamp_ns}")
genesis_payload = {"poxy_hash": poxy_hash, "pub_key": public_key, "tier": tier}
signature = ed25519.sign(private_key, canonical_json(genesis_payload))
# private_key is destroyed — never stored

The private key signs the genesis event payload, then is permanently destroyed. The public key and signature are recorded in the immutable ledger, and all subsequent ownership proofs reference this chain.

verified III. Immutable Heritage

Rarity tiers — Common through Mythic — represent genuine scarcity coefficients baked permanently into the generation algorithm. Once set, these values are immutable at the protocol level and cannot be altered by any administrative action.

Scarcity Enforcement

Tier probabilities are hardcoded into the RNG module. An audit trail of every roll is publicly queryable.

Chain of Custody

Every transfer, trade, and burn is a signed ledger event, cryptographically linked to the genesis record.

deployed_code Phase 1: Genesis Deployment

The initial phase establishes the core operational framework — deployment of server-side seed generation infrastructure, the ED25519 signing pipeline, and the baseline POXY tokenomics architecture.

Launch of POXY Identity Substrate (PIS) with ED25519 keypair generation.
Commit-reveal RNG validation loop deployed to production edge functions.
Append-only ledger initialized — no records deletable or mutable after write.
Release of the beta Terminal UI for early adopters.

terminal Core Logic: Cryptographic Engine

The POXY cryptographic engine uses a commit-reveal RNG pattern to guarantee provably fair outcomes. The server commits to an entropy seed before any user action, then reveals and combines it with a client-supplied nonce to produce the final result.

# Server-side seed generation (Edge Function)
def generate_commit(round_id: str) -> dict:
    server_seed = secrets.token_hex(32)          # 256-bit CSPRNG
    commit_hash = sha256(server_seed.encode()).hexdigest()
    # Store commit_hash publicly; server_seed locked until reveal
    ledger.insert({"round_id": round_id, "commit_hash": commit_hash})
    return {"commit_hash": commit_hash}

def reveal_and_resolve(round_id, client_nonce):
    row = ledger.get_commit(round_id)
    combined = row["server_seed"] + ":" + client_nonce
    result_hash = sha256(combined.encode()).hexdigest()
    tier = map_hash_to_tier(result_hash)            # deterministic tier assignment
    sig = ed25519.sign(SERVER_PRIVATE_KEY, canonical_json({"round_id": round_id, "result": tier}))
    ledger.append({"round_id": round_id, "result": tier, "sig": sig})
    return {"tier": tier, "sig": sig, "server_seed": row["server_seed"]}

After the reveal, anyone can independently verify the result by computing sha256(server_seed + ":" + client_nonce) and confirming it matches the stored result hash. The ED25519 signature confirms the server did not alter the seed post-commit.

storage Append-Only State Architecture

All POXY state transitions are stored in a strictly append-only ledger. No record is ever deleted or modified — ownership changes are represented as new events with cryptographic back-references to prior events, forming an unbroken chain from genesis.

-- Ledger schema (simplified)
CREATE TABLE poxy_events (
  id          UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
  poxy_hash   TEXT        NOT NULL REFERENCES poxy_assets(poxy_hash),
  event_type  TEXT        NOT NULL,  -- genesis | transfer | burn | verify
  payload     JSONB       NOT NULL,
  signature   TEXT        NOT NULL,  -- ED25519 over payload
  prev_hash   TEXT,                   -- NULL for genesis, else sha256(prev event)
  seq         BIGINT      GENERATED ALWAYS AS IDENTITY,
  created_at  TIMESTAMPTZ DEFAULT now()
);
-- Row-Level Security prevents any deletion or update
ALTER TABLE poxy_events ENABLE ROW LEVEL SECURITY;
CREATE POLICY insert_only ON poxy_events FOR INSERT TO service_role WITH CHECK (true);

hub Phase 2: Syndicate Expansion

Following a successful Genesis, the protocol scales to support complex user hierarchies known as Syndicates — introducing governance mechanisms and shared resource pooling capabilities.

Governance Modules

On-chain voting for protocol parameter adjustments via the DAO structure. Proposals must pass a 67% supermajority to take effect.

Resource Pooling

Syndicates can aggregate yield-generating assets into unified vaults for amplified collective returns and shared verification rights.

layers Phase 3: Syndicate Tiers

Syndicate tiers are determined by the cryptographic weight of the aggregated identities. Higher tiers unlock advanced protocol features, governance voting weight, and exclusive access to premium syndicate vaults.

Tier 1 (Initiate): Base access to governance proposals and standard yield pools.
Tier 2 (Operative): Enhanced voting power multiplier (1.5x) and access to priority transaction relays.
Tier 3 (Architect): Maximum protocol influence (3x voting weight), custom syndicate vault deployment, and zero-fee identity minting.

SYS_LOG: Cryptographic verification required for tier ascension. Node consensus mandatory.

layers Tier Architecture

POXY Syndicates operate on a five-tier hierarchy. Each tier unlocks progressively deeper protocol access, governance weight, and revenue participation rights.

Tier I — Recruit

Base access. Can participate in public drops and standard market operations.

Tier II — Operative

Unlocked by holding 5+ unique assets. Priority queue access for limited drops.

Tier III — Sentinel

Minimum 1 Rare or above. Governance voting rights activated.

Tier IV — Warlord

Minimum 1 Mythic asset. Revenue-sharing participation and vault creation rights.

group Collective Operations

Syndicates may pool verified assets into collective vaults. Vault operations are governed by multi-signature authorization, requiring consensus from a configurable threshold of vault keyholders.

gavel Usage Rights & Jurisdiction

POXY assets are digital collectibles with fully assigned ownership rights. The holder of a verified POXY asset is entitled to: (1) display rights across any personal or commercial medium, (2) transfer or resale of the asset on authorized secondary markets, and (3) protocol governance participation at the applicable tier level.

POXY World Ltd. operates under jurisdiction of England and Wales. All disputes are subject to binding arbitration under LCIA rules.

policy On-Chain Governance

Protocol parameter changes require a governance proposal submitted on-chain. Eligible voters are Sentinel-tier and above. A 67% supermajority is required for ratification. Emergency security patches may be deployed by the core team within a 24-hour notice window, subject to retroactive ratification within 7 days.

User data is processed in accordance with UK GDPR. No on-chain identity data is linked to personally identifiable information without explicit consent.

Cookie Policy

Functional cookies only. No third-party tracking cookies are deployed on any POXY World domain.

Threat	Countermeasure	Status
Duplicate minting	UNIQUE constraint on poxy_hash. Even if two mint calls run concurrently, identical hashes are rejected at the DB layer.	✓ Enforced
Replay attacks	Every signed request carries a unique nonce + ISO timestamp. The nonce is consumed atomically; reuse or stale timestamps are rejected.	✓ Enforced
Signature forgery	ED25519 signature security is 128-bit. The private key exists only in Edge Function secrets — not in the database, not in source code.	✓ Enforced
Event rewriting	INSERT-only triggers reject UPDATE/DELETE on ledger_events. Hash chain verification detects any storage-level tampering.	✓ Enforced
Database tampering	Hash chain and signatures are verifiable from the public key alone. A DB admin inserting a fraudulent event cannot forge a valid ED25519 signature.	✓ Cryptographic
RNG manipulation	Commit-reveal: server commits before seeing client input. Server cannot change seed; client cannot predict it. Result is deterministic from both inputs.	✓ Provably fair
Admin abuse	Dual-control key approval required for key changes. All admin actions are logged in security_audit_log with hash-chained entries.	⚠ Logged + audited
Client spoofing	All state transitions require a valid user JWT. Ownership verification is enforced by the Edge Function before any DB write.	✓ Enforced
Race conditions	pg_advisory_xact_lock serializes all ledger writes. Prevents concurrent hash chain forks at the transaction level.	✓ Serialized
Server compromise	A compromised server could sign fraudulent assets. However, unauthorized events are detectable in the public ledger. Key rotation immediately invalidates the compromised key.	⚠ Detectable

Reasons to start.

Secure

Invest

Open

Social

Powerful

Unique

Fundamental

Developing

Belonging

Three steps. No spinning wheels.

Open a box

Watch it form

Keep it on your shelf

Trusted, not hyped.

A closed economy, for now

Fair by design

Your account, secured

Real ownership

Your shelf is waiting.

POXY FAQ

General

Collecting and Opening

Economy and Coins

Account and Security

Safety and Trust

News

POXY WORLD is getting ready for testing

Coming soon: POXY WORLD opens to the public

POXY WORLD is getting ready for testing

Coming soon: POXY WORLD opens to the public

Policy

Your account and data

Security

The closed economy

Cookies and tracking

Changes to this policy

About POXY WORLD

What POXY WORLD is

Our design philosophy

How the economy works today

Where we're going

Who we are

Getting started