Blog

For years, discussions about AI threats remained largely hypothetical. The prevailing concern was that a model inside a chat window might become a strategist for hackers, helping them write devastating malware.Looking back, such fears were often dismissed as something still far in the future. Yet the turning point in the real world has arrived sooner than many expected.In early October, while investigating a campaign targeting South Korean financial institutions, CrowdStrike found that the attackers had integrated agentic AI directly into their operational pipeline. By connecting multiple large language models, including DeepSeek, GLM, and Grok, the attackers allowed AI to perform concrete tasks such as reconnaissance, penetration testing, and attack execution.This was not an isolated development.Anthropic’s September threat intelligence report found that multi-agent frameworks had recently been used for reconnaissance, vulnerability exploitation, and data theft. These systems could operate continuously for hours or even days, while humans retained only a small number of critical decisions, such as selecting targets and reviewing results.In other words, AI is visibly changing the nature of cyber offense and defense. Automated attacks once relied mainly on predefined rules and scripts. Now, agents are beginning to take over reconnaissance, judgment, and strategy adjustment as well, making attacks cheaper, easier to scale, and capable of operating autonomously for extended periods.As more of these autonomous entities are deployed throughout production systems—and embedded more deeply in our work and daily lives—a more difficult question is emerging:What happens if agents learn to “collude” with one another?1. From Helping Hackers Write Code to Agents Finding Ways to Act on Their OwnThe most important difference between agents and traditional chatbots is not simply that the underlying models are more capable. It is that agents are beginning to acquire real-world agency.A mature agent today can browse the web, execute code, read emails, call APIs, operate cloud services, and connect to a growing range of external tools through MCP, Skills, and other infrastructure. For further reading, see “When Hackers Scale Up with AI: The Next Level of Web3’s Security Arms Race.”The more capable these agents become, the more useful they are. But from a security perspective, their capabilities are also eroding a boundary that once mattered enormously. A series of incidents this year has made that shift particularly clear.On October 1, Salt Labs disclosed a previously patched vulnerability in Manus. At its core, it was an indirect prompt-injection vulnerability. Researchers only needed to send an ordinary email containing hidden malicious instructions to the target’s inbox. When the user later asked Manus to check their email, the agent could process those instructions and ultimately execute code planted by the attacker.The attack required neither a click on a malicious link nor the prior theft of a password. Manus’s security guardrail eventually detected the abnormal behavior and warned the user—but too late. By the time the warning appeared, the malicious code had already run.This once again exposed an important difference between agent security and traditional software security.When a browser detects a dangerous download, it can display a warning and let the user decide whether to continue. When a bank detects a suspicious transaction, it can freeze the transfer before sending it for manual review.An agent, however, is designed to minimize human involvement at every step. It is expected to read information, make decisions, and proceed with the next action on its own.As AI gains more autonomy, simply “detecting danger” may no longer be enough. Security controls must be capable of stopping dangerous actions before they are executed.That is why more discussions about agent security are moving beyond prompts, content moderation, and the model itself. We should not only ask whether an AI knows that it should not perform a particular action. We must also ask whether the system can make that action impossible, even if the AI attempts it.The emergence of multi-agent systems makes this problem even more complicated. The next generation of security controls may need to constrain not just one agent, but the relationships among several agents.2. More Dangerous Than One Agent Overstepping Is Several Agents “Colluding”In early September, an incident inside OpenAI’s model training and evaluation environment attracted considerable attention from AI safety researchers.Several agents that were supposed to complete their tasks independently discovered a public wiki and gradually turned it into a shared message board. One agent could leave information there, while other agents could later read and use it to continue their own work.OpenAI subsequently confirmed the behavior. Disclosures from other training runs also showed agents using an internal Artifactory instance as a shared message board and passing results to other collaborating agents through public file-hosting services.What makes these incidents interesting is that coordination among agents does not need to look particularly dramatic.One agent discovers somewhere it can leave information. Another happens to read it. A third realizes that the information helps it complete its task.Collaboration among agents is not inherently harmful. Multi-agent systems are explicitly designed to improve efficiency through specialization and information sharing.The risk emerges when that collaboration bypasses existing information barriers, independent reviews, or permission controls—or when agents that were supposed to keep one another in check instead form a de facto alliance. At that point, normal cooperation may evolve into harmful collusion.Consider a financial institution that operates several agents simultaneously. One analyzes markets, another assesses risk, a third generates trading strategies, and a fourth has the authority to execute trades and move assets.From the perspective of traditional access control, this design appears reasonable. The research agent cannot transfer funds. The execution agent cannot independently decide what to invest in. The risk agent can reject strategies that appear excessively dangerous. Responsibilities have been separated, which should theoretically be safer than giving a single super-agent every permission.But if these agents share long-term memory, read one another’s outputs, and continually adapt their behavior based on one another’s responses, will these supposedly independent roles gradually become a single system in practice?The research agent may learn how to describe a trade in ways that are more likely to pass risk review. The review agent may develop predictable preferences based on historical data. The execution agent may then infer, from a long record of prior approvals, which boundaries are unlikely to trigger intervention.No individual step necessarily looks malicious. Yet the system’s overall behavior may already have diverged from the user’s original objective.This is what makes collusion so difficult to address. The risk may not exist in the action of any individual agent. It may instead emerge from the relationships agents form with one another.On September 13, Vitalik Buterin connected this problem with the field of mechanism design, which he has studied for many years. He suggested that adversarial governance could ultimately become an important application of mechanism-design theory in AI safety.The two problems share a deep similarity.In traditional mechanism design, a relatively simple and static institution attempts to constrain a group of participants who are far more intelligent than the institution itself and who actively search for loopholes in its rules. In future AI systems, humans and less capable AIs may similarly need to govern groups of more advanced agents.One important lesson from mechanism design is that systems are often more likely to produce desirable outcomes when collusion among participants can be effectively constrained.The same principle may apply to AI.3. Agent Wallets May Need More Than Permission ManagementInstead of assuming that a perfectly safe super-model will one day be able to detect every dangerous behavior, we can approach the problem from another direction:How can we make it structurally harder for different agents to form dangerous alliances?This is where adversarial governance differs from the access-control systems we use today.Traditional permission systems address a relatively straightforward question: who is allowed to do what?Can an agent read emails? Can it call a trading API? How much may it spend per day? Which contracts may it access? Above what threshold must the user confirm an operation again?These controls remain essential. In fact, once agents begin controlling real assets, they may become more important than ever.But adversarial governance goes one step further. It asks how a system can prevent several agents—with different permissions, objectives, and information—from combining their capabilities to obtain capabilities that no single agent was ever granted.Simply adding another “security agent” may not solve the problem.Suppose the trading agent and the agent responsible for reviewing its trades use the same model, consult the same data sources, share the same context, and optimize for similar reward signals. Although the system appears to contain two layers of review, it may simply be duplicating the same judgment.Effective checks and balances may instead require deliberate differences between agents.The agent that creates a strategy and the one that reviews it could rely on different information sources. Different roles could be restricted from sharing certain memories. High-risk operations could require independent verification mechanisms. The final asset-execution layer could accept only requests that satisfy predefined rules, rather than trusting the judgment of upstream agents.The underlying principle is not new.Banks do not allow one employee to initiate, approve, and settle the same payment. Public companies do not allow business units to generate revenue and independently audit their own financial results.A resilient system should never base its security on the assumption that participants will neither make mistakes nor collude.This principle becomes particularly important when applied to Agent Wallets.Traditional wallet security revolves around a human. The user reviews the transaction, decides whether to authorize it, and signs it personally. Agent Wallets are designed to move in the opposite direction: AI can automatically claim rewards, rebalance positions, swap assets, bridge funds, and even manage an entire portfolio in response to market conditions.If every step must be presented back to the user for confirmation, much of the value of automation disappears.The challenge for future wallets may therefore extend beyond safely delegating signing authority to an agent. They will also need to give agents enough autonomy to be useful while ensuring that they can never exceed the scope the user genuinely authorized.Authorization needs to evolve from a simple "Allow/Deny" switch into a much more granular governance framework.Such a framework may define which assets an agent can manage during a given period, which protocols it may access, and the maximum amount it can spend per transaction or in aggregate. It may determine whether different agents can call one another or share context, which agent proposes an operation, which one reviews it, and which one ultimately executes it. It must also distinguish between actions that can proceed automatically and those that require human authorization, regardless of how confident the agents may be.Even the independence of an agent responsible for security review may need to become part of the permission model.The good news is that blockchain infrastructure is particularly well suited to enforcing this institutional layer.Smart contracts can apply limits on transaction amounts, asset scope, and authorization periods directly at the execution layer. Account abstraction, multisig wallets, and session keys also provide much greater flexibility for limited delegation than traditional single-key wallets.But blockchain can solve only part of the problem. It can record what happened on-chain, yet it cannot inherently determine why an agent took a particular action—or what communication, review, and coordination occurred among several agents before the decision was made.That may be the missing security layer in the next generation of Agent Wallets.Final ThoughtsFor years, one of the most common questions in AI safety was how to make models more “obedient.”Models should not produce dangerous content, execute malicious instructions, or cross boundaries established by users. But as agents acquire long-term memory, tool access, real accounts, and the ability to execute asset transactions, making models more obedient may no longer be enough.Events over the past few months have repeatedly demonstrated this shift.Attackers are already using multiple agents to conduct parallelized operations. Agents in experimental environments have independently discovered new communication channels. And an agent with access to external tools can transform a malicious email into a real-world action before its security controls have time to intervene.Vitalik’s idea of adversarial governance offers another way to think about AI safety. Instead of assuming that every future agent will be sufficiently reliable, we can design the broader system to remain secure even when it contains highly capable agents and increasingly complex permission structures.From this perspective, the intersection of AI agents and security will inevitably remain a long-term challenge.After all, as we delegate more of our work and lives to AI, the most important question is whether we can still be certain that the powers that matter most remain within the boundaries humans deliberately set.

Once you hold ETH, what else can you do with it?A few years ago, the answer was almost disappointingly simple: move it to a cold wallet, leave it there, and wait for the next bull market.But now that Ethereum has transitioned to proof of stake and onchain lending markets have matured, ETH no longer has to sit idle. The two most common options are native staking to earn protocol rewards or depositing ETH as collateral to borrow stablecoins—unlocking liquidity without selling the underlying asset.At first glance, both approaches put idle ETH to work. But comparing only their APRs obscures their most fundamental difference:Native staking addresses how long-term holders can earn protocol rewards on assets they intend to hold. Borrowing addresses how holders can unlock liquidity and improve capital efficiency without selling.They serve two entirely different financial needs.1. Native Staking: Turning a Long Holding Period Into Productive CapitalConsider the simplest scenario.Suppose you hold 32 ETH or more and are almost certain you will not need it for the next two or three years. You have already accepted the short-term price volatility. The only remaining variable you can put to work is the time you know you will spend holding it.That is precisely what native staking does: it turns time into productive capital.Since Ethereum transitioned to proof of stake, validators have staked ETH to participate in network consensus. They perform duties such as submitting attestations and proposing blocks, receiving rewards according to protocol rules.These rewards do not come from interest paid by another borrower or from additional tokens distributed by a DeFi protocol. They come from Ethereum’s protocol-level incentives for participants who help secure and operate the network.For long-term holders, the logic of native staking is therefore straightforward: if the ETH is going to remain untouched anyway, it can participate in securing Ethereum and accumulate additional ETH during that period.Pectra made this approach even more capital-efficient. (Further reading: “As 8 Million ETH Starts Moving, Is Ethereum Staking Undergoing a Structural Shift?”)The new 0x02 compounding validator increased the maximum effective balance of a single validator from 32 ETH to 2,048 ETH. Rewards above 32 ETH can increase the effective balance in 1 ETH increments and continue generating rewards, giving native staking a more complete compounding mechanism.Native staking, however, has one clear limitation: it addresses rewards but does not directly provide liquidity.Once ETH enters the validator system, its primary role is to serve as economic security for the network. New validators must pass through the activation queue, while a full exit may also require waiting, depending on network conditions. Staked ETH therefore cannot be spent, traded, or redeployed as freely as an ordinary wallet balance. (Further reading: “Why Does Native Ethereum Staking Come With a Month-Long Queue?”)Liquid staking partially addresses this limitation. When users stake through a protocol such as Lido, for example, they receive stETH, which can still be transferred, lent, or used elsewhere in DeFi. From a structural perspective, however, this adds another protocol and token layer on top of native staking.Abstracted to its core purpose, native staking is best suited to one particular need: making a long-term ETH position productive during the time you already intend to hold it.2. Borrowing: Unlocking Purchasing Power Without Giving Up Your PositionBorrowing solves a very different problem.Suppose you remain highly bullish on ETH and have no intention of selling, but suddenly need cash—or a compelling new onchain opportunity appears.Selling spot ETH would be the simplest option, but it also means surrendering the position. If ETH subsequently enters a major rally, rebuilding that position at a reasonable cost may be difficult.DeFi lending offers another approach: keep the ETH, deposit it as collateral, and borrow the stablecoins you need through an overcollateralized loan.On a protocol such as Aave, users can supply eligible assets as collateral and borrow other assets within the applicable loan-to-value limits. The borrowed funds can then be used for payments, investments, or other liquidity needs, while the original ETH remains deposited as collateral.At this point, ETH is serving a completely different role.In native staking, ETH is productive capital that earns protocol rewards by participating in network consensus. In lending, it functions more like collateral on a balance sheet, with its primary value lying in the liquidity it allows the holder to access.Strictly speaking, borrowing does not create free additional yield.Once users borrow assets, they take on debt and must pay a variable borrowing rate. At the same time, if the price of ETH falls substantially, the position’s Health Factor will decline. Once the position reaches its liquidation threshold, part of the collateral may be sold by the protocol.Borrowers on Aave must therefore monitor their loan-to-value ratio, Liquidation Threshold, and Health Factor.If the borrowed stablecoins are used to purchase more ETH, the position goes one step further: what began as liquidity management becomes leverage. If ETH rises, the strategy magnifies returns. If ETH falls, it accelerates the deterioration of the collateral position.This marks an important risk boundary between borrowing and native staking.The primary risks of staking involve validator operations, slashing, and delays in exiting or withdrawing staked ETH.Collateralized borrowing introduces additional risks associated with debt, variable interest rates, market prices, and liquidation.For long-term holders, borrowing answers a practical question: if you do not want to sell your ETH but need access to funds, can you unlock its liquidity?Yes—but that liquidity is not free.3. One Earns From Time; the Other Unlocks LiquidityViewed from this perspective, native staking and borrowing are not absolute substitutes. In portfolio management, they are better understood as complementary tools for different needs.A core position that is unlikely to be sold for several years may naturally fit native staking. It can earn Ethereum protocol rewards without introducing external debt or market-driven liquidation risk.A more tactical allocation with a clear short-term liquidity requirement—and whose holder is willing to monitor the position—may use borrowing as a buffer that avoids selling spot ETH.Put simply, when liquidity is not needed, ETH can go to work as productive capital. When liquidity is needed, ETH can serve as collateral. The former improves yield efficiency during a long holding period; the latter improves balance-sheet capital efficiency.DeFi also offers more aggressive ways to combine the two. A user might convert ETH into stETH, use it as collateral, borrow additional funds, and build a looping position in an attempt to capture both staking rewards and leveraged returns.But the more tightly a strategy optimizes capital efficiency, the longer its chain of risks and dependencies becomes.For long-term holders, removing one layer of smart contract risk is often more valuable than adding another two percentage points of projected yield.In practice, many users avoid native staking not because they reject its economics, but because it seems too complicated.Running a validator independently remains beyond the practical reach of most users. It requires setting up hardware, configuring clients, protecting against downtime, and handling ongoing maintenance. Those operational demands remain even after Pectra. Yet handing ETH to a centralized exchange for convenience undermines the original purpose of non-custodial staking.This is the gap that mature wallet products can fill by turning complex validator operations into an accessible service.With imToken’s non-custodial native staking service, for example, users can create a dedicated validator with at least 32 ETH and choose between a compounding validator using 0x02 withdrawal credentials and an automatic withdrawal mode.Professional infrastructure providers handle hardware deployment, validator operations, and continuous monitoring, while users retain control of their private keys and the withdrawal address specified in the validator’s Withdrawal Credentials.In other words, an operational process that was once highly technical and cumbersome is condensed into a native staking experience that remains intuitive and under the user’s control.Final ThoughtsFor long-term ETH holders, this is becoming an increasingly important question.In the past, the primary decision was whether to continue holding ETH.As staking, lending, and other onchain financial tools mature, the question becomes: if you intend to hold ETH for the long term, what role should it play?Should it become a productive long-term asset that continuously earns protocol rewards, or collateral that can unlock liquidity whenever capital is needed?Answering that question may matter far more than comparing a few percentage points of APR.

Over the past few years, few sectors in crypto have generated more grand narratives than real-world assets (RWAs) and stablecoins.On one side, U.S. Treasuries, stocks, funds, and even private credit are being brought onchain, giving real-world assets programmability, composability, and global circulation. On the other, fiat currencies such as the U.S. dollar and euro are being transformed into onchain cash that can move around the clock.This narrative has been repeated for so long that it can easily feel stale. But when the recent moves by traditional financial institutions and crypto platforms are viewed together, a different picture emerges: these are no longer isolated experiments. The pieces are beginning to interlock, forming an end-to-end financial system. (Further reading: “From ‘Speculative Asset’ to ‘Next-Generation Financial Infrastructure’: Is Crypto Building a New TradFi System?”)1. The Next Phase of RWAs Is About More Than Issuing TokensThe initial vision for RWAs was straightforward: turn assets into tokens.A U.S. Treasury fund that previously existed only in a traditional brokerage account could issue its shares as tokens. Gold that once had to be traded through funds, warehouse receipts, or brokers could be represented by a digital certificate onchain.This solved the problem of representing an asset digitally. But in the real financial world, a token alone is nowhere near enough.If an onchain token merely tracks a stock, it may not grant genuine shareholder rights. If it operates outside existing regulations and trading and settlement rules, institutions may be unwilling—or unable—to use it.A functioning market must answer a long list of mundane but essential questions. Who holds the underlying shares? How are dividends distributed? Who maintains the ownership register? How are transfers recorded? And how are trades settled after execution?That is why the New York Stock Exchange’s work deserves attention.In January, the NYSE announced that it was developing a tokenized securities platform. The proposal is not simply about issuing a handful of tokens that track stock prices. Instead, it aims to give tokenized shares the same shareholder rights as traditional securities, while supporting 24/7 trading, fractional shares, instant settlement, and stablecoin-based settlement.The NYSE has since brought in Securitize and tZERO to help build out digital transfer-agent services, broker-dealer participation, securities registration, and onchain settlement infrastructure.This is fundamentally different from a crypto-native platform issuing its own tokenized version of a stock.Traditional finance is trying to determine how blockchain can become a new technical foundation for securities markets without abandoning securities law, investor rights, or existing market rules.Meanwhile, crypto platforms are moving in the opposite direction—closer to traditional finance.Major trading platforms have begun offering access to U.S. stocks, ETFs, and even options. In the past, a user might buy BTC on a crypto exchange, Nvidia shares in a brokerage account, and gold through yet another provider. Increasingly, crypto platforms are trying to bring these assets into a shared account and funding system.Bitfinex Securities, for example, recently listed five products that allow eligible investors to gain economic exposure to listed companies including Strategy and Metaplanet through tokenized securities, with trading supported in U.S. dollars, USDT, and BTC.Ultimately, the RWA race is evolving from “Who can turn an asset into a token?” to “Who can build a fully functioning onchain capital market for issuance, trading, custody, settlement, and ongoing operations?”Once the discussion reaches settlement, stablecoins naturally become the next piece of the puzzle.2. Once Assets Move Onchain, Stablecoins Become the Cash LayerOnce assets can exist and trade onchain, the next question is obvious: what money should be used to settle those trades?For a long time, stablecoins functioned primarily as fiat-denominated tokens inside crypto’s own trading economy. Most users bought USDT or USDC to trade crypto on exchanges, with the funds circulating largely within the industry.But once assets begin trading around the clock, the limitations of traditional banking systems become immediately apparent.Why do conventional securities markets close on weekends? One important reason is that the banks, custodians, clearinghouses, and funding systems behind them all operate according to their own business hours.This is where stablecoins come in.In early September, 21 financial institutions—including Goldman Sachs, Bank of America, Citi, and Deutsche Bank—announced plans to establish a joint company and launch a U.S. dollar-denominated stablecoin in the first half of 2027. The initiative may later expand to the euro and other G7 currencies.Stablecoin issuance is therefore moving beyond competition among crypto companies and into the banking system itself.Circle CEO Jeremy Allaire offered an interesting analogy for the current market, comparing today’s onchain finance and stablecoin infrastructure to the internet in 2002.The point is not simply that the stablecoin market could grow many times larger. Rather, the infrastructure appears to be approaching a threshold: the technology is maturing, regulators are becoming more receptive, and institutions are finally gaining the conditions necessary for adoption at scale.Circle's latest report makes a similar argument, describing stablecoins as entering the regulated financial system rather than continuing to operate solely as crypto products outside banking.This also explains why RWAs and stablecoins are becoming increasingly difficult to discuss separately.Suppose a U.S. stock can genuinely trade onchain 24 hours a day. Tokenizing the stock alone does not solve the limitations of traditional markets. Stablecoins provide the corresponding form of money: if the asset can move around the clock, the cash must be able to do the same.Tokenized securities can form one side of a trade, with a stablecoin cash leg on the other. Blockchain can then enable near-real-time delivery versus payment, or DvP. A securities settlement process that once required several institutions, multiple accounts, and potentially several days could be compressed into a single system.As securities, funds, bonds, and other RWAs move onchain, stablecoins could evolve from the unit of account for crypto markets into the cash layer of the entire onchain capital market.This is also why regulation matters so much.Regulation is not necessarily the opposite of stablecoin expansion. In many respects, stablecoins can enter the broader financial system only after their regulatory boundaries become sufficiently clear.3. As Stablecoins Leave Exchanges, the Last Mile Connects to the Real WorldEven after assets are tokenized, issued in compliance with regulations, and settled onchain, stablecoins still need one final capability before they can truly function as money: people must be able to spend them in the real world.Recent developments in Japan offer a useful example.In August, HashPort and Lawson conducted an in-store pilot at Lawson’s Takanawa Gateway City location in Tokyo, allowing a customer to pay with a yen-denominated stablecoin. The merchant side was connected directly to the convenience store’s existing point-of-sale system.This was no longer a Web3 event with a QR code on a table and two wallets transferring tokens to one another. It was an attempt to integrate stablecoins into an ordinary retail environment.At another Lawson location, NETSTARS completed its own proof of concept for Stablecoin Pay, testing payments with a yen-denominated stablecoin, USDC, and USDT across multiple blockchain networks through an existing POS system.Stablecoin Pay officially launched in July with a merchant fee of 0.98%. Its objective is clear: merchants should not need to understand every blockchain, wallet, or stablecoin individually. They should be able to connect through a single payment infrastructure.This may be more important than the novelty of buying coffee with stablecoins at a convenience store.Credit cards, Alipay, and transit cards did not achieve mass adoption because every convenience store understood Visa’s clearing network, QR code standards, or the interbank system.Quite the opposite. One of the defining characteristics of a mature payment network is its ability to hide the complexity underneath.Stablecoins will probably have to follow the same path before they can enter mainstream retail. Consumers should only need to choose a wallet, while merchants continue using the POS systems they already know. Payment providers can handle the blockchains, currencies, exchange rates, confirmations, compliance, and settlement in between.Blockchain may ultimately sit behind every transaction without needing to appear in front of every consumer.Something equally interesting is happening on the other side of the payment terminal. HashPort also announced Wallet MCP, which is designed to connect AI agents such as ChatGPT and Claude to wallets. With user authorization, an agent could check balances, transfer or swap assets, and pay for external services.This means the stablecoin payment networks being built today may serve more than human users.If AI agents eventually book hotels, purchase API access, procure cloud-computing resources, or manage company expenses, stablecoins—with their digitally native, globally transferable, and programmable properties—may be better suited to machine payments than traditional bank cards.A new payment network is gradually taking shape: from consumer wallets to agent wallets, from onchain tokens to convenience-store POS terminals, and from U.S. dollar stablecoins to yen-denominated stablecoins.The role of the wallet will change accordingly.In the past, wallets mainly solved the problem of securely holding and using onchain assets. In the future, they may also become the user-facing gateway between onchain financial networks and real-world commerce.This is what makes the latest collaboration between imToken and NETSTARS worth watching. On September 3, the two companies signed a memorandum of understanding to explore connecting imToken’s wallet infrastructure with Stablecoin Pay, potentially allowing stablecoins held in users’ wallets to be spent at physical merchants in Japan.The collaboration remains exploratory and does not mean a specific payment service has already launched. But its direction reflects a broader shift in the role of wallets: from connecting users to onchain assets and DApps to becoming an entry point for real-world payments.Final ThoughtsLooking back, the progression over the past few years is remarkably clear.The first question was whether real-world assets could move onchain. Then came the question of liquidity: could those assets be traded, borrowed, and lent through DeFi?Today, the discussion has become far more practical. Can traditional institutions issue assets compliantly? Can trades settle using onchain money? And can that money be spent in convenience stores—or even by AI agents?When NYSE-backed market infrastructure, Wall Street stablecoins, convenience-store POS systems, and user wallets begin to interlock, RWAs will no longer be merely about bringing real-world assets into Web3.That may be the moment when crypto’s financial infrastructure truly begins moving into the real world.The next chapter is worth watching.

If you have recently staked ETH natively, you may have noticed something confusing: your ETH has been deposited and the onchain transaction has succeeded, yet your validator has not started working. Instead, its status remains “Pending.”And it may stay that way for more than a month.As of September 16, more than 1.8 million ETH was still waiting to enter Ethereum’s active validator set, with an estimated wait of around 32 days. In July, the wait exceeded 43 days. At the queue’s peak in March, roughly 3.4 million ETH was waiting to enter, pushing the estimated delay close to 60 days.In other words, “waiting a month” is no exaggeration.But that raises several questions.Ethereum produces a new slot roughly every 12 seconds, and an ordinary transaction can be confirmed quickly. Why, then, must billions of dollars’ worth of ETH sit idle for weeks before the validator can begin earning rewards? Does that ETH earn rewards while waiting? And why can joining the validator set take more than a month when exiting may take only minutes?The answers lie in an important Ethereum mechanism that most users rarely encounter: the validator queue.1. Where Does the One-Month Wait Come From?First, it is important to clear up a common misconception: Ethereum does not require newly staked ETH to remain locked for 40 days before it can begin working.The one-month wait is a dynamic outcome, not a fixed rule.In simple terms:ETH waiting ahead of you ÷ ETH Ethereum allows to enter each day ≈ estimated waiting timeEthereum’s proof-of-stake system does not allow every new validator to join the network at once. Instead, it uses a rate-limiting mechanism called the churn limit, which controls how much stake can enter the validator set during each epoch.An epoch consists of 32 slots. With each slot lasting approximately 12 seconds, one epoch takes around 6.4 minutes, and Ethereum processes roughly 225 epochs per day.After Pectra, which included the Electra consensus-layer upgrade, Ethereum began calculating this limit primarily in terms of ETH balance rather than simply the number of validators. The current activation cap is 256 ETH per epoch. Expressed as traditional 32 ETH validators, that means no more than eight standard validators can enter approximately every 6.4 minutes.The amount of ETH that can enter each day is therefore straightforward to calculate:256 ETH × 225 epochs ≈ 57,600 ETH per dayIf approximately 1.83 million ETH is already waiting, then:1.83 million ETH ÷ 57,600 ETH ≈ 32 daysThat is where the month-long queue comes from.The estimate changes every day. If less than 57,600 ETH joins the queue each day, the backlog gradually clears, and a 40-day wait may fall to 30 days and then 20. If more than 57,600 ETH enters the queue daily, however, the backlog continues to grow.The roughly 3.4 million ETH waiting in March, with an estimated delay of almost 60 days, was an extreme example.This is therefore separate from what users normally think of as Ethereum congestion. Low gas fees and ample blockspace do not mean validators can join immediately. The bottleneck is not execution-layer transaction capacity, but an intentional speed limit on validator activation.2. Why Not Just Open the Floodgates?If a weeks-long queue prevents capital from earning staking rewards, the most obvious solution might seem simple: why not raise the limit above 256 ETH per epoch?The answer is that validators are not ordinary accounts.Once an ETH transfer is complete, it generally does not impose an ongoing burden on the entire network. An activated validator, however, becomes a long-term participant in Ethereum’s consensus system, contributing attestations, receiving committee assignments, and helping the network reach consensus.Ethereum currently has more than 900,000 active validators and over 42 million ETH staked. Every additional validator becomes part of this enormous consensus system.That is why Ethereum deliberately controls how quickly the validator set can change.EIP-7514, introduced in 2023, placed an explicit cap on the rate of validator activation. The concern was not that having more stake is inherently bad. Rather, allowing the number of validators to grow without restraint over a short period would increase consensus-state size, validator-management overhead, and network communication and processing demands.Following Pectra, Ethereum allows a single compounding validator to have an effective balance of up to 2,048 ETH. One reason for this change was to prevent large amounts of stake from having to be divided among thousands of separate 32 ETH validators, reducing the additional burden caused by continued growth in validator count.But the churn limit serves an even more fundamental purpose: it prevents the group responsible for Ethereum’s security from changing too dramatically over a short period.A proof-of-stake network depends on its current active validator set for security. If large amounts of stake could instantly enter or leave, the foundation Ethereum uses to determine who can participate in consensus—and how much economic security remains in the system—could change just as quickly.Ethereum therefore imposes a speed limit on that transition.This is why the queue is not simply a bug waiting to be fixed.From a user’s perspective, it does reduce capital efficiency. From the protocol’s perspective, however, it functions more like an intentionally installed speed bump. Ethereum would rather leave millions of ETH waiting for weeks than allow its validator set to expand or contract abruptly over a matter of days.That principle remains visible in Ethereum’s future roadmap.EIP-8061, proposed for inclusion in Glamsterdam, would significantly increase the processing capacity for exits and validator consolidations to ease potential congestion. Yet it would retain the activation cap of 256 ETH per epoch.In other words, Ethereum is considering making it easier to get out, while showing no immediate intention of opening the entrance gates completely.3. Do You Earn Rewards While Waiting? Why Are Exits So Much Faster Right Now?If your ETH has been deposited, does the month spent waiting count as staking?For protocol rewards, the answer is no.A validator begins performing duties and earning Ethereum protocol rewards only after it becomes Active. Before that point, even if the deposit transaction has succeeded and the ETH has entered the staking process, a validator that remains Pending does not earn regular validator staking rewards.This is where a long queue has the most direct impact on users.Based on a network-wide staking APR of roughly 2.6%, a 32 ETH validator waiting 40 days would miss out on approximately 0.09 ETH in potential protocol rewards.That may not seem particularly significant for one validator. But for an institution seeking to deploy tens or hundreds of thousands of ETH, the cost of leaving capital idle for 40 days quickly becomes substantial.This helps explain why Ethereum’s staking queue has recently attracted greater attention from institutions and ETH treasury companies. When comparing staking options, users have traditionally focused on differences in APR and fees. But when the queue itself may last more than a month, the question of when assets actually begin earning rewards becomes part of capital efficiency as well.There is, however, an interesting contrast.The exit queue may show a wait of only a few minutes or hours. Does that mean Ethereum lets validators leave quickly but prevents them from joining?Not exactly. Both activation and exit are subject to churn limits. The ultimate wait depends on how much stake is actually in each queue.When roughly two million ETH is waiting to enter while very little is waiting to exit, the result is like two rate-limited highways: one has a traffic jam stretching for miles, while the other is almost empty.A short exit queue also does not mean ETH will return to a wallet within minutes. After a validator exits, it must wait a fixed 256 epochs—approximately 27 hours—before becoming withdrawable. It must then wait for Ethereum’s automatic withdrawal sweep to send the funds to the designated withdrawal address, which may take several additional days.For ordinary users, this creates an important difference between staking methods that is easy to overlook.If you run your own validator or create an independent validator through a non-custodial ETH staking service such as imToken, the underlying validator must genuinely enter Ethereum’s active validator set. It must therefore pass through the protocol’s activation queue.With imToken’s non-custodial staking service, for example, the user retains control of the withdrawal credentials while a node operator runs the validator. When the interface displays “Pending,” the validator is waiting for Ethereum to activate it. Protocol rewards begin only after its status changes to “Active.”Some liquid staking pools, by contrast, already operate large numbers of active validators and issue liquid staking tokens. This allows them to abstract away part of the waiting process at the product level, so users may not directly experience a month-long period in which their validator earns no rewards.The trade-off is a different trust boundary involving smart contracts, LST liquidity, protocol governance, and asset redemption.This is another consideration that APR often obscures: the true cost of staking is not limited to fees and yield.When capital enters the staking system, when it actually begins working, when it can exit, and who controls it throughout the process are all part of the staking product.Final ThoughtsAt first glance, making millions of ETH wait at the entrance for more than a month may look remarkably inefficient.But from the perspective of the network as a whole, the rationale becomes clearer. Ordinary transactions are about executing actions as quickly as possible. Validators determine who helps maintain Ethereum consensus in the next stage.The former can keep getting faster. The latter requires restraint.The activation queue is therefore what happens when staking demand greatly exceeds the entry rate established by the protocol. A safety mechanism that normally remains invisible has become a queue long enough for everyone to see.In one sense, the longer the queue grows, the more clearly it shows that demand to join Ethereum’s validator set continues to exceed the rate the protocol is willing to accommodate.No matter how many validators are waiting outside, Ethereum will continue opening the door at its own pace—one epoch at a time.

After a relatively quiet period, OpenClaw released version 2.0 on August 30.According to the project, this was the largest update in OpenClaw’s history, incorporating more than 16,000 pull requests and touching virtually every part of the product stack, including installation, messaging, memory, skills, models, automations, browser control, native apps, plugins, and security.Yet beyond this extensive feature list, what matters more is the clearer direction behind OpenClaw 2.0: AI agents are becoming truly capable of taking action in the real world.At the same time, this evolution is creating an unavoidable trust dilemma: as agents gain greater autonomy over how tasks are completed, how can we ensure that every critical action remains within the boundaries the user actually authorized?1. The Autonomy Dilemma: Full Delegation or Approval at Every Step?Over the past year, the most significant change in AI agents has not simply been that the underlying models have become more capable.As infrastructure such as MCP, skills, plugins, browser control, and code execution has matured, agents have gained more ways to affect the external world. They can modify information, click buttons, and even control browsers directly through computer use. (Further reading: Has Agentic AI Reached an Inflection Point? When AI Learns to Act on Its Own, How Will It Redefine Web3’s Security Boundaries?)But this is precisely where the problem begins. Under today’s interaction models, authorization often falls into one of two extremes.The first is full delegation: handing an agent a private key or a long-lived session key with broad permissions and allowing it to decide what to execute.This delivers the most seamless automation experience, but it also concentrates risk. A prompt-injection attack, malicious webpage, compromised environment, or simple misunderstanding by the model could propagate through the entire execution chain and ultimately result in real-world actions. (Further reading: A Signature Is More Than a Signature: When an AI Agent Signs for You, Who’s in Control?)In a conventional internet application, the result might be an email sent to the wrong person or a file deleted by mistake. Onchain, however, an incorrect transaction is often irreversible.The other extreme is refusing to delegate at all, requiring a confirmation or signature for every operation and every subtask. This may improve security, but it also undermines the value of automation.If an agent is helping a user execute a complex DeFi strategy involving multiple steps, but the user must pick up their phone and manually approve each one, the user has merely gone from clicking every button themselves to serving as the agent’s human rubber stamp.In other words, the freedom agents need to operate efficiently is also a new source of risk.The real question is therefore not whether agents should be given authority, but whether authorization can be sufficiently granular and dynamically enforced. Traditional permission systems are largely binary: an action is either allowed or denied. The tasks handled by agents are far more nuanced.A $10 transaction is not equivalent to a $100,000 transaction. Interacting with a protocol the user regularly uses is different from granting approval to an unfamiliar contract. Executing a swap explicitly requested by the user is also fundamentally different from an agent independently deciding to bridge assets to another network.The more autonomous agents become, the less their permissions can resemble a simple on-or-off switch.What is needed is a security mechanism that lets agents operate freely within clearly defined boundaries—and automatically stops them when they attempt to cross those boundaries.2. How Do We Build a Verifiable Line of Defense for Autonomous Agents?OpenClaw has not ignored this problem.It currently provides multiple layers of permission controls. For example, plugins can pause before executing specific operations and request user approval, while host-level commands are governed by separate Exec Approvals and allowlists.Compared with granting every tool and permission to an agent upfront, this is already an important step forward. But once agents enter payment, trading, and asset-management scenarios, a more precise distinction becomes necessary: allowing an agent to use a capability is not the same as authorizing it to perform a specific action.Allowing an agent to use a browser does not mean permitting it to purchase anything from any website. Allowing it to access email does not mean authorizing it to send messages to anyone in the user’s name. Likewise, allowing an agent to access a wallet should never mean allowing it to send any amount to any address.Permission systems for the agent era may therefore need to answer two separate questions.The first concerns capability permissions: can the agent use the browser, terminal, email, or wallet?The second concerns action authorization: is the specific action the agent is about to perform something the user actually authorized?How, then, can agents remain fully automated within explicit boundaries while returning control to the user whenever those boundaries are crossed?This is the problem imToken is exploring with Sigil. Its purpose is not simply to add another conventional confirmation pop-up. Instead, Sigil seeks to establish a clearly enforceable security boundary between users and agents through verifiable signatures and fine-grained permission controls.One of its core principles is: “What you see is what you sign.”In practice, users can grant agents a predefined scope of authority, allowing low-risk actions that comply with established policies to proceed automatically. When an operation reaches a spending limit, involves an unfamiliar protocol, or crosses another critical permission boundary, execution pauses and the specific request is presented back to the user for confirmation.Crucially, the confirmation should not merely say, “The agent is about to execute a transaction. Do you approve?”Users need to see the key parameters of the operation: which asset will be used, how much will be transferred, which address, contract, or service it will interact with, and what action will ultimately be executed.A confirmation is meaningful only when what the user sees, what they authorize, and what the system ultimately executes all correspond to one another.Sigil is also designed to use mechanisms such as passkeys, biometric authentication, single-use signatures, short validity periods, and cryptographic binding between signatures and request parameters. This makes critical authorization not only understandable to the user, but also verifiable by the system.An authorization record can therefore establish more than the fact that someone clicked “Approve.” It can answer who approved the request, exactly what they approved, and whether the action ultimately executed matches what they saw.From this perspective, Sigil is not intended to make agents do less.Quite the opposite.It is designed to let agents safely do more without taking away the user’s ultimate control. (Further reading: From Blind Approval to Verifiable Signing: How Sigil Adds a Guardrail for AI Agents)3. From Managing Assets to Managing AgentsTaking a broader view, this also reflects a fundamental shift in the role of wallets.Since Ethereum’s early years, imToken has witnessed—and evolved through—two major generations of wallets: the 1.0 era of managing individual private keys, followed by the 2.0 era, in which account abstraction improved the user experience.As autonomous agents such as OpenClaw 2.0 become more widely adopted, wallets are entering a third generation. They will increasingly need to help users manage agents that can make decisions and operate continuously on their behalf.This is why the capabilities the wallet industry has developed around private-key management, digital signatures, identity authentication, and permission isolation may take on new significance in the age of AI agents.On the surface, these technologies address the question of how to securely sign an onchain transaction. At a deeper level, however, they solve a much broader problem: how to prove that an action was genuinely authorized by a specific user or entity.Today, that action might be transferring 1 ETH. In the future, it could be sending an email, modifying a file, using a digital identity, purchasing a service, or allowing an agent to execute an automated strategy continuously for a week.Not all of these actions will necessarily happen onchain. But the underlying relationship is similar: an agent is invoking a capability that belongs to the user and acting in the user’s name.Sigil’s potential significance may therefore extend beyond crypto.As OpenClaw, Hermes, and other agents running on personal devices or in the cloud become connected to email, messaging, calendars, files, browsers, terminals, and payment tools, proving that a particular action was genuinely authorized by the user will become an increasingly universal requirement.Sigil could eventually extend from onchain transactions to data access, identity use, file modification, content publishing, service purchases, and automated tasks.As a joint exploration by imToken and OpenClaw, Sigil seeks to bring imToken’s decade of experience in self-custody, wallets, and digital signatures into this new stage, as autonomous agents begin operating in real execution environments.It does not replace the agent.Nor does it replace the wallet.It stands between them.

If we trace Ethereum’s upgrades over the past several years, one theme clearly stands above the rest: scaling.Dencun introduced blobs and dramatically reduced data costs for rollups. Pectra improved validator efficiency and staking mechanics. Fusaka deployed PeerDAS to reduce the burden of data distribution. At the protocol level, nearly every effort has focused on one goal: enabling Ethereum to process more data without pushing node requirements too high.This combination has worked. Rollup data costs have fallen, the mainnet gas limit has risen steadily, and Ethereum no longer routinely confronts users with transaction fees of tens of dollars, as it did during the previous bull market.But although the road is now wider, driving on it still feels awkward:Users still need to move assets across three or four L2s, with the constant risk of withdrawing to the wrong network.A transfer may be included in a block within seconds, yet bridges and exchanges can still make users wait more than ten minutes for confirmation.Professional builders construct nearly all blocks. A sensitive transaction could potentially be excluded under off-protocol policies.Even today, a newcomer who simply wants to transfer a few hundred dollars in USDC must first understand why the wallet needs ETH, what a nonce is, and how gas works.On the surface, these problems appear to be user-experience friction. Underneath, however, they involve deeper protocol mechanisms such as confirmation rules, block construction, censorship resistance, and the account model.These are precisely the issues Ethereum is beginning to address from Glamsterdam to Hegotá—from Q4 2026 into 2027.1. Scaling Continues, but Ethereum Is Starting to Stitch L1 and L2 Back TogetherScaling is not slowing down.Glamsterdam remains heavily focused on performance. Two of its most important components are ePBS (EIP-7732) and Block-Level Access Lists, or BALs (EIP-7928).Put simply:ePBS brings the proposer–builder separation already widely used outside the protocol into Ethereum itself. It also restructures the timing of block construction and validation, creating more room for larger blocks to propagate safely in the future.BALs allow a block to provide an upfront map of the state it will access. Nodes can then prefetch the required data and potentially process non-conflicting operations in parallel, helping address storage I/O bottlenecks.Beyond scaling, however, the biggest source of frustration for most users today is not insufficient TPS. It is that there are simply too many chains.A user’s ETH may be on mainnet, the meme token they want to trade may be on Robinhood Chain, the USDC they use for payments may be on Arbitrum, and the USDC they want to deploy into a market dip may be on Base.From the Ethereum Foundation’s perspective, these rollups are all part of the Ethereum ecosystem. For users, moving between them can feel more like exchanging currencies and applying for visas.Cross-chain protocols are exploring a variety of ways to reconnect these fragmented pieces. At the protocol level, one particularly important mechanism is the Fast Confirmation Rule, or FCR.Many users assume that once a transaction is included in a block, it is final. At the consensus layer, however, a newly produced block can still be affected by a small chain reorganization. Ethereum’s full, irreversible finality currently requires two epochs, or approximately 13 minutes.This delay rarely matters for an ordinary transfer. For bridges, large settlements, and centralized exchanges, however, it is a serious constraint. To avoid reorganization risk, they often have little choice but to make users wait.FCR offers a more efficient approach. Rather than waiting more than ten minutes for full finality, it uses the attestations validators already produce and evaluates their accumulated voting weight to determine whether a block has received sufficiently strong consensus support at an earlier stage.Under normal network conditions, the Ethereum Foundation aims to make this form of strong confirmation available within approximately 15 to 30 seconds.Strong confirmation is not the same as full finality. But for bridges, cross-chain messaging systems, and other infrastructure that currently must wait for finality, it could provide an earlier confirmation signal backed by a clearly defined security model.FCR is also unusual in that it does not need to wait for a specific hard fork. It is closer to a confirmation rule that consensus clients and infrastructure providers can adopt progressively.Once L2s, bridges, and wallets begin using this signal, many cross-layer delays caused by waiting for L1 finality could fall from more than ten minutes to tens of seconds.In the future, moving an asset may involve two or more chains behind the scenes. From the user’s perspective, however, it could require only one confirmation before the funds arrive moments later.2. A Deeper Question: Who Decides Whether a Transaction Gets Included On-chain?As blocks grow larger and builders become increasingly specialized, Ethereum faces another difficult trade-off.Professional builders use sophisticated infrastructure, computation, and order flow to optimize block construction. But as a result, control over what enters most blocks can become concentrated in the hands of a small number of powerful organizations.That creates a serious risk: censorship.A builder might refuse to include an otherwise valid transaction because of regulatory pressure, commercial competition, or hostility toward a particular privacy protocol. Even if the user controls the private key and offers sufficient gas, the transaction could remain stuck outside the chain. Further reading: “Writing Censorship Resistance Into the Protocol: Who Decides Whether an Ethereum Transaction Is Included in a Block?”If a decentralized network cannot preserve permissionless access to transaction inclusion, greater throughput alone rests on a fragile foundation.This is why FOCIL—Fork-Choice Enforced Inclusion Lists, defined in EIP-7805—has become a central component of the planned Hegotá upgrade.Its basic logic is deliberately straightforward: builders can optimize blocks, but they cannot unilaterally decide whose valid transactions are allowed onchain.For each slot, the protocol selects a committee of validators. Based on the pending transactions visible in their mempools, committee members construct and broadcast inclusion lists. Builders remain free to order transactions and capture MEV, but the blocks they produce must satisfy the inclusion-list requirements.If a builder maliciously ignores those requirements, attesters will not vote for the block under the fork-choice rules, preventing it from becoming canonical.Put differently, builders can compete on their ability to construct profitable and efficient blocks. They cannot decide on behalf of the entire network who gets to use Ethereum.Once this mechanism is in place, it may also provide a foundation for another long-discussed but slow-moving part of Ethereum’s roadmap: privacy.Privacy discussions have historically focused on zero-knowledge proofs, stealth addresses, and mixing pools. But if a builder can identify a transaction calling a privacy contract and simply refuse to include it, even the most sophisticated cryptography becomes ineffective.Within Ethereum’s emerging privacy roadmap, FOCIL addresses precisely this point of vulnerability. Only when the protocol can protect the inclusion rights of valid transactions do higher-level privacy systems have room to function.More ambitious privacy proposals remain under discussion. EIP-8182, for example, proposes protocol-supported private ETH and ERC-20 transfers through a native shielded pool.The broader direction is becoming clear: privacy cannot remain a peripheral feature provided by an isolated third-party DApp. Over time, it must become part of Ethereum’s foundational infrastructure.3. The Final Step: Native Account Abstraction and Wallets Designed for HumansThe architectural changes discussed above largely operate beneath the surface. The third development, however, could directly transform the everyday wallet experience.Ethereum is finally preparing to make deeper changes to the Externally Owned Account (EOA) model it has used for more than a decade.For an ordinary internet user, Ethereum’s traditional private-key account model can be remarkably unforgiving:Lose the private key, and account access may be gone permanently.Hold thousands of dollars in stablecoins but lack 0.001 ETH for gas, and the assets may be temporarily impossible to move.A simple DeFi action may require an approval followed by a swap, with multiple signatures needed to complete a single task.Transaction nonces must be processed in strict sequence. If one transaction becomes stuck, every transaction behind it may also stall.The community has introduced several intermediate solutions over the past two upgrade cycles.ERC-4337 brought account abstraction to the application layer through smart contract wallets without changing the core protocol. Pectra then introduced EIP-7702, allowing ordinary addresses to delegate functionality to smart contract code.EIP-7702 is ultimately a bridge. One of the most important native account abstraction proposals now being considered for Hegotá is EIP-8141, formally known as Frame Transaction.A traditional Ethereum transaction effectively binds three responsibilities together:who authenticates the user, who pays for gas, and what the transaction does.EIP-8141 aims to separate these responsibilities at the protocol level through different transaction frames.Further reading: “Native Account Abstraction + the Quantum Threat: Why Was EIP-8141 Passed Over as the Headline Feature of Ethereum’s Hegotá Upgrade?”In practical terms, the model can be understood in three parts:Validation: Accounts would no longer be permanently restricted to one fixed ECDSA signing path. More flexible authentication methods, including passkeys, could become possible. Combined with biometrics such as fingerprint authentication or Face ID on mobile devices, this could make key rotation and account recovery more intuitive.Payment: Gas sponsorship could become more native. An application could pay gas for a new user, or a transaction flow could use USDC to cover the cost, reducing reliance on separate offchain relayers.Execution: Atomic batching could allow actions such as approval and swapping to be completed as one operation. Either all steps succeed together or all of them revert.EIP-8250, or Keyed Nonces for Frame Transactions, is also under discussion. If adopted, it could give accounts multiple independent nonce lanes, allowing transactions to proceed in parallel instead of forcing every action through a single sequential queue.If these capabilities become native to the protocol, wallets such as imToken could undergo a fundamental transformation.Today, wallets spend significant effort reminding users to hold enough ETH for gas, explaining why transactions are stuck, teaching them to record seed phrases, and helping them switch RPC networks across different chains.In the future, if signature schemes, gas sponsorship, permission controls, and transaction routing all become programmable, wallets could finally take on their natural role: a quiet operating layer between users and the decentralized world.Users would retain full control, just as they do today. But interacting with the wallet could feel as intuitive as scanning a payment code or unlocking a phone with a fingerprint.Final ThoughtsLooking back at Ethereum’s recent upgrade path, the direction is remarkably clear.Dencun introduced blobs. Pectra continued scaling while improving validator and account capabilities. Fusaka deployed PeerDAS to prepare Ethereum for greater data throughput. Glamsterdam will use structural changes such as ePBS and BALs to lay the groundwork for higher gas limits and parallel execution.Scaling is far from complete. But it is no longer Ethereum’s only challenge.Ethereum can now devote more attention to some of its most fundamental—and most difficult—problems. This is why the Ethereum Foundation reorganized its protocol work in 2026 around three straightforward goals:Scale, Improve UX, and Harden the L1.Ethereum has already shown the world that it can function as a global computer that never stops running.The next step is making it genuinely seamless for ordinary people to use.

After buying ETH, many people keep a close eye on its price, but rarely look back and ask a different question: has the amount of ETH they hold changed over the past year?For ETH you plan to hold long term and do not currently need to use, there is another often-overlooked source of return: staking, which allows you to accumulate more ETH while you hold.This return comes from the Ethereum network itself. Staking is Ethereum’s native mechanism for helping secure the network. Validators participate in block validation, support the network’s operation, and receive ETH rewards according to protocol rules. Through staking, your ETH can take part in this process too.Let your ETH work for Ethereum, and for you.For long-term holders, staking adds another layer of meaning to holding ETH: you can continue holding your ETH while participating in the network and accumulating rewards. By choosing a staking model that supports compounding, eligible rewards can continue to be staked, allowing accumulation to carry on over time.And participating does not mean every user has to become a node operations expert. imToken Stake brings access to both non-custodial staking and liquid staking into the wallet experience users already know, helping ETH holders with different needs find the option that works best for them.Non-Custodial StakingNon-custodial staking is designed for users who hold 32 ETH or more and want to participate in Ethereum’s native staking while avoiding the complexity of running validators themselves.With imToken Stake, users can complete the ETH staking process directly in their wallet while retaining withdrawal control. Validator deployment, operation, monitoring, and maintenance are handled by imToken together with professional node infrastructure providers.This means users do not need to prepare their own servers or configure execution-layer and consensus-layer clients. They can participate in ETH staking with a lower technical barrier, while avoiding the need to hand withdrawal control over to a third-party custodian.This is the core value of non-custodial staking:Asset control remains with the user, while validator operations are handled by professional infrastructure providers.For long-term ETH holders, this offers a more balanced way to participate. It preserves the direct connection to Ethereum’s native staking protocol, while reducing the technical and operational burden of running validators independently.Notably, imToken’s non-custodial staking now supports a compounding mode, allowing staking rewards to accumulate within the validator and be automatically restaked, further improving capital efficiency for long-term ETH staking.Why Does Non-Custodial Staking Require Professional Operations?Non-custodial staking may look like simply depositing 32 ETH, but behind it is a validator system that needs to run continuously.Validators need to stay reliably online and correctly participate in block proposals and attestations. Node clients need to be upgraded in a timely manner. The operating environment must remain stable. Key management, monitoring, alerts, and incident response all require long-term maintenance.If a validator remains offline for an extended period, it may incur inactivity penalties. If serious violations such as double signing occur, it may face slashing risk. For most users, running a validator independently is therefore not a low-barrier option.imToken Stake’s non-custodial staking is designed to hand this operational complexity over to professional infrastructure providers. Users can focus on asset allocation and staking decisions, while service providers take responsibility for validator operation and maintenance. Each side takes on the role it is better suited for.This is not simply handing ETH over to a platform. It is a way to lower the barrier to non-custodial staking through professional node services, while preserving the user’s withdrawal control.Liquid StakingFor users who care about liquidity, imToken Stake also provides access to liquid staking. Through the liquid staking service provider Lido, users can participate in staking with smaller amounts of ETH. Lido issues stETH, a liquid token representing the user’s staking position, allowing users to retain a degree of on-chain liquidity while participating in staking.The advantage of liquid staking is its lower entry threshold and greater flexibility. It is suitable for users who want to stake smaller amounts of ETH, or who want their staked assets to continue participating in DeFi.That said, liquid staking is not a native Ethereum protocol feature. It is provided by third-party protocols. Before participating, users should understand the potential smart contract, liquidity, and other risks associated with the relevant protocol.Home StakingFor users with the technical ability and a desire to participate more deeply in building the Ethereum network, home staking remains an important option.Users can refer to Ethereum’s official documentation on home staking and validator setup, prepare their own hardware, configure the network environment, run clients, and complete validator creation and maintenance themselves.This approach requires users to take responsibility for hardware, network conditions, key backup, client upgrades, uptime maintenance, and risk management. It has the highest barrier to entry, but also gives users the greatest degree of autonomy.Home staking is better suited for users who are willing to learn over the long term, maintain their own nodes, and personally participate in Ethereum’s consensus process.One Entry Point, Three PathsThere is no single right answer to ETH staking. What imToken Stake aims to provide is not just a staking entry point, but a clearer framework for choosing how to stake ETH. It helps users understand the asset control, operational responsibilities, liquidity conditions, and risk assumptions behind each option, so they can make decisions based on their own needs.Going forward, imToken Stake will continue to focus on security, autonomy, and transparency, providing more users with a clear and reliable ETH staking experience.Stake, under your control.

On the evening of September 22, a user sent an ATOM transfer.The next morning, the transaction was still marked “Pending.”The user had not lost their private key, and the wallet showed no abnormal signing activity. Yet multiple public RPC endpoints showed Cosmos Hub stalled at block height 33,086,740.No new blocks were being produced, so there was nowhere for the transaction to be included.Only after Cosmos Hub resumed block production roughly a day later did the pending ATOM transfer finally succeed.For an ordinary user, this may have been one of the clearest possible lessons in how blockchain consensus actually works.We often say that no central authority can shut down a public blockchain. The reality is more complicated. A sufficiently decentralized blockchain may have no physical “off switch” sitting in a company’s server room, but it can still stop.The Cosmos Hub halt exposed this normally invisible part of the system to everyday users.1. Why Did Cosmos Hub Suddenly Stop Producing Blocks?First, it is important to clarify a common misunderstanding: Cosmos Hub itself was not directly attacked.The incident began on Neutron.On September 22, a Neutron governance proposal titled “AIATO: AI Agent Takeover” passed. The attacker exploited chain-level governance permissions and used privileged instructions provided by the wasmd framework to reassign the administrators of application contracts associated with Astroport, Drop, and other protocols to attacker-controlled addresses.This was not a conventional code vulnerability or protocol bug.A simple analogy is that each application had its own door lock, but Neutron’s chain-level governance still held a more powerful master key. Once the attacker gained control of the governance outcome, they effectively obtained that master key. They could appoint new administrators, migrate contracts, and ultimately move the assets controlled by those contracts.Cosmos Hub became involved when some of the stolen assets were transferred across chains.According to Cosmos Labs’ incident report, the attacker moved assets to several networks before Neutron stopped operating. Approximately 1.7 million ATOM was transferred to Cosmos Hub, where the attacker began exchanging it through cross-chain liquidity.Cosmos Hub itself had not been exploited, and ordinary Hub users did not lose funds directly because of the Neutron attack.However, the stolen ATOM had already reached the Hub. To prevent the remaining funds from leaving, a group of Cosmos Hub validators began taking their nodes offline.By approximately 7:18 p.m. Singapore time on September 22, the validators that had stopped participating represented more than one-third of the network’s total voting power. Cosmos Hub could no longer reach consensus on new blocks and halted at height 33,086,740.This distinction matters.No company clicked a “Pause” button, nor did the network first conduct an onchain governance vote to stop. Cosmos Hub halted because enough validators ceased participating in consensus.What happened next is even more revealing.Approximately four hours after the halt, validators received a complete recovery plan. It proposed a one-time state change at the halted height that would move the remaining ATOM from the attacker’s address to a multisignature address managed jointly by community validators.Cosmos Labs then developed, tested, and distributed the Gaia v28.3.0 patch based on the plan accepted by validators.At the designated recovery height, the patched Gaia software would execute a single state transition, moving 1,227,121 ATOM from the attacker’s address to a 4-of-6 multisig controlled by Nansen, Keplr, Enigma, Silknodes, Kiln, and Polkachu.By early September 23, validators representing more than 67% of total voting power had confirmed that they had installed Gaia v28.3.0.Cosmos Hub coordinated its restart at 12:00 UTC that day. Approximately six minutes later, the one-time state change was executed at block height 33,086,741, and the network resumed normal block production.From halt to recovery, the sequence was clear: validators first caused the network to lose liveness. Then more than two-thirds of the voting power adopted a new state-transition rule, allowing that rule to become part of the canonical state after the restart.This leads to a deceptively simple question: if Cosmos Hub is decentralized, why can more than one-third of its voting power stop it? And why does restarting it require enough validators to accept and run the same software?The answer lies in the meaning of consensus itself.2. Consensus Does Not Mean “The Network Can Never Stop”One of the most common misunderstandings about blockchain is treating “decentralized” and “incapable of going offline” as synonyms.Consensus mechanisms actually solve a different problem: how can many independent nodes agree on transaction ordering and the state of a ledger without relying on a central bookkeeper?Different blockchains answer that question in different ways.Bitcoin’s best-known mechanism is proof of work. Miners compete to produce blocks using computational power. If two valid branches temporarily emerge, nodes continue building on the chain with the greatest accumulated proof of work.Bitcoin therefore has no explicit moment at which 67% of participants vote and a block becomes permanently finalized. Instead, it offers probabilistic finality: the more blocks that are built on top of a transaction, the more computationally expensive it becomes to reorganize that transaction out of the chain.This is why users have traditionally been advised to wait for six confirmations before treating a Bitcoin transaction as sufficiently settled. Even a miner with substantial computing power cannot simply bypass the consensus rules enforced by full nodes.That does not mean Bitcoin’s state is absolutely unchangeable under every imaginable circumstance. If the broader ecosystem adopted new client software and new consensus rules through a hard fork, a state transition that was invalid under the old rules could theoretically become valid under the new ones.The real question is who could persuade enough miners, full nodes, exchanges, wallets, and users to accept those new rules together.In practice, almost no one can.Bitcoin developers cannot unilaterally determine the network’s consensus rules, nor can miners or exchanges easily do so. The social coordination threshold is extremely high. After Binance lost 7,000 BTC in a 2019 hack, there was brief discussion of contacting major miners to reorganize the chain, but the idea went nowhere.Ethereum offers another well-known model.Since moving to proof of stake, Ethereum has used Gasper, a consensus mechanism that combines Casper FFG with the LMD-GHOST fork-choice rule.In simplified terms, one component determines which chain validators should follow, while the other allows checkpoints to achieve finality.A checkpoint must receive votes representing at least two-thirds of the total staked ETH before it can progress toward finalization. Conversely, if more than one-third of the stake fails to participate correctly for an extended period, Ethereum may temporarily stop finalizing blocks.Ethereum also includes an inactivity leak. If the network cannot finalize for long enough, the effective balances of inactive validators gradually decline, eventually allowing the participating majority to regain the two-thirds threshold and restore finality.Changing an otherwise finalized outcome would again require changes to protocol rules and client software.The 2016 DAO incident is the classic example. Through a hard fork at block 1,920,000, the Ethereum community executed what the Ethereum Foundation explicitly described as an “irregular state change,” transferring the affected ETH to a recovery contract.Not everyone accepted that decision. Some miners and community members refused to upgrade and continued maintaining the original state, ultimately creating Ethereum Classic.Cosmos Hub uses yet another model. Its CometBFT consensus is closer to a conventional Byzantine fault-tolerant (BFT) system.In simplified terms, a block requires a commit signed by more than two-thirds of the total voting power before it can be accepted.The advantage is clear finality. Once a block receives sufficient voting power and is committed, users do not need to keep waiting for additional blocks to accumulate probabilistic confidence, as they do with proof of work.The trade-off is equally direct. If validators representing one-third or more of the voting power stop providing the votes required for a commit, the remaining validators cannot reach the more-than-two-thirds threshold, no matter how hard they try.Under those conditions, the safest response is to stop producing blocks—as Cosmos Hub did during this incident.From a distributed-systems perspective, the halt was therefore not mysterious. Once validators controlling enough voting power stopped participating, the consensus protocol followed its rules: it sacrificed availability rather than confirming new blocks without sufficient agreement.This reflects two concepts that ordinary users often conflate. Safety: preventing different nodes from finalizing conflicting states. Liveness: ensuring the network can keep progressing and processing new transactions. When too few nodes participate in a BFT consensus system, temporarily losing liveness may be the price of preserving safety. Put plainly, a decentralized ledger would rather stop than allow different groups of validators to maintain conflicting versions of the truth.Seen from this perspective, many apparently unrelated incidents in public blockchain history revolve around the same question:When distributed nodes can no longer agree on the correct state, what should the network do?3. From Bitcoin to Solana: Where Are the Real Risk Boundaries of Public Blockchains?Cosmos is not the first network to expose this question.Bitcoin experienced a classic chain-split incident in 2013.Bitcoin 0.8 had switched its underlying database from Berkeley DB to LevelDB. When a block containing an unusually large number of transaction inputs appeared, version 0.8 nodes processed it normally, while some older nodes rejected it because of Berkeley DB’s lock limits.Everyone was still running Bitcoin software, but old and new clients now produced different answers to the same question: was this block valid?The network split into two chains. The version 0.8 chain temporarily held roughly 60% of the total hash power, preventing the normal proof-of-work process from quickly resolving the split on its own.Major mining pools ultimately coordinated a downgrade to version 0.7, restoring greater hash power to the chain following the older rules. The network then converged again. The incident was later documented in BIP 50.Ethereum’s 2016 DAO incident pushed the question one step further.As discussed above, the Ethereum community adopted a hard fork that executed a special state change at block 1,920,000 and transferred the affected ETH into a recovery contract.But part of the mining and user community rejected this intervention and continued following the original rules, creating the chain now known as Ethereum Classic.The DAO fork demonstrated that in an extreme event, social consensus exists alongside consensus encoded in software. If participants cannot reach sufficient agreement, one blockchain can genuinely split into two.Solana’s 2021 outage demonstrated a different failure mode.In September of that year, a flood of bot-generated transactions overwhelmed the network. Validator processes exhausted their memory and crashed, leaving the network unable to agree on the current state or confirm new blocks for approximately 17 hours. Validators then coordinated a network restart.These incidents did not have the same cause.Bitcoin’s 2013 fork occurred because different client versions began enforcing different validity rules.Solana’s 2021 outage occurred because large numbers of validators could no longer participate normally in consensus, causing the network to lose liveness.Ethereum’s DAO fork concerned whether the community should actively alter state by adopting new protocol rules.The Cosmos Hub incident added another variation. Validators first coordinated to intentionally remove enough participation for the network to lose liveness, preventing stolen assets from continuing to move. A sufficiently large share of voting power then adopted new software and a recovery state, allowing the network to reach agreement again.Rather than reducing these events to “blockchains can be switched off” or “decentralization is a lie,” it is more useful to recognize a less convenient but more accurate reality:A consensus mechanism is not a machine that can never fail. It is a decentralized set of rules defining who determines the canonical chain when disagreement occurs, how much participation is required for a state to become final, whether a network should continue or halt during a failure, and what kind of collective action can change the rules governing what happens next.This leaves ordinary users with a question more important than whether the chain should have been halted.Final ThoughtsThe crypto industry often says, “Not your keys, not your coins.”That principle remains valid. It describes control over assets: if you hold your own private key, a wallet, exchange, or other third party cannot normally sign a transfer on your behalf.But it assumes the underlying blockchain can process the signed transaction.On the day Cosmos Hub stopped producing blocks, users still held their private keys, and their assets did not disappear. Yet even a correctly signed transaction could not be processed because there was no new block to include it.The recovery process revealed something else. When a sufficient share of consensus participants accepts a new state rule, the state of a particular account can change without a transaction signed by that account’s original private key.This does not invalidate “Not your keys, not your coins.” It reminds us that sovereignty over private keys and authority over the underlying consensus are not the same thing.The same distinction applies to wallets.A wallet can ensure that users retain control of their private keys and signing authority. It can identify chain-level anomalies quickly, display transaction status accurately, maintain redundant RPC and node connections, and verify the final outcome of a transaction after the network recovers.But a wallet cannot restore consensus on behalf of a blockchain. It cannot guarantee that the underlying network will never be interrupted, nor can it guarantee that the chain’s rules and state will never change through consensus-level decisions.A mature decentralized system should therefore not pretend that nothing can ever change.Instead, it should make its imperfect boundaries as clear as possible: who can cause consensus to halt, how much voting power is required, and under what circumstances emergency intervention is permitted.True decentralization cannot guarantee that a system will never encounter a crisis.What matters is whether, when a crisis does occur, we can still determine who decided how the ledger would proceed, under which rules, and with how much consensus behind them.

If you use onchain apps, you have probably run into this: a new wallet receives stablecoins, but you cannot send them because you have no ETH for gas. You try to swap tokens on a DEX and get stuck. Or you withdraw USDC from an exchange, only to realize you forgot to set aside ETH for the next transaction.Then comes the familiar scramble to buy a little ETH or ask someone to send you enough to get started. It is one of crypto’s most reliable ways to turn away newcomers.That is why Vitalik Buterin’s recent comments on the progress of EIP-8141, or Frame Transactions, have attracted attention. If the proposal is adopted, a user could transfer assets without holding ETH in their wallet. The network fee could be shown as a USDC charge, or an app could cover it entirely.The news quickly produced an alarming claim: “If you don't need ETH to use Ethereum, what value will ETH have?”The answer is not that simple. What a user pays with and what the Ethereum protocol ultimately uses to settle transaction fees are two different things.1. What Does “Paying Gas Without ETH” Actually Mean?Consider an ordinary Ethereum transaction today.Frank has 1,000 USDC in his wallet and wants to send 100 USDC to a friend. If he has no ETH, he cannot submit the transaction.That is because, for a standard Ethereum account today, the person initiating a transaction also pays its network fee. Frank signs, Frank sends, and Frank’s ETH balance pays for gas. Those roles are effectively bundled together.EIP-8141 proposes separating them.Under the current proposal, a Frame Transaction can contain multiple frames that handle different parts of the process, including transaction verification, determining who pays gas, and execution of the user's intended action.In Frank’s case, he could still sign to confirm, “Yes, I want to send this 100 USDC.” But a separate sponsor or paymaster could provide the ETH needed to pay Ethereum’s gas fee. Frank could then pay that sponsor a small amount of USDC.Frank might see only “Send 100 USDC” and “Network fee: 0.1 USDC.” He would not need to know the ETH-denominated gas cost or prepare ETH in advance.From the protocol’s perspective, however, Ethereum has not started accepting USDC as gas. Someone else paid the network fee in ETH and settled separately with Frank in USDC.EIP-8141’s own example of paying fees with an ERC-20 token follows a similar structure: a sponsor approves and covers the gas payment, while the user transfers tokens to the sponsor as compensation.A familiar payment analogy may help. If you use a card billed in your home currency while shopping in Japan, you see a charge in your own currency, while the merchant may receive yen. That does not mean Japan has changed its settlement currency. The asset shown at the point of payment and the asset used for settlement can differ.EIP-8141 offers a similar abstraction. The user may no longer need to hold ETH personally: another account pays the ETH-denominated gas fee, then recovers the cost in USDC or another asset.That distinction sounds small, but it leads to a very different conclusion about ETH.2. Why Does Ethereum Want to Hide Gas from Users?Not having to prepare ETH yourself is not an entirely new idea.Account abstraction under ERC-4337 already allows smart accounts to use paymasters for gas sponsorship. An app can cover a user’s fee, or let the user pay the fee in stablecoins.The difference is where the machinery sits. ERC-4337 adds infrastructure outside Ethereum’s native transaction format, including UserOperations, bundlers, an EntryPoint, and paymasters. EIP-8141 aims to bring comparable flexibility more directly into the transaction structure itself.At heart, it addresses a question that should have been answered long ago: why must an ordinary user understand gas before they can send money?When you transfer money to a friend through a mainstream payment app, it does not tell you to visit another platform and buy a separate “settlement token” first.Yet that has long been normal in crypto. You need ETH on Ethereum, SOL on Solana, and BNB on BNB Chain. Move to a new L2, and your first question may again be whether your wallet has the right token to get started. An experienced user might solve the problem with a quick bridge transfer. For someone new, it can be enough to make them close the page.Frame Transactions could also address other persistent frustrations.Today, swapping a new token on a DEX often requires one transaction to approve the token and another to execute the swap. If the swap fails, the approval may remain active onchain.With frames, the preceding approval would be rolled back too, rather than being left behind as a lingering security risk.The broader possibility is that authorization, execution, fee payment, and verification no longer have to be inseparable parts of a single account’s action. They can be arranged to suit the transaction.3. Is This Good or Bad for ETH?This debate has produced two opposite predictions. One says, “If users no longer need ETH for gas, ETH loses its value.” The other says, “Lower friction will make transaction volume soar, so this must be hugely positive for ETH.”It is too early to draw either conclusion from a proposed change to Ethereum’s transaction architecture. What we can say is that EIP-8141 does not remove ETH’s role as the asset used to pay Ethereum’s underlying network fees.Users might not see ETH in the wallet UI, but the paymaster, app, or other account covering their transaction would still need to meet an ETH-denominated fee obligation. Frames do not replace the EIP-1559 fee market with a stablecoin fee market.What changes is where the demand for ETH sits.Today, a million users might each keep a little ETH in their wallets for gas. In a future with widespread sponsorship, a smaller number of paymasters, wallet providers, and apps might instead manage larger ETH balances and handle fees for those users.That does not mean every stablecoin fee paid by a user will trigger an immediate purchase of the equivalent amount of ETH on an exchange. Sponsors can hold inventory, replenish it over time, hedge their exposure, or use other treasury strategies. “Users can pay fees in stablecoins” does not, by itself, tell us how much new demand for ETH will appear.The decisive question is whether a better experience leads to more genuine use of Ethereum.Imagine that 100 people want to make an onchain transaction. Today, 70 give up while trying to buy ETH for gas, calculate fees, or bridge funds, and only 30 complete it.If a wallet handles that complexity in the background and 80 people complete their transactions instead, Ethereum could see more activity—and more ETH paid as fees, including the portion burned under EIP-1559—even if those users never hold ETH themselves.Conversely, if the change brings no additional activity and merely replaces “pay your own fee” with “have someone else pay it for you,” it does not create new value on its own.Final ThoughtsIn my view, EIP-8141 weakens the requirement that every user must keep a small amount of ETH on hand before using Ethereum. Its promise is that removing this hurdle could help more people actually use the network.Ordinary users do not need to change their habits because of a proposal that has not yet been adopted. But for wallets, the direction is clear.A good wallet should increasingly let users focus on where their assets are going and what they want to do. It should explain the risks and the final cost. Which account pays the network fee, whether the user is charged in ETH or a stablecoin, and whether a gas sponsor is available are details the wallet should handle in the background whenever it can.That is often what mature infrastructure looks like.