Solid: Fixed-Supply ERC-20 Without Initial Allocation (Clones of NOTHING)

Magicians Primordial Soup
, , , ,
1

Solid is a fixed-supply ERC-20 primitive that removes discretionary initial allocation.

This sits near the design space discussed here:
https://ethereum-magicians.org/t/add-erc-token-with-built-in-amm/22336

However, Solid is not an ERC proposal and not a generalized AMM standard. It is a single canonical implementation contract named NOTHING, from which all Solids are made.

The structural issue

Fixed supply does not imply neutral allocation.

In a typical ERC-20 deployment, the full supply must be assigned at creation. Even if minting is permanently disabled, that initial assignment is a structural privilege.

Solid removes that step entirely.

There is no premine. There is no allocation event. There is no initial assignment to an externally owned account.

What it is

A Solid is an ERC-20 token that implements its own constant-product trading logic inside the token contract itself.

There is no external pair contract.
There is no separate AMM deployment.
The pricing invariant and the token live in the same contract.

Every Solid:

  • has a fixed total supply

  • maintains its own in-contract constant product pool

  • can always be bought or sold directly against that pool

  • has no owner, admin, upgrade path, or fees

The constant product curve is standard. The constraint is the elimination of discretionary initial allocation.

NOTHING and “making” a Solid

All Solids are ERC-1167 minimal proxy clones of NOTHING.

New Solids are created by calling make(name, symbol) on NOTHING:

  • make is not payable

  • the full supply is placed directly into the pool

  • the maker receives zero tokens

  • only name and symbol are configurable

No new logic is deployed when making a Solid. Clones delegate to the canonical NOTHING implementation while maintaining independent state.

Calling make (or made) on any Solid behaves identically to calling it on NOTHING.

Mechanism

Pricing follows a constant product invariant:

k = S * E

Where:

  • S is the Solid balance held by the contract

  • balance is address(this).balance

  • E = balance + 1

The +1 is a constant virtual native reserve. It exists only to define the invariant at initialization and cannot be extracted.

At creation, balance = 0, so E = 1.

The maker must acquire tokens by trading against the same invariant as everyone else. The only structural advantage is temporal ordering.

Canonical references

Spec: https://solid.uniteum.one/protocol
NOTHING: https://solid.uniteum.one/nothing
Code (jekyll branch): https://github.com/uniteum/solid
NOTHING on mainnet: https://etherscan.io/address/0xB1c5929334BF19877faBBFC1CFb3Af8175b131cE
Example Solid (Uniteum 1): https://etherscan.io/token/0x7D5B1349157335aEEB929080a51003B529758830

Feedback

I’m looking for prior art I may have missed, obvious structural failure modes, or reasons this constraint does not meaningfully change the launch surface.

1 Like