After learning Solidity forget the ERCs

tehnalogos — Sun, 07 Jun 2026 21:41:25 +0000

ERC20, ERC721, and ERC1155 were brilliant inventions.

They gave Ethereum a shared language for digital assets. Wallets could recognize tokens. Marketplaces could list NFTs. Indexers could track balances and ownership. Apps could integrate with assets they had never seen before without every team inventing its own custom logic.

That was a foundational step for the EVM ecosystem.

But here is the uncomfortable part: an app can use ERCs correctly and still feel absolutely terrible.

The contract can be audited. The token standard can be familiar. The wallet integration can work. The transaction can settle. The events can index properly. The marketplace can display the asset.

And the user can still leave thinking, “Why was that so painful?”

That is the gap developers keep misdiagnosing as “bad UX.” It is deeper than that. The problem is not that crypto apps need prettier buttons or fewer popups. The problem is that most EVM apps are built around assets first and users second.

ERCs standardized tokens. They did not standardize the user. And that is the layer consumer crypto is still missing.

Correct ERCs, Terrible UX

The classic EVM learning path goes something like this:

Learn Solidity.
Learn ERC20.
Learn ERC721.
Maybe learn ERC1155.
Deploy a token.
Build an app around it.

That path made sense for a long time because ERCs were one of Ethereum’s great achievements. They gave the ecosystem interoperability. A token could move between wallets, marketplaces, games, DeFi apps, explorers, and indexers because everyone agreed on a shared interface.

But ERCs also trained developers to think in assets before they learned to think in users.

That bias is everywhere.

A new app often starts by asking:

What token standard do we need?
Do we mint ERC721 or ERC1155?
How do approvals work?
How do we expose transfers?
How do we make the wallet recognize the asset?
How do we preserve marketplace compatibility?

Those are valid questions. But they are not the first questions a consumer product should ask.

The first question should be:

What is the user trying to do, and why is the blockchain in their way?

Because most of the time, it is.

ERC20 Approvals Are a UX Horror Story Wearing a Standard

Take ERC20.

ERC20 is one of the most important standards in crypto. It works. It is everywhere. It made fungible tokens interoperable across the entire ecosystem. (Interesting side note: Fabian Vogelsteller, the creator of the ERC20 standard later recognized its problems and created a set of new standards called LSPs)

It also gave us one of the worst default user experiences in consumer software: approvals.

A user wants to swap, subscribe, buy, stake, mint, join, or play. Instead of completing the action, the app first asks them to approve a spender. Then it asks them to confirm the actual transaction. Sometimes the approval is unlimited. Sometimes it is for a specific amount. Sometimes the wallet warning is terrifying. Sometimes the user has no idea what they just authorized.

From the protocol’s perspective, this is normal.

From a user’s perspective, it is insane.

Imagine opening a normal app and being asked:

“Before you can use this feature, please grant this third-party contract permission to move some amount of your money. You may revoke this later using another interface you have never heard of.”

That is not product design. That is infrastructure leaking through the screen.

The ERC20 approval flow may be technically correct, but technical correctness is not the same as user safety, user understanding, or user trust.

(Interesting side note: Fabian Vogelsteller, the creator of the ERC20 standard later recognized its problems and created a set of new standards called LSPs to solve what ERCs got wrong)

ERC721 and ERC1155 Solved Ownership, Not Experience

The same pattern shows up with NFTs and multi-token assets.

ERC721 and ERC1155 let apps create recognizable, transferable digital objects. That matters. Without those standards, the NFT ecosystem would not have scaled the way it did.

But ownership alone is a thin product primitive.

A user does not experience a collectible, badge, membership, ticket, credential, or game item as a token ID sitting at an address. They experience it as part of a larger context.

What is this asset?
Why did I receive it?
What can I do with it?
Which app issued it?
Does it unlock anything?
Can I use it safely?
Can another app understand its meaning?
Can it interact with my profile, my permissions, or my history?

ERC721 and ERC1155 do not answer those questions by themselves.

They tell the ecosystem that an address owns a token. They do not tell the user why that token matters.

So teams bolt on the missing product layer themselves. Profiles live in one place. Metadata lives somewhere else. Permissions are handled through custom backend logic. Notifications are custom. Token-gating is custom. Recovery is custom. Social context is custom. Delegation is custom.

Every app rebuilds the same missing layer, and almost none of it composes.

That is how you end up with products that are “onchain” in theory but fragmented in practice.

The Real Problem: The User Is Just an Address

Most EVM apps still have a painfully weak model of the user.

The user is an address.

The address connects.
The address signs.
The address owns assets.
The address pays gas.
The address grants approvals.
The address appears in a database.

That model is precise at the protocol level, but it is far too primitive at the product level.

A real user has identity, preferences, devices, permissions, recovery needs, relationships, reputation, history, and intent.

An address has none of that by default.

This mismatch explains why so many crypto apps feel patched together. The contracts may be clean, but the user model is improvised. The product has to reconstruct the human being around a cryptographic key.

That is backwards.

You cannot build consumer software around the assumption that the user is a signing key with a balance.

Gas Is Not a Fee. It Is a Product Interruption.

Gas is the most obvious symptom of this broken architecture.

In a consumer app, gas is not just a transaction fee. It is an interruption in user intent.

The user arrives wanting to do something simple: collect, publish, join, vote, play, claim, send, follow, create, or participate.

The app responds by saying:

“First, go acquire this separate asset from somewhere else so you can pay for the computational cost of doing the thing you already decided to do.”

That may be rational from the protocol’s perspective. It is absurd from the user’s perspective.

It is especially destructive during onboarding. The first few minutes of a product experience are when curiosity is highest and trust is lowest. Yet many EVM apps choose that exact moment to teach users about native tokens, exchanges, withdrawals, bridges, balances, transaction fees, failed transactions, and wallet funding.

By the time the user is ready to press the original button again, the product has already taught them that using it is work.

That is why gasless UX is not a cosmetic improvement. For consumer apps, it is a requirement.

The user should bring intent.
The application should handle execution.

The chain can still settle the action. The transaction can still be verifiable. Ownership can still be meaningful. But the first interaction should not feel like a funding tutorial.

Approvals Are Not Permissions

Approvals reveal the same architectural weakness.

A wallet popup appears. The user wants to continue. The system treats a click as informed consent.

But most users are not approving from understanding. They are approving from momentum.

That is not a real permission model.

In mature software, authority is scoped. A mobile app can access your camera without getting access to your whole filesystem. A team member can publish content without controlling billing. An API key can be limited to a narrow set of operations. A device can be trusted for some actions but not others.

Crypto should be better at permissions than Web2, not worse.

A creator should be able to let a publishing tool manage content without touching funds.
A brand should be able to give a campaign manager limited rights without handing over the whole account.
A game should be able to perform low-risk actions without asking for broad control.
An agent should be able to act within boundaries instead of becoming a private key with too much power.

The right question is not simply:

“Did this address sign?”

The right question is:

“Is this actor allowed to perform this action for this user, under this scope?”

That is the foundation consumer crypto actually needs.

The Ideal Flow Looks Nothing Like Today’s Default Flow

The ideal consumer crypto flow is not:

Connect wallet.
Switch network.
Buy gas.
Approve token.
Confirm transaction.
Wait.
Confirm again.
Hope the asset appears somewhere recognizable.

The ideal flow is closer to:

The user enters with intent.
The app recognizes a profile, not just an address.
The app requests only the permissions it needs.
The user understands what is being authorized.
Gas is handled in the background when appropriate.
Assets arrive with context.
The account can support multiple devices, apps, keys, and agents.
Recovery and delegation are built into the account model.
Other applications can understand the user, their assets, and their permissions without rebuilding everything from scratch.

That is what normal software feels like.

The blockchain should make that flow more powerful, not more painful.

The user should not need to understand the machinery before receiving value from the product. The machinery should exist underneath the experience, executing intent, preserving ownership, and making the system verifiable.

This is the shift from asset-first design to user-first design.

And this is where LUKSO’s LSPs become interesting.

LSPs Start Where ERCs Stop

The interesting thing about LUKSO’s LSPs is not simply that they are “more standards.”

Crypto already has plenty of standards.

The interesting thing is the direction of the abstraction.

ERCs mostly start from the asset. They define how tokens behave, how they transfer, how balances are read, how ownership is tracked, and how approvals work.

LSPs start from a different premise:

What if the user was the primitive?

A Universal Profile is a smart contract based account that can represent a person, creator, brand, DAO, agent, or organization. It can own assets, store metadata, manage permissions, receive interactions, and act as the user’s onchain presence.

The profile is not decoration around the account.

The profile is the account.

That changes the entire product model.

In the usual address-first world, the app begins with 0x... and then tries to attach meaning later. In a profile-first world, the app begins with a richer onchain object that can express identity, ownership, metadata, permissions, and relationships from the start.

That is a much better primitive for consumer applications.

A creator is not just an address that minted something.
A brand is not just an address that owns a collection.
A community member is not just an address that passed a token gate.
A player is not just an address holding items.
An agent is not just a key with too much power.

These are users with context.

The account model should be able to express that.

LSP6 Turns Wallet Prompts Into Real Permissions

LSP6 Key Manager is one of the most important pieces of this architecture because it moves permissions into the account layer.

Instead of treating authority as a single private key that can do everything, a Universal Profile can be controlled through different keys with different permissions.

That means an app, device, agent, or session key can be allowed to do some things but not others.

This is a massive product unlock.

A social app could publish posts without being able to move assets.
A game could update low-risk gameplay state without controlling the whole profile.
A commerce app could request limited permissions for a specific interaction.
A team could give different members different rights over the same brand profile.
An AI agent could act inside a defined scope instead of becoming a security nightmare.

That is the difference between asking users to blindly sign and giving applications a real permission system.

It is also the difference between crypto as a wallet popup simulator and crypto as an application platform.

LSP7 and LSP8 Make Assets Fit the User Layer

LSP7 and LSP8 extend the same user-first philosophy to assets.

They are not just about creating another version of fungible and non-fungible tokens. They are about making assets work more naturally inside a profile-based ecosystem.

Consumer assets are rarely just balances or token IDs.

They can be memberships, collectibles, credentials, access passes, tickets, badges, reputation markers, social objects, game items, creator drops, or brand interactions.

Their meaning depends on who holds them, where they came from, what metadata surrounds them, what permissions they unlock, and how applications interpret them.

In an ERC-first model, assets often float around as isolated objects at addresses.

In an LSP-first model, assets can live inside a richer user graph.

That is a very different foundation.

It means assets can be received with more context. Profiles can track what they own. Applications can build around users instead of reconstructing ownership from scattered token contracts. The asset becomes part of the user’s onchain presence, not just another entry in an indexer.

That is how digital objects start to feel like part of a product instead of artifacts from a transaction log.

LSP25 Fixes the First-Mile Problem

The first-mile problem in crypto is simple:

Users often have to pay before they understand why they should care.

They need gas before they can try the app. They need the right network before they can interact. They need a funded wallet before they can experience the product.

That is backwards.

LSP25 and relay-based execution help flip the order.

The user signs intent.
The application or relay handles execution.
The user gets to experience value before being forced to understand infrastructure.

This does not make the system less onchain. It makes the onchain system usable.

For consumer apps, that sequencing matters. Let the user collect the thing, join the community, publish the post, claim the badge, or try the game. Let the app handle the transaction complexity underneath.

Users should not need to buy gas to discover whether your product is worth using.

The EVM Does Not Need More Token Interfaces. It Needs a User Layer.

Solidity taught developers how to write programmable contracts.

ERCs taught developers how to build programmable assets.

But consumer crypto needs the next step:

Programmable users.

That means smart accounts, universal profiles, scoped permissions, richer metadata, received asset tracking, relay execution, delegation, recovery, and gasless flows.

These are not side features.

They are the difference between an application that exposes contracts and an application that feels like software.

This is the uncomfortable part for experienced EVM developers: knowing ERCs may make you good at the asset layer while leaving you undertrained at the product layer.

You can deploy a correct token.
You can integrate a wallet.
You can expose a mint button.
You can index the events.
You can show the asset in a marketplace.

And you can still ship something only crypto-native users can tolerate.

That was acceptable when the ecosystem was mostly building for itself. It will not be acceptable if the goal is consumer adoption.

After Learning Solidity, Forget the ERCs

The title is obviously bait.

Do not actually forget ERCs.

ERC20, ERC721, and ERC1155 still matter. They are part of the foundation. Developers should understand them. Apps will continue to use them. Interoperability is still valuable.

But after learning Solidity, developers need to stop treating ERCs as the center of the application universe.

ERCs are asset standards.

They are not product architecture.
They are not a user model.
They are not a permission system.
They are not onboarding.
They are not recovery.
They are not identity.
They are not context.
They are not intent.

The next wave of EVM apps will not win because users admire the contracts.

They will win because users do not have to think about the contracts.

The infrastructure will still matter, but it will be arranged around the user instead of exposed as a prerequisite for every action.

That is the promise of LSPs. They do not make the EVM less powerful. They make the power usable.

The EVM already has programmable contracts.
It already has programmable assets.

The missing primitive is the programmable user.

Developers who understand that shift will build products.

Developers who do not will keep shipping contract interfaces and wondering why everyone outside crypto leaves.

To learn more about LSPs see the technical docs

DEV Community: tehnalogos