Skip to content
ArchXS

Practice

On-chain products that survive their own redesign

A public chain promises that the rules do not change behind anyone's back. A product promises that it will be corrected after launch. Both can be kept, but only if the upgrade boundary is drawn deliberately, before the launch rather than during an incident.

On-chain products that survive their own redesign
Fig. 01What must never need changing goes on the chain and stays immutable, everything else sits behind an upgrade boundary designed on purpose, and the buyer is not required to own a wallet in order to buy.

How we look at it

Most projects of this kind fail on one of two symmetrical mistakes. Either the contract is immutable and the economy is frozen at whatever the team believed on launch day, or the logic sits on a server and the chain holds a picture plus a receipt, in which case the on-chain part is decoration. Neither is a technology problem; both are one unanswered question: what in this product must never need changing. The second question belongs to whoever will actually buy the thing. In a mass-market channel a wallet cannot be a precondition of the transaction, because an architecture that demands a new competence from the buyer before the sale is no longer selling the product, it is selling the competence. And in a regulated organisation the chain is the cheap part. The expensive part is agreeing what the product is in the categories that organisation already uses, because only then can it be sold, supported and defended in an audit.

What we have built

We led the Polish Crypto Stamp for the national postal operator, an organisation of more than 80,000 people, from concept to market launch, accountable for the commercial, technical and legal sides and for the external partners. The physical item stays a full postage stamp and the token is its counterpart rather than its replacement; print-run and numbering discipline is enforced in the contract; the purchase runs through the channel the customer already used, paid for in the way they already paid, with no wallet required at the counter. In our own protocol the collections are built on EIP-2535: one proxy routing calls by function selector into 21 facets over a shared storage layout, so a correction to game mechanics ships as a facet replacement instead of a migration asking 2,300 holders to move to a new address. Composability is taken from ERC-6220, ERC-7401 and ERC-5773 rather than invented, which is what lets a marketplace we have never spoken to render a composed token correctly. The economy is split into an elastic utility token and a fixed-supply governance token, with staking and a receipt token that lets a holder exit liquidity without unstaking. Off-chain the split is kept honest: an indexer listens to events and fills a read model in PostgreSQL, applications talk to the API and never to a node, and nothing that decides an outcome lives there, so if the API disappears the state is still on the chain and still verifiable. Marketplace mechanics run on Seaport for ERC-721 and ERC-1155 instead of being rewritten. On the identity side a Keycloak SPI verifies EIP-191 signatures with a single-use, time-limited nonce, so a wallet is one authentication method in the same realm as email OTP and passkeys, with an embedded wallet for users who arrive without one and ERC-4337 smart accounts covered; the client half is published under MIT as a wagmi connector.

What follows

What is left is a product someone else can integrate without asking: contract addresses, the facet inventory and the token model published, and an upgrade path exercised rather than assumed. Two costs are stated rather than hidden, upgradeability means holders trust an admin key, and storage shared across facets punishes a careless struct change in every facet at once. What it buys is the right to correct the design after launch without asking anybody to migrate.