Technical Analysis of Ethereum Inscriptions ETHS: Essentially Financial Hype Rather Than Product Innovation
TechFlow Selected TechFlow Selected
Technical Analysis of Ethereum Inscriptions ETHS: Essentially Financial Hype Rather Than Product Innovation
Ethscriptions capitalized on the BTC inscription trend, relying on hype and repackaging old ideas, but has yet to discover a new paradigm.
Navigating Web3 tides with focused insightsAuthor: Wuyue, Geeker Web3
Introduction: Current Ethereum inscriptions are essentially rebranded Ordinals—there’s no truly novel paradigm. ETHS still carries security risks; although it is more decentralized than Rollups, its withdrawal process relies on third-party notaries/managers, posing a theft risk. Clearly, ETHS at present is driven more by financial speculation than delivering innovations beyond what Ethereum Layer2s offer.
The recent boom in Bitcoin ecosystem inscriptions has inspired developers on other chains to build similar systems. While implementation details and capabilities vary slightly across different blockchains, these inscription systems share some common characteristics:
-
Inscriptions utilize text data attached during transfers to express intended operations, such as writing "transfer 1 coin to XXX" within the message. Note that this information is plain text and does not trigger on-chain smart contract execution.
-
Developers design a set of rules and standards to formalize all textual messages.
-
Developers provide an Indexer—a tool that aggregates all inscription-related text data from the blockchain and computes the state of the inscription system. The Indexer is an open-source off-chain component that anyone can run.
Bitcoin's Ordinals introduced a mechanism for issuing NFTs and tokens on BTC, sparking widespread discussion about Bitcoin L2 solutions. In this sense, Ordinals possess certain exploratory and pioneering qualities. However, Ordinals face technical and usability limitations due to Bitcoin's architectural constraints and have drawn criticism from core Bitcoin community members over issues like dust pollution and excessive data usage.
So, is replicating inscriptions on Ethereum meaningful? After all, Ethereum already supports complex smart contracts, including native ERC20 and NFT standards. What impact would these inscription projects have on the Ethereum ecosystem, and could they provoke controversies similar to those seen on Bitcoin?
Technical Implementation of Ethscriptions
Let’s first examine how Ethscriptions work—one of the most prominent inscription projects on Ethereum—primarily leveraging Calldata for operation.
Calldata refers to raw input data transmitted in Ethereum transactions. It is typically used to pass parameters when interacting with smart contracts but can also be used to send text messages (e.g., notes, engravings, transfer memos) to EOA addresses. The “Input Data” field in the image below represents calldata.
If you want to inscribe "Hello world" using Ethscriptions, you need to construct a transaction containing the following calldata:
Once the off-chain Indexer detects this transaction, it updates its database and notifies users: a new inscription has been created with the content "Hello world." More complex content, such as base64-encoded images, can also be embedded in inscriptions.
Ethscriptions currently adopts six ESIPs (Proposals for improvement to the Ethscriptions protocol), analogous to EIPs, defining inscription usage in various scenarios. However, these are relatively basic specifications—for example, formatting rules for inscriptions initiated from EOAs or emitted contract events.
Since Ethscriptions operates on Ethereum, it can leverage Ethereum smart contracts to some extent. That said, direct interaction with smart contracts is not recommended by the Ethscriptions team.
Although official NFT marketplaces are implemented via smart contracts, according to the documentation, Ethscriptions aims to offer users “decentralized and affordable computation services”: moving computation off-chain significantly reduces Ethereum usage costs.
Let’s analyze the cost of calling smart contracts, which consists of three parts:
-
Base transaction cost: Required for any Ethereum transaction, currently 21,000 gas.
-
Data transmission cost (calldata): Calldata usually transmits data and parameters for smart contract interactions. After EIP-2028 adjustments, each non-zero byte consumes 16 gas, while zero bytes consume 4 gas.
-
Contract execution cost: If a transaction invokes a function in a smart contract, additional computational costs apply based on complexity. For instance, updating state (like balance changes in an ERC-20 contract) via SSTORE may consume 5,000–20,000 gas.
Take a simple USDT transfer as an example, consuming 63,197 gas total, with the following calldata:
Let’s break down this calldata and estimate its gas cost:
-
Ethereum calldata uses hexadecimal format, where every two characters represent one byte (16² = 2⁸). The prefix 0x indicates hexadecimal encoding.
-
The four non-zero bytes after 0x, a9059cbb, constitute the function selector. -
Next comes a 32-byte address field, padded with 12 leading zeros (since Ethereum addresses are 20 bytes long, extended to 32 bytes), followed by 20 non-zero address bytes.
-
The final 32 bytes represent the amount, heavily left-padded with zeros, ending with
3b9aca00, representing 4 non-zero bytes. -
Thus, there are 28 non-zero bytes and 40 zero bytes.
Therefore, calldataGas = 28 * 16 + 40 * 4 = 608 gas.
With total gas at 63,197, subtracting calldata and base costs leaves 41,589 gas for smart contract computation. This shows computation dominates the cost—even for a simple transfer—and will grow further for more complex transactions.
Moving computation off-chain indeed significantly lowers usage costs: instead of directly invoking smart contracts on-chain, users can send transaction data to a designated EOA address,
0x00000000000000000000000000000000000face7
including in the calldata which contract was intended to be called and corresponding input parameters. Since this address is an EOA with no associated code, no on-chain computation occurs—only a message is published.
Off-chain, once the Indexer detects this message, it parses it to determine which Ethereum contract the sender intended to interact with and then performs the computation off-chain to derive the result.
For the Indexer to perform inscription and smart contract computations off-chain, it must follow a State Transition Function (STF) rule set and runtime environment—complex versions of which are called virtual machines (VMs). Ethscriptions introduced its own VM under ESIP-4—originally named Ethscriptions VM, later renamed Facet VM.
Facet—A Kind of Coprocessor
Facet defines itself as a cheap, usable, secure, and decentralized computing platform. It listens to Ethscriptions calldata on Ethereum, pulls it into its VM for computation, and returns results to users. Facet comprises several key components:
-
Facet VM: A Ruby-based virtual machine responsible for monitoring ETHS transactions, parsing calldata, and executing computations.
-
Rubidity: A smart contract programming language used in Facet, resembling Ruby while retaining many Solidity concepts and syntax to ease developer onboarding.
-
Dumb Contract: Contracts running on Facet. The name is humorous. Some call them “dumb” because they reflect silent processing. Yet per the official motto “So dumb, they’re smart,” it carries a defiant tone against smart contracts—hence “dumb contract” remains appropriate.
Dumb contracts are never actually deployed on Ethereum; their code is only published on-chain via calldata. Below is an example of minting via a Dumb Contract:
A minting transaction sends calldata to the EOA black hole address
0x00000000000000000000000000000000000face7
declaring the token and quantity to mint—essentially identical to Ordinals or BRC-20:
Now let’s visually compare Rubidity and Solidity, shown below:
While the team claims Rubidity resembles Solidity to ease adoption, this poses challenges for developer growth. Moreover, the Facet VM currently only supports dumb contracts pre-approved on an official whitelist, indicating limited confidence in the language and VM. Whether reusing the EVM would be harder than building a new VM and language is debatable—but one thing is clear: a new language, new contracts, new ecosystem, and new way to use Ethereum make for compelling marketing.
Facet’s Critique of Smart Contracts
Facet’s documentation includes this provocative statement: «Smart Contracts are considered to be the feature above all others that makes Ethereum special, and yet Facet’s thesis is that Smart Contracts are Ethereum’s biggest design flaw.»
They argue that Ethereum smart contracts are the largest design flaw because outputs are fully determined by inputs (calldata), so performing computations on-chain wastes money unnecessarily. Combined with Ethscriptions’ claim of providing “decentralized and affordable computation,” it’s evident that Ethscriptions and Facet aim to create a perception: “We’re creating a new Ethereum scaling paradigm and usage model.” Yet many of ETHS’s technical approaches appear unreliable.
From a product perspective, Facet enabling indirect smart contract calls off-chain and maintaining its own dumb contract system aligns with its vision.
But economically speaking, there’s no free lunch—storage and computation require funding. So how should the Indexer cover these costs? The team offers no clear answer. Let’s consider possibilities:
-
Charge users directly—e.g., marketplace fees paid by buyers. But we cannot evaluate a quasi-L2 network’s long-term sustainability through a simple project’s fee structure.
-
Rely on ecosystem hype and speculative gains. This works short-term for project teams but isn’t sustainable. If Ethscriptions aims to become a new Ethereum paradigm, the Indexer needs a durable, network-driven economic model.
-
If operated as a non-profit public good, who would fund it? Likely not the Ethereum Foundation, given Ethereum already has strong alternatives—Rollups.
Root Causes Behind Facet and Dumb Contracts
If we only needed simple Ethereum inscriptions, Ethscriptions alone would suffice. Why did ESIP-4 lead to the creation of Facet?
Because the inscription system cannot support complex transaction logic. Consider the official Ethscriptions NFT marketplace contract, which uses an orderbook model.
To deposit an inscription NFT into the contract, simply write the EthscriptionId into calldata and call the marketplace contract. This intentionally uses an invalid function call format, triggering the fallback() function by default.
This eventually emits an event named PotentialEthscriptionDeposited on Ethereum. Off-chain Indexer nodes detect this event and locally update ownership of the NFT to the marketplace contract.
To save gas, the ETHS marketplace does not store seller listing details (price, expiry time, etc.) in Ethereum contracts. Instead, these are stored off-chain—likely on dApp servers. Buyers monitor these messages and can submit a buyWithSignature() command to purchase.
Orderbooks are acceptable for NFTs due to their non-fungibility. But can fungible token inscriptions use AMM mechanisms? No. Neither NFT nor token inscription states exist on L1—they resemble Ordinals and BRC-20. This contradicts community narratives—be cautious: inscriptions are not genuine assets natively on the ETH chain. Merely having calldata on L1 and declaring operations doesn’t qualify something as a native L1 asset. Otherwise, Rollup L2-native assets could also be called L1 assets since their calldata resides on L1. Clearly, labeling such assets as native L1 is absurd.
You might ask: didn’t we just use a smart contract for trading? How can we say contracts can’t read or manipulate inscriptions? Actually, the contract only handles payments and emits events for off-chain Indexers to act upon. From Ethereum’s EVM perspective, inscription states cannot be reconstructed in Ethereum’s dedicated state database (“world state”), nor can contracts reference them.
Regardless of asset type—token, NFT, or otherwise—I offer a simple criterion to distinguish L1 vs L2 assets: Can its state be reconstructed in Ethereum’s “world state”? Can the L1 EVM reference, invoke, query, or modify its state? If not, it’s not an L1 asset.
Hence, the deposit event is named PotentialEthscriptionDeposit—“potential inscription deposit”—not a definitive one, because the contract cannot verify the inscription’s existence or authenticity. If you list a non-existent or someone else’s inscription, the contract won’t reject it—the Indexer simply won’t recognize your action.
Thus, inscription systems can only implement simplistic pseudo-contract logic, like orderbooks. Orderbooks fundamentally rely on mutual recognition between parties under agreed rules—something expressible even in plain text, much like inscriptions themselves.
Imagine completing the above without smart contracts: a seller includes a message in a regular transaction saying “Send me 1 ETH with note ABC to get my inscription NFT #123.” As long as the Indexer supports this logic, detecting a 1 ETH transfer with note ABC allows immediate off-chain state update.
Of course, this approach introduces problems—such as multiple buyers attempting to claim one NFT, resulting in duplicate transfers. The seller receives multiple payments, but only one user gets the NFT in the Indexer’s database. This may partly explain why the team, despite criticizing smart contracts, still uses them for their flagship marketplace. Hence, you should understand that Facet’s claim of invoking smart contracts without computation is unreliable marketing.
True, orderbooks could theoretically work with plain text instead of contracts. But more complex logic like AMMs requires actual smart contracts—they demand contract-enforced validation, not just peer-to-peer agreement. Reliable verifier contracts must check balances, liquidity, and perform calculations—all requiring access to verifiable asset data.
AMM is merely a basic DeFi form; any more complex logic cannot be realized solely within Ethscriptions. This explains the emergence of Facet—its primary goal is cross-domain functionality! It’s essentially an L2, albeit without blocks. We say “cross-domain” rather than “cross-chain.” Once all L1 assets move into Facet, cross-domain invocation issues vanish, enabling complex operations on off-chain assets via dumb contracts.
Comparison with Rollups
After this lengthy analysis, it should be clear that Ethscriptions resemble Rollups. But only “resemble”—strictly speaking, they implement only a subset of Rollup core functionalities. Missing features critically undermine its narrative or worse, expose users to serious risks.
Rollups are complex systems—we won’t dive deep here. They share similarities with Ethscriptions:
-
Both submit L2 transaction data (calldata) to Ethereum L1.
-
Both move computation off-chain.
These similarities are obvious. Now let’s examine differences in detail.
Rollup batches calldata submissions
In Rollups, users rarely submit transactions directly to L1. Instead, they send them to off-chain sequencers, which batch, compress, and submit multiple transactions’ calldata in a single L1 transaction. This spreads the 21,000 gas base cost across many users.
Ethscriptions lacks this mechanism—all users submit calldata directly to L1.
Using our earlier USDT example (608 gas calldata cost), assume 100 users initiate 100 transactions. Roughly estimating both models:
-
Each inscription user pays 21,608 gas (608 + 21,000). No computation cost since it happens off-chain.
-
Each Rollup user pays ~818 gas ((608*100+21,000)/100). Computation cost same as above.
Of course, Rollup users also pay L2 computation/storage fees to the sequencer, though these are far cheaper than L1 and negligible here. Rollups also add minor metadata but benefit from better compression—we’ll skip those nuances.
This rough estimate shows Ethscriptions holds no cost advantage over Layer2s. Additionally, I’ve seen community claims like “4,000 inscriptions can be transferred in bulk for ~0.11 ETH, averaging $0.05 per transfer” to prove low costs—yet these misunderstand ETHS mechanics and interaction details.
Off-chain pre-confirmation
Thanks to off-chain sequencers, Rollup users receive pre-confirmations within 1 second—much better UX than waiting 12+ seconds for L1 confirmation. Inscription supporters may counter that pre-L1 inclusion, finality remains uncertain.
Censorship resistance and decentralization
Rollup users may face censorship by off-chain sequencers, whereas Ethscriptions cannot censor users. Well-designed Rollups include force-inclusion mechanisms to resist sequencer censorship, ultimately removing their power to censor.
Thus, Rollup users can bypass the sequencer entirely and interact directly with L1. Rollups offer flexibility—use fast sequencers or go straight to L1. Ethscriptions, however, forces all traffic onto L1, giving users no choice.
Additionally, Ethscriptions criticizes Rollup sequencers as centralized. Yet Indexers themselves are highly centralized. Ethscriptions argues Indexers aren’t truly centralized because anyone can run and verify them. But in reality, most users won’t self-host nodes. Thus, ETHS only appears more decentralized under extreme conditions—while Rollup sequencers may fail, ETHS can persist as long as multiple community-run Indexers remain active.
Revenue model
No project can survive on goodwill alone. Sustainable projects—whether centralized or decentralized—must establish viable revenue models to ensure long-term network security.
Rollup sequencers have clear revenue streams: charging higher gas fees, extracting MEV, etc.—providing incentives to maintain network integrity. In contrast, since Ethscriptions users submit calldata directly to L1, the Indexer struggles to monetize.
Developer experience
Most Rollups reuse Ethereum’s development languages and toolchains, allowing seamless migration. None of this exists in Ethscriptions—developers must learn Rubidity, build new scanners, master a new VM, etc. These barriers, conversely, could represent frontier opportunities in a nascent ecosystem.
Withdrawals and state settlement
This is Facet’s fatal flaw. Rollups don’t just submit calldata (inputs) to L1—they periodically submit finalized post-computation states (outputs). ZKRs and OPRs use different proof methods to verify input-output consistency. Regardless of method, L1 contracts serve as ultimate arbiters. On Rollups, outputs are provably linked to inputs—forgery is impossible.
What’s the purpose of state settlement? Withdrawals—moving funds from L2 to L1. Once a state root is published on L1, users can prove their withdrawal request is included via Merkle proofs. Upon verification, the L1 contract releases the assets.
Facet lacks a state settlement mechanism, making permissionless, decentralized withdrawals from L2 to L1 impossible. Earlier we noted it needs an L2 layer to enable complex contract logic—like FacetSwap, an AMM built with dumb contracts.
Notice FacetSwap clearly features separate deposit and withdrawal actions. Standard swaps don’t require deposits/withdrawals—Facet mandates cross-domain movement first.
In Facet, deposits require locking L1 funds in an L1 bridge contract and emitting the ethscriptions_protocol_CreateEthscription event for Indexer indexing—consistent with standard L2 deposit patterns.
Withdrawals, however, pose severe security risks. With no state settlement, L1 contracts cannot autonomously verify withdrawal validity. So what does Facet use? Administrator approval—or “witness mechanism”—similar to the hacked Axie bridge.
Let’s look directly at Facet’s bridge contract:
0xD729345aA12c5Af2121D96f87B673987f354496B.
hashedMessage is a message signed by a signer—an appointed admin address. Without state settlement, no validation (e.g., checking if the account holds sufficient balance on L2) is possible. Thus, anyone controlling the signer private key—malicious team member or hacker—can withdraw all funds from the contract.
In Rollups, no witness approval is needed. In sidechains, if aiming for decentralization, validators can be selected from consensus participants and economically bonded to deter malice.
In Ethscriptions and Facet? Nothing. It’s bluntly, unapologetically just an admin address. For a project loudly proclaiming “smart contracts are flawed,” “Rollups are centralized,” and “we’re a next-gen computing platform,” this feels overly careless. Clearly, it has many flaws—but we can remain watchful. Though these issues are hard to fix and may similarly plague Bitcoin L2s.
Conclusion
Current Ethscriptions involve certain “false advertising.” Key points:
-
Assets on Ethscriptions and Facet are not issued on L1.
-
To enable complex contract capabilities, Facet evolved into an L2 entity—but with major fund security risks.
-
Despite promoting on-chain de-contracted computation, the team doesn’t even apply this to their flagship applications.
-
Ethscriptions resembles a Rollup with severely incomplete core functions—neither cheaper nor faster, nor as secure. Everything it achieves, Rollups can do; critical features Rollups provide, it cannot.
-
To fix these issues, it would need state settlement, sequencers, L2 blocks—and ultimately become a Rollup.
Riding the wave of Bitcoin inscriptions, Ethscriptions repackages old ideas with new hype but hasn’t discovered a new paradigm. Current ETHS is primarily driven by financial speculation rather than offering anything beyond existing Ethereum Layer2 capabilities. Its long-term value remains to be explored, but in its current form, ETHS bears “an unbearable weight of being,” with promotional claims vastly exceeding practical outcomes.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
