- LaunchProof is an educational reference implementation designed to make token-sale mechanics and trust boundaries inspectable. It is not audited or presented as production-ready software for real funds.
- The public client reads and writes directly to Ethereum Sepolia. There is no application database or trusted backend ledger.
- The canonical V2 deployment replaced and cancelled V1 after unrestricted demo-asset controls were identified; the deprecated history remains public rather than being hidden or reused.
Token-sale infrastructure
LaunchProof
A verified Ethereum token-sale reference on Sepolia with escrowed payments, oracle pricing, exact-asset refunds, vesting, and Foundry invariant testing.
RoleSmart Contract & Full-Stack Web3 Engineer
TimelineJuly 2026
Team1
FocusToken-sale infrastructure
Escrowed paymentsVerified contractsLive chain state
Public evidence
Proof at a glance
- Network
- Ethereum Sepolia
- Testing
- 31 Foundry tests + fuzz and invariants
- Contracts
- Verified on Etherscan
- Proof
- Public deployment and live transaction flow
Educational reference implementation on Sepolia. The contracts are not audited, and the project is not production-ready for real funds.
Overview
Verifiable token-sale infrastructure with escrowed payments, phase-aware pricing, refund protection, vesting, and a fully documented Sepolia release.
A verified Ethereum token-sale reference on Sepolia with escrowed payments, oracle pricing, exact-asset refunds, vesting, and Foundry invariant testing.
Problem, context, and constraints
Naive token sales can forward funds immediately, assume stablecoin parity, mix decimal systems, misprice purchases that cross phase boundaries, or expose emergency withdrawals that undermine refunds.
A credible public reference needs more than a contract: its frontend configuration, deployment transactions, verification state, secret handling, testnet assets, and end-to-end transaction flow must remain aligned and independently inspectable.
- Economic terms and payment-feed configuration must become immutable when the sale starts.
- Native ETH and ERC-20 assets with different decimals need one consistent USD accounting model without hiding oracle assumptions.
- Failed or cancelled sales must preserve exact original-asset refunds, and recovery functions must not invade recorded liabilities.
- The Sepolia experience must be usable without presenting demo dUSDC or dUSDT as official Circle or Tether assets.
My role and contribution
Smart Contract & Full-Stack Web3 Engineer
- Designed and implemented the non-upgradeable LaunchProofSale lifecycle, including ordered phases, escrow, soft-cap finalization, cancellation, exact-asset refunds, and cumulative vesting claims.
- Integrated native ETH and generic-decimal ERC-20 payments through validated Chainlink-compatible price feeds and 18-decimal USD accounting.
- Applied OpenZeppelin SafeERC20, ReentrancyGuard, Pausable, and delayed default-admin access control with narrowly scoped operational roles.
- Built liability-aware treasury withdrawal and asset-recovery paths that protect payment escrow and outstanding LPF entitlements.
- Created capped six-decimal demo stablecoins and a rate-limited Sepolia faucet, then removed the deployer's minter role during deployment finalization.
- Built the responsive Next.js client with wagmi, viem, RainbowKit, live protocol reads, wallet writes, on-chain previews, slippage protection, and role-gated controls.
- Added deterministic deployment, artifact rendering, Etherscan verification, validation, and canonical live end-to-end purchase workflows.
- Documented architecture, math, security assumptions, deployment, deprecation history, and reproducible validation commands.
Architecture and system details
A wallet-connected Next.js client uses wagmi and viem for direct Sepolia reads and signed writes. LaunchProofSale owns lifecycle state, escrow accounting, phase consumption, entitlements, refunds, vesting, and authorization. OracleLib validates and normalizes Chainlink-compatible feeds, while VestingMath isolates cumulative release arithmetic. Payment assets remain in contract escrow until successful treasury withdrawal or an exact-asset refund; CI and deterministic deployment scripts keep the contract, public addresses, verification state, and frontend configuration reviewable.
01Wallet client
- Next.js App Router and TypeScript
- wagmi, viem, and RainbowKit
- Live reads and signed writes
- Purchase preview and slippage floor
02Sale protocol
- Non-upgradeable LaunchProofSale
- Bounded phase-aware pricing
- Escrow, soft-cap finalization, and refunds
- TGE, cliff, and linear vesting
03Pricing and assets
- Chainlink Sepolia ETH/USD feed
- Validated generic-decimal ERC-20 inputs
- Capped dUSDC and dUSDT demo assets
- Immutable fixed-price demo feeds
04Delivery and proof
- Foundry unit, fuzz, and invariant tests
- Vitest frontend tests
- Contract and frontend GitHub Actions
- Sepolia-only deployment guard
Verified on-chain deployment
The public application is connected to the canonical V2 deployment. Each address below is recorded in the repository deployment artifact and linked to its Sepolia Etherscan page.
Public testnet deploymentEthereum Sepolia
Chain ID 11155111Canonical V2 deployment from 21 July 2026. All listed contracts were independently confirmed through Etherscan API V2; the earlier V1 sale address was cancelled and is intentionally not reused.
LaunchProofSaleVerified
0x1435ab…1354e4LPF sale tokenVerified · fixed supply
0xdca78b…66147aDemo dUSDCVerified · Sepolia demo asset
0x215b4f…3a82b4Demo dUSDTVerified · Sepolia demo asset
0xbd9743…b78485Demo token faucetVerified · sole demo-token minter
0x27e152…574d89Deployer / administrator / treasuryTestnet account
0x63d35A…5ED9D9Key technical decisions
- Context
- Immediately forwarding contributions makes exact refunds impossible if a sale fails or is cancelled.
- Choice
- Keep each payment asset in contract escrow, record liabilities per asset, and release proceeds only after successful finalization.
- Tradeoff
- The contract holds assets for the sale lifecycle, increasing accounting responsibility while preserving exact-asset exit rights.
- Context
- A single purchase can consume the end of one allocation phase and continue into the next price tier.
- Choice
- Bound phase loops to ten entries and price each consumed segment at its own phase rate using the same path for preview and execution.
- Tradeoff
- Quotation logic is more involved, but avoids pricing an entire boundary-crossing purchase at the cheapest phase.
- Context
- Administrative ability to rewrite sale terms after participation begins weakens the protocol's stated guarantees.
- Choice
- Fix phases, allocation, soft cap, timestamps, treasury, and vesting at construction and permanently close payment configuration at sale start.
- Tradeoff
- Mistakes require a new deployment, but participants can inspect stable economic rules.
- Context
- A realistic Sepolia flow needs usable payment tokens without pretending they are official stablecoins or allowing unrestricted minting.
- Choice
- Deploy capped dUSDC and dUSDT assets, make the rate-limited faucet their sole minter, renounce the deployer's minter role, and label them throughout the UI.
- Tradeoff
- Per-wallet cooldowns are only an anti-abuse convenience and do not provide identity or Sybil resistance.
Security, scaling, and reliability
- SafeERC20 and measured input-balance deltas reject transfer-tax behavior and handle ERC-20 transfers defensibly.
- ReentrancyGuard and checks-effects-interactions protect purchases, refunds, claims, withdrawals, and recovery paths.
- AccessControlDefaultAdminRules adds delayed default-admin transfer; sale, pause, blocklist, and treasury responsibilities use separate roles.
- Pausing and blocklisting affect only new purchases, so they cannot trap refunds or vested claims.
- Oracle validation rejects non-positive, stale, and incomplete rounds; feed and token decimals are normalized rather than assumed.
- Supported payment assets cannot use generic recovery, and LPF recovery is limited to balance above outstanding entitlements.
- The Sepolia deployment script rejects every other chain ID, verifies full funding and role finalization, and has no mainnet deployment path.
- Private keys, mnemonics, API keys, keystores, Foundry broadcast artifacts, caches, and root environment files remain excluded from version control.
- LaunchProof has not been audited or formally verified and is not presented as production-ready for real funds.
Testing strategy
- Thirty-one Foundry tests cover configuration, funding, phase boundaries, four decimal models, oracle failures, escrow, exact refunds, vesting, roles, recovery, transfer-tax rejection, and native reentrancy.
- Three fuzz properties run 512 cases each across decimal handling, preview/execution consistency, and vesting bounds.
- Five stateful invariants run 128 sequences of 64 calls to check allocation, entitlement, escrow, and liability properties.
- Eight Vitest tests cover frontend configuration, protocol rendering, and pure client logic.
- Separate GitHub Actions workflows run contract formatting, compilation, tests, coverage plus frontend linting, type checks, tests, and production builds.
Result and proof
- The complete application is live on Sepolia with a Vercel frontend configured against the canonical V2 addresses.
- Seven repository contracts and the external ETH/USD feed were confirmed through Etherscan API V2 and recorded in the public deployment artifact.
- A canonical live flow claimed 1,000 dUSDC, approved exactly 1 dUSDC, and purchased 20 LPF; its three transaction hashes and post-transaction assertions are public.
- The sale was fully funded with 30,000,000 LPF, and deployment validation confirmed the deployer retained neither LPF surplus nor demo-stablecoin minter permission.
- V1 was cancelled after its unrestricted demo controls were identified; zero sales and escrow were confirmed before deprecation, and the production client was moved to a hardened V2 deployment.
- The repository publishes reproducible contract, frontend, deployment, verification, and end-to-end validation workflows without claiming an audit or mainnet release.
Before
Token-sale examples that hide trust assumptions, flatten phase pricing, forward contributions immediately, or stop at local contract deployment.
After
A reviewable full-stack reference with explicit economics, protected liabilities, a live testnet client, verified source, deterministic release workflows, and public transaction proof.
Challenges, tradeoffs, and next steps
Hardest part: Keeping phase pricing, generic asset decimals, oracle validation, escrow liabilities, refunds, vesting, role boundaries, deployment artifacts, and frontend state consistent across the complete lifecycle.
Key learning: Deployment is part of protocol design: the contract, testnet assets, roles, verification state, frontend configuration, transaction proof, deprecation path, and secret hygiene all need explicit validation.
- Commission an independent security review before any real-funds use.
- Add formal verification for core escrow, phase, and vesting invariants.
- Broaden end-to-end browser coverage around wallet and lifecycle states.
- Use a carefully operated multisig for administrative and treasury roles in any future non-demo environment.