## What v1 does

It **registers** a token that already exists. A builder supplies a network and a contract address,
and the name, symbol, decimals and total supply are **read from the chain**, never taken from the
form.

That distinction matters: a form that accepts a symbol lets anyone register USDC's address and label
it whatever they like. Reading means the page shows a fact about the contract rather than a claim
about it.

`VerifyTokenOfferingJob` does the reading. It refuses an address with no code at it (an externally
owned account is not a token) and an address whose contract does not answer the ERC-20 reads.

## Why deploying is not built

Deploying a new token means shipping compiled bytecode in a paid kit, and **that is a trust claim
rather than a feature**. It only holds with a reproducible build: committed Solidity source, an exact
compiler version and settings, and a documented command that reproduces the bytes byte-for-byte.
Until that exists, registering is the honest offering: no gas, no bytecode to take on trust, and no
issuance liability created by the kit.

If you add deploying, it needs all of this, and none of it is optional:

- **Reproducible build.** Source, `solc` version and settings, and a command a buyer can run.
- **A boring contract.** Fixed supply minted in the constructor, and no owner, mint, burn, pause or
  upgrade function. Each of those is a rug vector and a support burden.
- **CREATE2 rather than plain CREATE.** An ERC-4337 UserOperation has no contract-creation form, so
  `to: null` from a smart account fails or is silently rewritten. On Base a large share of users are
  Coinbase Smart Wallet. CREATE2 also makes double-submission impossible: the same salt and init
  code cannot create twice.
- **A mainnet guard.** `ONCHAIN_ALLOW_MAINNET_WRITE`, plus type-the-symbol confirmation on a
  distinct page rather than a modal. Modals get dismissed; pages get read.
- **Honest gas.** On Base and every OP-stack chain the **L1 data fee is a separate component that
  `eth_estimateGas` omits**, and for contract creation with multi-KB calldata it usually dominates.
  And do not put a `gas` field in the transaction you hand the wallet: if your limit is low the
  transaction runs out of gas, the user loses the entire fee and gets nothing.

## The scope boundary

Deliberately out, because this is where the money and the liability concentrate:

- No sale, no bonding curve, no fundraising contract. A sale contract needs an owner to withdraw
  proceeds, which reintroduces every rug vector a boring token removes.
- **No LP creation.** It is the next thing everyone asks for, it looks like a small integration, and
  it is not: creating a market is arguably distribution, and "the founder pulled the LP" is the
  canonical rug story.
- No airdrop execution. A Merkle claim contract holds value and needs an owner to sweep unclaimed
  tokens, undoing everything the boring contract achieved.

## The public page

One page in this module is public: `/t/:public_slug`, for offerings that are both live and
published.

It is a **deliberate, narrow exception** to the kit's tenancy rule, written to be obviously so. It
is found by a **random 16-character slug, never by id**, because an id-addressed public route is
enumerable, which would turn "share this link" into "read every workspace's tokens". Registering a
token does not publish it; the builder sets `published` explicitly.

## You are the issuer

The registration form carries this, and it belongs there rather than only in a doc, because that is
the screen a person actually reads:

> One Shot ships code. When you present or issue a token, *you* create it, *you* distribute it, and
> *you* are the person a regulator, an exchange, or a holder will look to. Issuing or promoting a
> token is a regulated activity in many jurisdictions and the rules differ by country. This is not
> legal or tax advice.