POOLZPAD Development proof
← Fee transparency

POOLZ PAD V1 · engineering reveal

Built in layers.
Tested at the boundaries.

A clear view of how the proposed V1 contracts separate trading, fee accounting, treasury operations, rewards and public evidence—before any production deployment.

Explore the system ↓Development build · unaudited

No production addresses · no wallet connection · no transaction capability

Solidity tests75 / 75passing in the current build
Engine tests79 / 79passing in the current build
Production deployments0release remains gated
Private keys in apps0signing stays outside the system

System flow

One trade.
Four clear stages.

The design keeps the user's swap path small, moves later operations into bounded components and makes the final result independently traceable.

01Trade

Pool execution

A POOLZ trade is executed through the approved pool route. The pool handles the liquidity-provider fee separately.

02Account

Fee hook

The hook calculates the fixed protocol fee and records exact liabilities without running buybacks or rewards inside the trade.

03Route

Bounded vaults

Each approved share moves only to its fixed destination for buyback, ecosystem operations or trader incentives.

04Prove

Finalized evidence

The indexer waits for finality, reconciles outcomes and prepares a readable public record from the same source history.

Total swap fee1.25%
Liquidity providers0.25%
Protocol fee1.00%40% buyback · 40% ecosystem/team · 20% trader/growth

Nine focused modules

Small surfaces.
Specific jobs.

Each module has a narrow responsibility. The V1 design avoids concentrating trading, treasury execution, scoring and claims inside one all-powerful contract.

01V1 module

POOLZ token

Fixed 55M supply

No external mint, transfer tax, blacklist, pause or upgrade path.

02V1 module

Fee hook

Exact protocol accounting

Collects and records the protocol component across the supported swap paths.

03V1 module

Ecosystem splitter

Fixed recipients

Separates the approved ecosystem accounting paths without caller-selected recipients.

04V1 module

Buyback vault

Bounded execution

Requires a minimum POOLZ output and burns only the tokens received by that operation.

05V1 module

Reward vault

Separate conversion path

Keeps reward conversion and distributor funding isolated from buyback assets.

06V1 module

Reward distributor

Immutable campaign terms

Requires complete funding before activation and prevents duplicate claims.

07V1 module

Trade attribution

Authenticated activity

Rejects outsiders, wrong pools, duplicate executions and incomplete trade records.

08V1 module

Airdrop distributor

Snapshot-bound allocation

Binds distribution to reviewed snapshot evidence, a fixed root and a fixed deadline.

09V1 module

Vault controls

Narrow permissions

Uses fixed executors, two-step controller handover and no arbitrary-call surface.

Automated test evidence

Proof of progress.
Not a shortcut to audit.

These checks demonstrate repeatable development behaviour across contract and data-engine boundaries. They reduce uncertainty, but they do not replace testnet evidence or independent security review.

Smart-contract suite75 passing
Deterministic engine suite79 passing
01

Fee math

Exact 1% protocol accounting, rounding and mixed swap sequences are exercised.

All four swap modes
02

Destination safety

A trigger can release accrued value but cannot replace the approved recipient.

Fixed routes
03

Buyback bounds

Expired, failed, zero-output and below-minimum operations revert without partial movement.

Atomic result
04

Reward integrity

Campaigns cannot activate early or before the complete declared allocation is funded.

Fund before activation
05

Canonical data

Provisional forks can be repaired and cannot settle scores or public outcomes.

Finalized blocks only
06

Recovery evidence

Wrong-chain, malformed, conflicting and secret-bearing inputs are rejected.

Fail closed

What this shows

Implemented and repeatable.

  • Core contracts compile and pass their current automated tests.
  • Fee accounting and operational execution are separated.
  • Invalid states fail visibly instead of being silently balanced.
  • The public layer can explain the same evidence in plain language.

What remains gated

Testnet, audit and approval.

  1. 01Approve the final production configuration, fixed recipients and operating limits.
  2. 02Complete the Robinhood testnet rehearsal and reconcile each fee destination end to end.
  3. 03Complete independent security review and resolve every material finding.
  4. 04Publish verified contracts and activate production only after written authorization.
Next reveal · testnet evidence

Architecture first.
Live rehearsal next.

The next release will connect the approved testnet configuration to visible fee collection, splitting, vault accounting and transaction evidence.

View testnet preflight →