蟹大的加密之旅

#dusk $DUSK In these past two days, $DUSK has been rising pretty lively, but the more I watch the order book, the more I feel something is off about this move: volume is up, but that doesn’t mean liquidity has truly improved.

Right now, DUSK is around $0.0695, up nearly 11% over the past 24 hours. Trading volume is about $4.45 million, roughly 40%+ higher than the day before. Just looking at these numbers, it’s easy to think, “Money is coming in.” And with the recent CreatorPad reward campaign layered on top, it’s also normal for attention to pick up in the short term.

But I don’t buy that. I prefer to look directly at the order book.

On CoinGecko, for DUSK/USDT on Binance, the 24-hour trading volume is about $810,000. The issue is that the current +2% depth is only about $15.9k, and the -2% depth is just $30.5k. The spread is around 0.14%. This is the part I actually care about: being able to print tens or even hundreds of millions in one day doesn’t mean you can really put in a few tens of thousands of dollars and still get a comfortable fill.

When the market is slow, this doesn’t feel as obvious. But once something like @Dusk happens—an activity ends, the market suddenly weakens, or a large number of stop-losses get dumped all at once—the problems with a thin order book get amplified immediately. What you may be seeing are just “a few percentage points up or down,” but what you’re truly getting is slippage, wick-ins, cancellations that don’t happen in time, and sometimes even the stop-loss execution price isn’t at all what you thought it would be.

So even though DUSK is up this round, I won’t treat volume as proof that liquidity has improved. What actually changes my mind is seeing the order book depth increase consistently over weeks—not propped up by one single event pumping the trading volume.

Volume can be manufactured by hype; it’s harder to fake depth.

That’s also my biggest question about DUSK right now: once the heat comes, does what’s left behind are real traders—or just a pretty 24h Volume number?

#dusk $DUSK @Dusk

#dusk $DUSK If you blur out those big phrases like “regulated onchain finance” on the official website first, and only let an ordinary user use Dusk, I think the problem becomes even more obvious: in the first step, exactly what should you click?

@Dusk Actually, the underlying layer is no longer in the “can’t be used” stage. The mainnet is Live, and the data on the official site shows that 210+ million DUSK are participating in staking, with a deterministic finality of about 10 seconds. The issue is that whether the underlying is running smoothly and whether users feel it’s easy to use are two completely different things.

In April, the official specifically released Dusk Connect and a new version of the Dusk Wallet—which in itself says a lot. The official admitted that the original Web Wallet was more like a standalone app, and that a dApp can’t discover the wallet, request accounts, and sign transactions the way people are used to with EVM wallets. The new version really does add browser extension, desktop, and mobile support, along with public/private transfers, shield/unshield, staking, claim rewards, and other functions—but at the time, the official positioning for it was still “developer preview.”

This is my biggest product doubt about Dusk right now: there’s more and more technical capability, but do ordinary users really know when to do a public transfer and when to shield? After assets move across environments, where do you go to view them? If something fails, do you retry immediately, wait, or contact support?

This isn’t nitpicking. In January, the bridge service was paused because the signing wallet was compromised. In the follow-up postmortem, the official even broke transaction status down into seen, submitted, completed, failed, stuck—showing that whether users can understand what’s happening after something goes wrong is itself part of product safety.

More realistically, right now, Dusk Trade on the official site is still “Building,” and DuskEVM and Hedger are still in Testnet.

So I actually feel that the next phase for Dusk should probably not be about adding yet another technical buzzword, but about turning “can a first-time visitor successfully complete one full operation within ten minutes” into a hard metric.

Enterprise-grade infrastructure can be complex, but the user interface can’t expect users to become semi-developers first.

#dusk $DUSK @Dusk

My biggest question about @Dusk right now isn’t whether the technology can be made—it’s: when will ordinary users be able to truly use it without “having to read the documentation”?

Dusk’s official site is already talking very far ahead: €300 million+ confirmed issuance scale, 50,000+ investor coverage, 210 million+ DUSK participating in staking, and final determinism in about 10 seconds. But on the other side, Dusk Trade is still marked as Building, and DuskEVM and Hedger are still on Testnet. In the new Dusk Wallet released in April, the official positioning at the time was still only a developer preview. The narrative and data have moved into “institution-grade financial infrastructure,” yet the actual product layer users can touch is still in catch-up mode. I think we can’t ignore that gap.

Especially after the Bridge incident in January, I care even more about “what to do if something goes wrong.” At the time, the signing wallet was compromised. In the official March post-incident review, it revealed that during the attack there were abnormal transfers of millions of DUSK. The last cross-bridge attempt of 8.91 million DUSK failed only after the service was shut down. Later, the bridging system specifically added a set of transaction states—seen, submitted, completed, failed, stuck. In essence, it’s solving one thing: don’t leave users staring at a transaction that’s stuck with only guessing.

This is also what I hope Dusk will add in its next phase. Privacy, compliance, ZK, institutional assets—ordinary users might not understand these on day one. But “Where am I in the process right now,” “Why did it fail,” “Has the money gone out,” and “Who should I go to for the next step”—these must be immediately clear.

In the end, financial infrastructure isn’t only about on-chain finality; it’s also about certainty when users encounter anomalies. The technology can be complex, but you can’t leave that complexity to the user.

#dusk $DUSK @Dusk

Research From @Dusk to today, I’ve become more and more concerned about a very practical question: for DUSK, is the demand truly “someone is using it for real,” or is everyone just locking up their coins for now and calling it demand?

Recently, Dusk has been getting more and more specific about its RWA track. The numbers shown on the official website are now: over €300 million in confirmed issuance, 50,000+ investor reach, and already more than 210 million DUSK tokens participating in staking. Looking at these figures alone, it definitely seems like there’s more substance than simply talking about a “privacy chain.”

But from a token-economics perspective, I think there’s a contradiction here.

Right now, DUSK’s two most clearly defined uses are Gas and Staking. The problem is: staking addresses security needs, but it doesn’t equal the creation of new external buy-side demand. Also, the official token issuance model is an initial 500 million tokens, and then releasing another 500 million over 36 years—where the planned release for the first four years alone is about 250.48 million. The block rewards that validators receive also inherently include newly issued tokens.

So what I really want to look at isn’t “how many tokens are staked,” but rather: the actual fees generated by real on-chain transactions—when will they start covering an ever-growing portion of the security budget?

Especially on August 15, @Dusk just published a new article about SME Tokenization. The path through NPEX, Dusk Trade, and regulated securities is indeed becoming clearer and clearer. But there’s one thing to pay attention to: issuing €300 million worth of assets on Dusk doesn’t mean there will be €300 million worth of DUSK demand in the same amount.

Between asset size, transaction frequency, Gas consumption, and the final flow back to DUSK holders, there are multiple layers.

That’s the data I want to track most right now.

If, in the future, Dusk Trade truly gets going and real assets continue to be traded—then as fee revenue begins to rise noticeably, DUSK’s economic model would look much more compelling than it does today. But until then, I won’t automatically equate “210 million tokens staked” with strong demand.

Locking tokens can reduce circulating supply; only usage can prove the value flows back.

#dusk $DUSK @Dusk

I’m looking at the ecosystem around @Dusk right now, and the question I most want to ask is no longer “Who else is collaborating?” but rather: what exactly have these collaborations left on-chain?

The latest website has listed NPEX, Chainlink, 21X, Cordial Systems, and Quantoz on its partnership map, and even provided €300M+ in confirmed issuance and 50K+ investor reach. The overall picture really is starting to look more like a legitimate financial infrastructure project.

But there’s a key question that’s easy to overlook: a partner’s data doesn’t necessarily mean the data that Dusk has already obtained.

For example, NPEX has raised over €200M in the past, serves 100+ SMEs, and has 17,500+ active investors—this shows that NPEX itself has real business. But how many of those users have already become Dusk users? How much asset has actually moved onto the chain? How much ongoing trading and liquidity has this generated? So far, the official materials have not provided equally clear conversion metrics.

Even more importantly, Dusk Trade is still labeled “Building,” while DuskEVM and Hedger are still on testnet. The deeper DuskEVM integration that 21X mentioned earlier was also something that was planned from the start.

So I think what Dusk lacks most right now isn’t the next cooperation poster, but a “partnership conversion table”: how many assets and real users have come in, how many trades were actually generated, and how much liquidity has been left behind.

On August 15th, the official just talked again about how tokenization can open up the SME private placement market—this direction I agree with. But once the story gets to this point, the ecosystem should start speaking with results.

An ever-longer list of partners is certainly a good thing. But if, in the long run, it can only prove that “the entry exists” without proving that “the money truly came in,” then ecosystem prosperity and ecosystem expectations are two different things.

#dusk $DUSK @Dusk
#dusk $DUSK

#dusk $DUSK Today I watched DUSK’s chart for a while, and I’m more and more concerned about one question: @Dusk talks about RWA and putting institutional assets on-chain, but $DUSK ’s current trading depth—are you really prepared to handle a volume of this scale?

As of today, the DUSK price is around $0.061, with a market cap of roughly $30.5 million. Total trading volume over the past 24 hours is only about $2.8 million. Taken by itself, this number doesn’t necessarily mean nobody is trading—but if you place it in the context of high-frequency trading, what I care about most is what happens after orders are actually executed.

Especially on July 10th, Bitget directly delisted the DUSK/USDT spot trading pair. The official statement didn’t separately say “it’s because liquidity is poor,” but in the delisting review criteria it clearly lists trading volume and liquidity at the top. Meanwhile, related services for DUSK—like bots, copy-trading, Earn, and so on—were removed as well.

I think this is more worth watching than a price drop of a few percentage points.

Because @Dusk is already discussing NPEX, Quantoz, Chainlink within the official ecosystem—clearly the direction is regulated assets, stablecoins, and RWA. But what institutional capital fears most is not exactly “there’s no story.” It’s that there is a price, but no depth: you can place orders, but you can’t get out.

Small-cap market orders might not feel the difference, but once positions are scaled up, order book thickness, slippage, and how fast you can cancel orders are the real costs. In extreme market conditions, if you layer on leverage, after a few sell walls get eaten, the few points you see on the candlesticks might be an entirely different story in terms of actual fills.

What’s even more interesting is that in August there’s an OpenDusk governance vote catalyst—whether to redirect originally destroyed block rewards toward the community treasury. I’m not against ecosystem incentives, but I’ll ask one thing: if the new incentives ultimately mainly bring short-term trading volume, and there’s no long-term market-making capital and real buy/sell depth, will the depth just go back again after the hype cools off?

For traders, my current judgment about whether DUSK has truly entered the next stage isn’t about how bullish people feel. It comes down to three things: whether the order books on major exchanges have gotten thicker, whether slippage for large orders has decreased, and whether depth can hold up in extreme market conditions.

RWA can be talked about slowly, but liquidity is a daily assignment—the order book is doing homework every day.

#dusk $DUSK @Dusk

#dusk $DUSK Over the past couple of days, I’ve been continuing to actually look at it @Dusk, and I’m increasingly feeling that DuskEVM has something that’s rather awkward about it. It keeps emphasizing a “familiar EVM experience,” but when it’s time for ordinary users to move assets back from DuskEVM to Dusk L1, the process is anything but “familiar.”

Right now, in the official documentation, DuskEVM is still Testnet. Withdrawals require you to complete 3 on-chain actions in a row: first initiate the withdrawal on DuskEVM, then wait until the status becomes “Ready to prove,” after which you submit the proof to Dusk L1. Next, you have to keep waiting until it reaches “Ready to finalize,” and only then confirm the transaction once more—so the assets truly return. Also, both the proof and the finalize steps require additional Dusk L1 fees.

What concerns me most is this “waiting” in the middle. Even the official docs say so: when withdrawals can continue depends on the network state, proof maturity, and dispute-game checks. You can’t judge it by time—you can only watch the status in the Web Wallet. If you switch browsers or the records are gone, you’ll need to keep the transaction hash yourself and look it up again.

Technically, of course, these steps have their reasons, but ordinary users simply don’t want to research things like output proposals, proof submitted, or waiting to finalize. Especially since Dusk had a bridge-related security incident just in January this year. At the time, the official paused bridge services and replaced the relevant addresses. Even though the announcement stated there was no loss of user funds, that incident actually underscores the point: for a cross-chain product, the most important thing isn’t just whether it can run. After something goes wrong, users must know where they’re stuck and what to do next.

So my biggest question about DuskEVM right now isn’t whether the technology can be made to work—it’s whether, once it’s truly live on mainnet, @Dusk will fully hide these underlying states behind the product layer. It can be complex for regulated markets, but for end users, the buttons should ideally not be complex. Otherwise, even if the on-chain settlement is done beautifully, the first time a user’s withdrawal gets stuck for ten minutes, what they’ll be thinking isn’t “nice engineering,” but just: where did my money actually go?

#dusk $DUSK @Dusk

#dusk $DUSK When I went through the materials for @Dusk , the thing that really stumped me wasn’t its privacy technology—it was the line it kept emphasizing: providing infrastructure for “regulated finance, institutional-grade applications.”

That goal is huge, so I’m more concerned about one question instead: **When does Dusk truly count as reaching “institution-grade”?**

When the mainnet launched in January 2025, the official message was already clear: developers, come build on Dusk. But by April 2026, it was Dusk Connect and the new Wallet that finally entered developer preview. Even the official acknowledged that, before that, the Web Wallet was essentially a standalone app—dApps couldn’t directly complete wallet discovery, account requests, and signing. These gaps were even described as “missing front-end pieces” for Dusk applications.

That’s a bit awkward.

The mainnet has been running for more than a year, and the institutional story has been told for a long time. But when developers actually want to deliver applications to users, some very basic connection layers are still being filled in.

Even more concerning is the boundary of permissions.

In January this year, the signing wallet of Dusk Bridge was taken down. The attacker then moved roughly **10.91 million DUSK**. The official explanation afterward was very clear: it wasn’t a consensus-layer vulnerability. Instead, the bridge’s wallet keys were compromised, and at the time, for speed and operational simplicity, the bridge used a relatively lightweight design.

Then the AEGIS security remediation fixed 39 issues at once, including 7 Critical and 1 related High.

So my question about Dusk is actually very simple:

If, in the future, it really needs to carry securities, RWA, and regulated assets, then “protocol security” alone clearly isn’t enough. Bridges, wallets, permissions, keys, and the front-end connection layer—if any one part involves centralized trust, it could become the real upper limit of risk for the entire system.

I agree with the technical roadmap. But those words—“institution-grade financial infrastructure”—I think @Dusk still needs to keep proving it.

#dusk $DUSK @Dusk

I re-read the @BabylonLabs_io website and Explorer today, and there’s a detail that makes me pretty uneasy.

On August 3rd, the website’s homepage shows that 56,853.16 BTC has already been staked, worth about $5.64 billion. That’s a significant amount, but when you click into the official Explorer, the BABY Price shows as $0(-), and key data such as block height, total transactions, and total delegated amount also aren’t displayed properly.

What’s more worrying is that on the Finality Provider page, active nodes, delegated amount, and the number of stakers are also blank.

This isn’t just a question of whether the pages look good.

If I’ve just finished staking and the transaction hasn’t updated for a long time, how am I supposed to figure out what’s going on? Is BTC still being confirmed, did the wallet operation fail, is Babylon’s indexer delayed, or did the delegation simply not succeed at all?

When choosing a Finality Provider, users can’t even see real-time status or the delegation distribution—so how are they supposed to judge whether a node is stable or whether delegations are overly concentrated?

Babylon has always emphasized native BTC, self-custody, and no cross-bridge, but keeping assets in your own wallet doesn’t necessarily mean you can feel reassured that the entire process is sound.

What truly affects trust usually isn’t the technical jargon on the marketing page, but whether—once the money goes in—you can verify what happened, whether you can find the cause if something goes wrong, and whether there’s a clear way to get help when things get stuck.

For a protocol that is carrying over $5.6 billion in assets, the website’s data may look beautiful, but the Explorer responsible for verifying those data shouldn’t be something users have to guess at for the long term.

Whether the product is mature shouldn’t ultimately be judged by how big the slogans are, but by whether these most basic things are actually reliable.

#baby $BABY @BabylonLabs_io

After 99 projects go under, who’s still paying for security?

This year, 99 crypto projects have already stopped operating.

When I saw this news, my first reaction wasn’t about how many narratives the market has filtered out again—it was that many projects never addressed the most basic problem from the start: when token prices fall, subsidies decline, and validators leave, who continues to pay for the network’s security?

A new PoS chain can attract staking with high APY, or generate activity through airdrops. But if the security budget is entirely built on its own token, its defense will fluctuate with the token price. The lower the market cap, the cheaper the attack. Continuing to mint to keep validators running would further dilute the token’s value.

That’s also why I’ve kept researching Babylon. It tries to bring native BTC into the security supply side, so that PoS chains, Rollups, and app chains don’t have to rely only on their own tokens to build an economic defense. BTC holders lock funds on the Bitcoin network—no wrapping or cross-chain needed—and provide guarantees to external networks through a punishable mechanism.

But I won’t assume the pattern holds just because the staking scale grows. With BTC involved on the supply side, it only indicates that yield demand exists. What truly determines whether Babylon can operate long-term is whether the networks being secured are willing to continuously pay real costs.

Only if people still buy BTC security after subsidies dry up can Babylon move from a staking protocol toward becoming security infrastructure.

#baby $BABY @BabylonLabs_io

More than 2.5 million ETH are waiting to enter the staking queue.

What the market sees is a rebound in staking demand, but I’m more focused on the signal behind it: as more and more capital is willing to lock up assets to help secure the network, blockchain security itself is becoming a business that can be priced.

Ethereum uses ETH to secure its own network, and Babylon wants to expand this logic further—so that BTC can not only secure Bitcoin, but also become external security capital that can be called upon by PoS chains, rollups, and application chains.

This is also what I think makes Babylon easy to undervalue. On the surface, it offers a BTC staking gateway; in essence, it is building a security supply-and-demand marketplace. BTC holders provide economic collateral, access to the network raises the cost of attack, and Babylon connects both sides and enforces the punishment and exit rules.

But from an investment research perspective, staking volume isn’t the only answer. Even if the supply side locks in more BTC, if there aren’t enough networks that are willing to continuously pay for security, growth may still rely on token subsidies. What’s truly worth tracking is the number of networks onboarded, actual security spending, protocol revenue, and whether these revenues can gradually support returns for BTC stakers.

ETH staking queueing indicates that capital is willing to lock up for the long term for network security. What Babylon needs to prove next is whether Bitcoin’s economic security can be transformed—from an asset characteristic into an infrastructure service that other blockchains are willing to continuously buy.

If the answer holds, Babylon’s competition won’t just be the BTCFi yield market, but the security budgets of the entire on-chain world.

#baby $BABY @BabylonLabs_io

The first time I saw Babylon’s staking model, I didn’t immediately understand it as a yield product. What truly attracted me was that it is trying to create a new market: enabling other networks to directly purchase the economic security provided by Bitcoin.

In the past, when a new chain wanted to launch, it would usually need to issue its own token, recruit validators, and then build a security budget through high incentives. The problem is that many projects’ token consensus and liquidity are not strong enough to sustain long-term security. Once subsidies decline, validators leave, attack costs drop, and network security weakens rapidly.

Babylon offers another way of thinking. BTC holders can lock native BTC to provide slashable security for PoS chains, rollups, or other systems; the networks that connect then secure the service by paying rewards, gaining stronger economic backing than their own tokens can provide. To me, this feels more like building a decentralized security capital market than simply turning BTC into another staking asset.

But whether this model ultimately works depends less on how much BTC is locked and more on the demand side. Whether networks that connect to Babylon are truly willing to keep paying, and whether the security they gain can translate into more users, capital, and protocol revenue—this determines whether the whole system can operate without relying on subsidies.

I will also keep observing the role $BABY plays in it. If it only handles reward distribution, sell pressure may persist long term. If Gas, governance, validation, and ecosystem settlement demand grow in tandem, the token may be able to form more stable value capture.

Babylon’s ceiling is not to add another BTC staking entry point, but to make Bitcoin’s security consensus a form of public capital that the entire on-chain world can access.

#baby $BABY @BabylonLabs_io

After re-examining Babylon, what interests me most is no longer just Bitcoin Staking, but the Trustless Bitcoin Vaults it is enabling. For a long time, although BTC has the strongest consensus among crypto assets, it has been difficult to directly access lending, stablecoins, and institutional credit markets. Users typically rely on WBTC, cross-chain bridges, or centralized custodians to convert native BTC into another on-chain representation. Once that conversion is completed, the risk shifts away from Bitcoin itself and onto custodians, bridges, and smart contracts.

Babylon aims to solve a more fundamental problem: BTC does not leave the Bitcoin mainnet, while external protocols can still verify whether it exists, whether it is locked, whether the collateralization ratio is healthy, and when it should be liquidated. If this direction becomes real, lending protocols like Aave will no longer be dealing with some wrapped BTC, but with a collateral infrastructure capable of reading the state of native BTC. For me, this is the key shift that takes BTCFi from “generating yield-bearing tokens” to “building native financial rails.”

I believe this is more important than simply increasing BTC’s yield. It means BTC can evolve from a passive store-of-value asset into productive capital that can participate in lending, financing, and asset-liability management. Miners, long-term holders, and institutional capital may also gain new liquidity without giving up control of their assets. If this path holds, BTC’s financial efficiency will improve, and the market won’t have to keep concentrating core credit in the hands of a few wrapped-asset issuers.

That said, technical validation is not the same as a complete business loop. State proofs, oracles, liquidation delays, and execution efficiency under extreme market conditions will all determine whether the product can support real funds. Going forward, I’m more focused on Babylon’s actual deployment with Aave and Ledger, and whether BTCVaults can generate stable fees. If these pieces work, Babylon may become not just a BTCFi protocol, but an important native Bitcoin interface for on-chain finance.

#baby $BABY @BabylonLabs_io

哈哈哈哈

When I first got into Web3, I thought the biggest advantage of blockchain was its simplicity.

There were no complicated processes, no intermediaries—one wallet could participate in global finance.

But later, more and more traditional assets started trying to come on-chain, and I realized a problem became increasingly obvious:

Blockchain can reduce transaction costs, but it doesn’t naturally inherit the operating rules of traditional finance.

The reason real-world finance can support large-scale capital isn’t just because there are assets, but because there’s a complete rule system behind them.

Who can buy, who can sell, what the limits are, and under what circumstances operations are paused—these are the foundational elements accumulated over years in financial systems.

In the past, the on-chain world has mostly focused on “how assets are transferred,” and hasn’t yet built sufficiently robust infrastructure for “how assets should be managed.”

That’s what makes Newton Protocol so interesting to me.

The Authorization Layer it attempts to build, in essence, adds rule-execution capability to the blockchain.

With a Policy Framework, developers can convert conditions across different scenarios into executable logic, so applications don’t just complete transactions, but run according to predefined rules.

I think the importance of this direction lies in how it connects two worlds.

The on-chain world provides openness and efficiency.

Traditional finance provides rules and order.

True large-scale adoption in the future won’t just mean moving assets onto the blockchain—it will mean letting the logic of real-world finance run naturally in an on-chain environment.

Newton isn’t the answer to all problems, but it enters an unavoidable direction.

Because as more and more capital, assets, and applications move on-chain, rules won’t disappear—they’ll only exist in a different form.

The long-term value of $NEWT depends on whether it can be adopted by more protocols and applications.

If, in the future, on-chain finance needs a universal rules-execution layer, the direction Newton is exploring may become an important part of it.

@NewtonProtocol $NEWT #Newt

After working on projects for a long time, I find myself increasingly less drawn to those particularly grand stories.

Because the market is always full of beautiful narratives; what’s truly scarce is a team that can break down complex problems and solve them step by step.

Newton Protocol is one of the projects I’ve been willing to keep observing lately.

The reason isn’t that it talks about the future for how long; it’s because the problem it tackles is quite fundamental.

As the on-chain world develops, its complexity is essentially always increasing. From simple transactions to financial protocols, and then to automated applications—the systems become more powerful, but at the same time they also increasingly need new ways to coordinate.

What Newton wants to do is to ensure that these complex behaviors can run according to clear rules.

From the Authorization Layer to the Policy Framework, and then to Verifiable Automation, its core logic isn’t to create a brand-new application, but to provide a set of foundational capabilities that make application execution more standardized.

I think the biggest characteristic of infrastructure projects is that in the short term they often aren’t particularly exciting.

Because unlike consumer apps, you can’t directly see user growth. But once they become a foundational component in the ecosystem, value keeps accumulating as usage scales.

Of course, from an investment perspective, caution is always necessary.

A correct technical direction doesn’t guarantee success; an excellent whitepaper still needs ecosystem adoption to prove it.

So when I observe $NEWT , what I care more about are a few long-term indicators: whether there is real application integration, whether developers keep using it, and whether the network has formed genuine demand.

Every day the market has new hot topics, but opportunities that are truly worth attention are often hidden in projects that solve long-term problems.

How far Newton can go still needs to be validated by time, but the problems it’s exploring are indeed directions that you can’t get around in on-chain development.

@NewtonProtocol $NEWT #Newt

I had a question for a while after watching some automation strategies run: if a system helps you complete a large number of tasks every day, what is it that you truly need to focus on?

Many people’s first reaction might be efficiency.

Faster trading, more executions, and lower labor costs.

But as the size of capital grows, the truly important problem shifts in another direction: does this process actually run according to the logic that was set?

That’s also why I find Newton Protocol’s design approach interesting.

It doesn’t put the emphasis on “having machines do more for people,” but instead focuses on a commonly overlooked issue in automation—how the execution process can be verified.

In essence, “Verifiable Automation” in the Newton whitepaper adds a verifiable mechanism to automation systems.

Many past on-chain automation solutions are more like execution scripts: the system receives a task, carries out the actions, and the user ultimately sees the results. But what happens in between, why the actions are carried out this way, whether they meet the original conditions—often this isn’t transparent.

Newton’s idea is to change this flow.

With the Operator Network, task execution no longer depends on a single executor; instead, coordination and verification are carried out by participants across the network. At the same time, TEE and ZK technologies handle the execution environment and proof-related issues, enabling the system to prove that certain behaviors meet predefined conditions.

The most critical point for me here is that Newton isn’t merely improving automation efficiency—it’s redefining what capabilities an automation system should have.

A truly mature automation network shouldn’t just “be able to execute,” it should also “be able to explain its execution.”

In a way, this is similar to traditional financial systems.

Large-scale asset management doesn’t only care about final returns; it also focuses on process records, execution rationale, and the paths of responsibility. If on-chain automation is to support more complex financial behavior in the future, it will likewise need this kind of verifiable foundation.

As for $NEWT , I’m especially interested in whether it can become a foundational component in the automation ecosystem.

Because in the future, the on-chain world won’t be short of automation tools. What may truly be scarce is an underlying system that can make automated actions verifiable, trustworthy, and widely adopted.

@NewtonProtocol $NEWT #Newt