Concept projectA self-initiated brief, not client work. Product names are fictional.

Beacon · Token launchpad

A launchpad that explains itself.

A token launch site where every action is explained in plain language before anyone signs.

Scope
6 deliverables · 4 phases

The challenge

Token launches ask people to trust contracts they cannot read. Wallet pop-ups show hex data and gas estimates; the real terms — lockups, fees, who can change what — sit in a document few people open.

Goals

  • Designed so every transaction is summarised in one plain sentence before the wallet opens.
  • Designed to show the contract’s key terms next to the button that triggers them.
  • Built on audited contract standards, with an independent audit before launch.

Approach.

  1. 01

    Terms beside actions

    Next to “Join sale” you see the price, the lock-up period and the fee, in words.

  2. 02

    Read before you sign

    Before the wallet opens, a summary card says exactly what will happen and what it costs.

  3. 03

    Show the chain

    Live sale progress and recent transactions come straight from the contract, with links to verify them.

What we built.

A launch website, wallet connection, a sale page with live on-chain data, transaction review cards, a claim dashboard and the sale contracts with full tests.

Sale page — the terms sit next to the button, and the purchase is summarised in a sentence.
Before you sign — what you send, what it costs, and what the contract can and cannot do.
Connecting explains itself: it shares an address, not access.

Concept screens, designed and built in HTML and CSS. All names, figures and data shown are fictional.

Design decisions.

  • Plain sentences first

    Every number has a sentence next to it. “You can claim these tokens from 12 March” beats a timestamp.

  • Violet for the chain, Signal for you

    On-chain data uses the violet palette; the one action you can take is the only warm colour on screen.

  • Calm loading states

    Pending transactions show what is happening and how long it usually takes, instead of a spinner.

How it would ship.

The plan we would run for a project like this, with a demo every week.

  1. Weeks 1–2Risk model, sale flow, contract spec
  2. Weeks 3–7Contracts, tests, dApp on testnet
  3. Audit windowIndependent audit and fixes
  4. Launch weekMainnet deployment, monitoring

Stack

  • Solidity
  • Foundry
  • OpenZeppelin
  • TypeScript
  • viem
  • wagmi
  • WalletConnect
  • Astro

Deliverables

  • Launch website
  • Sale and claim contracts
  • Wallet connection and dApp
  • Transaction review cards
  • Audit preparation pack
  • Deployment runbook
Next concept HaldeBook a class in three taps