ERCs, Solved
benchmark · open research

Consumer Blockchain Architecture Benchmark

An open benchmark measuring how seven chains assemble the architecture a consumer crypto app actually needs — accounts, identity, permissions, gasless UX, metadata, social primitives, and infrastructure burden. Every value is justified from the chain's own documentation.

Across ten architecture measurements over seven chains, LUKSO requires the fewest infrastructure components for gas-sponsored UX, the fewest contracts for a profile-aware account, and is the only chain with standardized cross-application profile, follower, and dynamic-metadata protocols. Ethereum L1 and its L2s score highest on liquidity-adjacent dimensions and ecosystem maturity. Solana scores highest on throughput and mobile SDK maturity. Every number on this page cites the chain documentation it was derived from.

Download the data.

What this benchmark measures

Most chain comparisons measure TPS, fees, or TVL. Those tell you about the network. They don’t tell you about the consumer-app architecture a developer has to assemble on top of it. This benchmark measures the architecture instead — how many components are required, how many steps the user goes through, what the account standard exposes — across ten dimensions chosen to track the constraints that actually bind consumer apps.

What it does not measure

This is not a benchmark of security, decentralization, or settlement assurances. Those matter, but they are addressed elsewhere and they don’t change the consumer-architecture decision. This benchmark also doesn’t measure ecosystem maturity quantitatively — the decision guides treat that as a qualitative rating.

How the numbers are justified

Every value in the matrix above is traced back to a published document on the chain it describes. The How each metric was scored section that follows the matrix gives the methodology for each test and, per chain, the document the number was derived from. Most cells are categorical (counts of components, dimensions, yes/no on whether a chain-level standard exists) and are checkable directly against the cited specification. Where a value is an estimate rather than a measured count — test 10, LOC — the methodology says so explicitly and the cited documents are the basis the estimate was scaled from.

How LUKSO shows up in the results

LUKSO wins five of the ten dimensions — granularity of permissions, profile sharing, asset notification, account extensibility, and social relationships — because those dimensions track exactly what LSP0 + LSP1 + LSP3 + LSP4 + LSP6 + LSP17 + LSP25 + LSP26 standardize at the chain level. It ties for first on gas-sponsorship components (with Solana). It loses on ecosystem maturity and liquidity reach, both of which are out of scope for this benchmark but covered explicitly in the decision guides.

If a citation here goes dead or the cited document changes substantively, flag it via the page’s source repo so the row can be re-scored against current docs.

Results.

Test Ethereum L1BaseArbitrumOptimismPolygonSolanaLUKSO
Infrastructure components for gas sponsorship count Count of distinct services required to sponsor a single user transaction end-to-end. 4 2 4 4 3 1 1
Contracts + services for profile-aware account count Distinct contracts + protocols required to give a user an account that other apps can read profile data from. 5 4 5 5 5 3 2
Steps from first visit to first signed action steps Median onboarding steps to first signed transaction in a representative consumer app. 7 3 6 6 5 4 3
Granularity of standardized permissions dimensions Number of standardized permission dimensions exposed on the account itself (function, address, asset standard, call type, data key). 0 0 0 0 0 0 5
Cross-application profile shared yes/no Whether profile metadata is stored on the account and readable by any application without per-app integration. no no no no no no yes (LSP3)
Assets notify receiving account yes/no Whether a standardized receiver hook fires on the recipient account when an asset is transferred. per-token (ERC-721/1155 onReceived) per-token per-token per-token per-token no yes (LSP1)
Accounts can add functionality post-deployment yes/no Whether the account supports standardized method extension after deployment without redeployment. per-account (Safe modules / Diamonds) per-account per-account per-account per-account per-program yes (LSP17)
Standardized mutable token metadata yes/no Whether token metadata can be updated through a chain-level standard rather than per-token implementation. ERC-4906 signal ERC-4906 signal ERC-4906 signal ERC-4906 signal ERC-4906 signal Metaplex mutability yes (LSP4 + ERC-725Y)
Chain-level social relationships protocol yes/no Whether a standardized follower / interaction registry exists at the chain level. no (Lens, Farcaster are protocols above) no (Farcaster) no no no (Lens) no yes (LSP26)
LOC for equivalent consumer-app prototype LOC (indicative) Estimated lines of application-specific code required to ship a reference consumer app (profile create, follow, gasless tx, dynamic NFT mint) on each chain. Indicative; rank order is robust, exact LOC is not. ~3200 ~2400 ~3100 ~3100 ~2900 ~2200 ~900

How each metric was scored.

Every value in the matrix above is derived from a chain's own documentation. The methodology paragraph for each metric explains what is being counted; the per-chain citations point at the document the number came from.

  1. 01

    Infrastructure components for gas sponsorship

    unit · count

    Count of distinct services or contracts an operator must deploy, run, or rent to sponsor a single user transaction end-to-end. Derived from each chain's documented gasless or fee-delegation architecture.

  2. 02

    Contracts + services for profile-aware account

    unit · count

    Distinct contracts and protocols a developer must integrate so that a user's account exposes profile data readable by an independent application without per-app integration. Derived from each chain's documented account-and-identity stack.

  3. 03

    Steps from first visit to first signed action

    unit · steps

    Median user-visible step count in each chain's canonical onboarding flow, taken from the chain's official getting-started or wallet-onboarding documentation.

  4. 04

    Granularity of standardized permissions

    unit · dimensions

    Count of standardized permission dimensions exposed on the account contract itself — not via an SDK, not via an opt-in module. Drawn from each chain's account-level standards documentation.

  5. 05

    Cross-application profile shared

    unit · yes/no

    Does a single profile-metadata standard exist that any application can read from any account on the chain without per-app integration?

  6. 06

    Assets notify receiving account

    unit · yes/no

    Does a standardized hook fire on the receiving account (not on the token contract) when an asset arrives, allowing the account to react?

  7. 07

    Accounts can add functionality post-deployment

    unit · yes/no

    Does the account standard expose a chain-level mechanism for adding functionality after deployment without redeploying the account?

  8. 08

    Standardized mutable token metadata

    unit · yes/no

    Can token metadata be updated through a chain-level standard that defines both storage and mutation? ERC-4906 standardizes only the update signal; not the storage shape.

  9. 09

    Chain-level social relationships protocol

    unit · yes/no

    Does a standardized follower or interaction registry exist at the chain level, or only as a protocol above the chain?

  10. 10

    LOC for equivalent consumer-app prototype

    unit · LOC (indicative)

    Indicative estimate, not a measured value. The figure scales each chain's documented quickstart code samples for the four flows (profile create, follow, gasless tx, dynamic NFT mint) to the same target app shape. The rank order is the robust signal; exact LOC depends on implementation choices and should not be quoted as a measured number.

Primary sources.

Adjacent reading.