What is Quai (and QI)? A 30-second recap

Last month I wrote and published a full research article on the Quai Network and its dual-token system (QUAI & QI). It’s a very interesting tech stack and, as I said then, it’s one of the most serious attempts I’ve seen to keep Proof-of-Work relevant at scale.

Instead of the binary “longest chain” race of classic Bitcoin, its consensus, Proof-of-Entropy-Minima (PoEM), ranks blocks by how much entropy they remove from the system. On top sits a hierarchical sharding structure that can make the network scale as demand grows. Moreover, Quai hs built-in merged mining (SHA-256, Scrypt, KawPoW) properties plus SOAP to keep energy-based security competitive and shared with larger networks.

If any of that is new for you, stop here and read my full deep-dive first — Quai Network: Entropy, Energy Cash, and Scalability — because I’m not going to re-explain the architecture here. This piece is intended to be the practical follow-up: how you get a wallet, use QUAI/QI, and mine it.

The one thing you do need to know before we keep going: Quai runs on two native tokens.

• QUAI — account-based, EVM-compatible. Think “digital gold + smart-contract fuel.” Programmable, scarce.

• QI — UTXO-based, fixed-denomination “energy cash.” It tracks the real energy cost of producing it, with cash-like privacy (non-address-reuse, payment codes, fixed “bills”).

You can hold one or both, and you can also convert between them on-chain. Let’s get you set up now.

This article is sponsored by Dominant Strategies (Quai Network’s core team). Their support made it possible for me to spend the time researching, understanding, writing, and editing this piece. The content remains fully authentic and didn’t suffer any direct influence from the team, who respected its independent creation.

Quickstart: Using QUAI/QI

The first angle we will cover in this guide is from a user perspective. This is because all miners are, essentially, users; while not all users are miners.

1. Set up a wallet

If you are used to crypto you know this is the critical first step. If not, not worries, I got you covered!

In my research I found two core wallets for interacting with Quai and QI: Blip (Blippay) and Pelagus.

Blip (or Blippay) is a mobile wallet for Android and iPhone users. It has a beautiful layout, quick setup, smooth user experience, and native integration to Quai DApps. However, it’s not open-source, which is a relevant property for a crypto wallet, in my opinion. On a positive note, its latest upgrade added raw ETH wallet support and seamless bridging/swapping between QUAI, ETH, USDT, and WQI. Interoperability is key.

Install Blip on Android

Pelagus is a browser extension built specifically for the network (community-owned, open-source). It’s what I first used to test QUAI and QI. You install it from the Chrome Web Store, click “create a new wallet,” and set a password.

Install Pelagus on Chrome

Important note: I recommend following the links in the @QuaiNetwork official account’s bio on X for security reasons. This can help protecting you from phishing attempts. Bookmark it, then.

After picking your wallet of choice and installing it, the most important part is the seed phrase: a recovery phrase of random words that controls every address your wallet derives.

Write it down on paper (offline), keep it somewhere safe and separate from your computer, and never share it or type it anywhere. Both Blip and Pelagus will show you how to back up and verify your phrase.

Other wallets exist (including exchange addresses, a MetaMask snap, Tangem support, and more), but for holding small amounts and interacting with the Quai Network as a user, Blip and Pelagus look like the best option right now. They are hot wallets, nevertheless, and the private key can be exposed (it’s stored in the browser) if your device is compromised. Be careful!

2. Understand your wallet

This is where Quai feels different from Ethereum (or other popular networks). Your Quai wallets surface two kinds of addresses, and they’re not interchangeable:

• A QUAI address — used for QUAI. It looks like an Ethereum address and lives on a specific zone (the shard within the Prime → Region → Zone hierarchy). Right now only the Cyprus-1 zone is live on mainnet, so your address has the zone encoded in its prefix.

• A QI address — used for QI. This is a UTXO address resembling Bitcoin’s, and it follows a different rulebook: fixed denominations, enforced non-reuse of addresses, and payment codes (BIP-47-style) so you can receive on a reusable identifier without ever reusing an on-chain address.

Basically, QUAI and QI are separate ledgers. Sending QUAI to a QI address (or vice-versa) won’t work like an ERC-20 transfer. You need the right address type for the right token. The wallets keep your seeds, derives both address types, and handles the routing, so just make sure you’re copying the correct address when you share it.

3. QUAI ↔ QI conversion

Converting between QUAI and QI is an on-chain, protocol-level operation, not a swap on a DEX. It matters because both tokens exist to serve different roles; conversions are how the system lets supply and demand rebalance between them.

How it works: the conversion rate is mathematically determined by a controller that tracks miner difficulty over a ~4000-block window and applies discounts to keep things fair. When you convert, your transaction settles at the next prime block, and every completed conversion is locked for two weeks.

There’s also slippage to account for — it can rise if a lot of conversions land in the same window, and you can set a maximum slippage threshold so it fails gracefully instead of executing on bad terms.

Honestly, the mechanics are meant for market makers and power users who want to arbitrage and provide liquidity between the two tokens. For the rest of us, Pelagus built an easy wrapper called Market Make: you pick a direction (QUAI→QI or QI→QUAI), set your amount and slippage tolerance, and it handles submission.

By default, just keep the two-week lock in mind and don’t convert money you need soon.

4. Ecosystem outlook

The best way to get QUAI onto the network right now is the Symbiosis bridge (Base/Ethereum → Quai), which also handles WQUAI and USDT.

Quainance is the official DeFi hub on Quai (live since July 2026): swap $QUAI, $USDT, and $WQI, bridge assets, and provide liquidity in one place. The usual “all your DeFi in one spot” front door.

Be careful with the spread, though! Liquidity is still thin ($8,130 TVL on Quainance, for example, as shown in the video) and large amounts could cause a huge spread in price.

On the NFT side, Bazarr is the new marketplace on mainnet, a real, live market for NFT collections on Quai. There’s also a growing field of DEX/AMM liquidity and QI’s privacy rails for cash-like transfers.

My honest read (as I said in the deep dive): the dual-token liquidity question is still open: splitting value across two ledgers is harder to bootstrap than one. But the rails are real and the tooling (Blip/Pelagus, bridge, DeFi, NFT, conversions, etc) is much further along than most Layer-1s at this stage and market cap.

Watch the ecosystem list on the Quai website for what’s live next.

Check the Quai Ecosystem

Quickstart: Mining QUAI / QI

What follows here is a quickstart introduction to mining QUAI/QI. However, it’s important to note that I’ll only cover the basics here (literally a quickstart). This is not and advanced mining guide.

Pools

Different from what most beginners think, you don’t really need to run a Quai Network node to mine. You just point a miner at a mining pool. This, of course, has some inherent trust assumptions (you trust the pool will behave well) and some points of centralization, but it is possible.

Quai officially documents pools across all three algorithms; no registration is needed on most, you just use your wallet address as the worker. For GPU mining (KawPoW) the common choices include 2Miners, HeroMiners, K1Pool, Kryptex and others. For SHA-256/Scrypt ASIC mining (available since SOAP), pools like 2Miners SHAd256, StratumX and others support merged mining.

Two names worth knowing if you want to take back control:

• StratumX — Quai’s own zero-fee, non-custodial, KYC-free mining infrastructure, built for solo-style mining directly against the network. You connect with standard stratum software, your work is credited on-chain, and 100% of rewards go straight to your address — no pool fee, no third-party custody. It’s also the route the protocol devs point to for QI mining and lockups (LMRs): some pools don’t yet let you choose QUAI vs QI or set a lockup, but StratumX honors your preference on-chain.

• DePool — the same idea pushed further: a decentralized mining pool you run yourself (just a flag on a Quai node), earning a fee on miners you host with no custom pool software.

We might need a full article later covering how to start your mining setup in each of of those.

Merged mining & SOAP

Here’s the part that makes Quai’s PoW unusually efficient.

Because blocks are nested (zone within region within prime), one mining solution can count for all three chains at once. The docs call this “three chains, one computer” — the same hashrate secures the hierarchy, and coincident blocks act as automatic, trustless bridges. Miners also generate low-difficulty proofs called workshares that get included in the next block and paid proportionally (PRS), so near-misses aren’t wasted.

SOAP extends this to external hashrate: SHA-256/Scrypt miners can point existing ASIC fleets at Quai. When a parent-chain block is found, the subsidy is converted to QUAI and burned — creating continuous buy-and-burn pressure — while the miner is compensated in QUAI via workshares.

I already covered all that in the deep-dive article I mentioned in the beginning. So, it’s worth it revisiting the other piece if you want more depth into these concepts.

Pick your reward: QUAI, QI, or both

At each block a miner chooses whether to be rewarded in QUAI or QI. You can’t claim both from the same block.

The economics differ by design: QUAI rewards scale with the logarithm of difficulty (scarcity-oriented, deflationary), while QI rewards scale linearly with difficulty (energy-linked, inflationary).

So: prefer QI if you want stable, energy-backed cash for operating costs; prefer QUAI if you’re aiming to hold a scarce asset.

You can switch your preference anytime, and you can even lock rewards (LMR) for 2 weeks to 12 months for higher yield.

The trick is that most pools let you set a worker and then choose per-block which asset the pool credits you, or mine a merged workshare set and split between algorithms.

Set up your miner

The practical recipe is the same regardless of algorithm:

1. Wallet — get a QUAI wallet address from Step 1.

2. Pick a pool + software — StratumX or DePool for a decentralized experience. Otherwise, for GPUs (KawPoW), grab SRBMiner-Multi, Rigel, WildRig, or the 2Miners quick-start bundle; for ASICs pick a SHA/Scrypt pool. The pools list recommended software per rig.

3. Configure the connection — your miner connects to the pool over the Stratum protocol (the standard way miners talk to pools). Example for GPU KawPoW on 2Miners Europe:

stratum+tcp://quaikawpow.2miners.com:4545 -u YOUR_QUAI_ADDRESS -p x

1. For SHA-256 ASICs on 2Miners:

stratum+tcp://quaisha.2miners.com:8181 -u YOUR_QUAI_ADDRESS -p x

1. Replace the address with yours; set a rig name if you want, then start the miner and watch the pool dashboard for shares.

That’s it! Hashrate, shares, and payouts. Stratum handles the job distribution; your only job is the correct address, the right port for your algorithm, and patience.

The more workers, like you, pointing computing power to the Quai Network, the stronger it gets against certain threats and more valuable the QUAI you are holding gets, together with the entire ecosystem being powered by the dual-token system.

Hope this quickstart guide has helped you in your first steps on the Quai Network.

Drop your thoughts or questions in the comments.

I’ll answer everything I can, or point you to the right person.

Leave a comment

Thanks for reading 「thecoding」!

Follow me on X at vinibarbosabr and subscribe for free to [en] thecoding.substack.com or [pt-br] codigoaberto.substack.com for more pieces like this.

Check thecoding.dev to start working with me on technical content, docs engineering, devrel partnerships, and more.

Blockchains are excellent tools for validating, storing, and protecting simple data history (the state) in a decentralized, credibly-neutral, and permissionless way. They are far less excellent at letting applications ask complex questions about the current state (queries) and then prove the answer is correct to a light client.

For that we have database and file systems like GroveDB.

My first contact with this tech was while researching Dash’s Orchard implementation for Zcash-like shielded transaction on Dash Evo. There is a full article about that:

In the next few minutes you should be able to leave with a clear picture of what GroveDB is, the problem it solves, why hierarchical design matters for complex queries, how it is already used in production, and what it offers for developers who need queryable, provable blockchain state.

Databases, RocksDB, and the Blockchain-as-Database Reality

Databases exist to organize, store, retrieve and keep large amounts of data consistent while shielding applications from physical details of disks and concurrency.

Early systems forced programmers to chase pointers. Later, the relational model gave devs declarative queries and logical independence. Under internet-scale write pressure, the industry moved toward log-structured merge trees.

Blockchains are not exempt from that.

Blockchains are frequently described as “distributed databases” or “immutable ledgers,” but this is a partial narrative. These decentralized systems still need better ways to make complex queries and many of them use battle-proven databases for off-chain queries like RocksDB.

The latter is an embeddable key-value store forked from LevelDB and became the practical choice for many blockchain nodes to address this weakness. RocksDB can turn continuous, random-looking state updates into sequential writes, offers strong durability via a write-ahead log, and runs inside the node process itself in an efficient way.

Bitcoin Core’s chainstate, NEAR’s trie, and many other clients rely on LevelDB or RocksDB for exactly these reasons.

The truth is that the ledger is append-only and globally agreed. The current state (balances, documents, nullifiers) must still be stored, indexed, and served efficiently on every full node.

Flat key-value storage (as in blockchains) solves the durability and write-throughput problems. It does not, however, give us secondary indexes that stay efficient and produce compact cryptographic proofs. For that we have tools like GroveDB.

Subscribe now

What GroveDB is

GroveDB is a hierarchical authenticated data structure sitting on top of RocksDB. Literally a “grove” of nested Merkle AVL trees, if you want to go technical.

Each tree is a Merk tree: a self-balancing Merkle AVL tree optimized for batch writes and fast range proofs. Trees can contain other trees, so the whole database forms a deep hierarchy who single root hash authenticates everything beneath it. Beautiful, right?

The basic building blocks are called elements:

// Simplified view of the element types (from the GroveDB source)
pub enum Element {
    Item(Vec<u8>, Option<ElementFlags>),          // ordinary data
    Reference(ReferencePathType, ...),            // cross-tree link
    Tree(Option<Vec<u8>>, Option<ElementFlags>),  // a nested Merk tree
    SumItem(...), SumTree(...),                   // automatic aggregates
    CountTree(...), CountSumTree(...),            // counting variants
    // ...
}

A developer works with path queries. Instead of scanning an entire flat map, you name a path through the hierarchy and optionally add limits, offsets or conditional sub-queries.

use grovedb::{GroveDb, Element};
use grovedb_version::version::GroveVersion;

let db = GroveDb::open("./my_db")?;
let v = GroveVersion::latest();

// Create trees
db.insert(&[], b"users", Element::new_tree(None), None, None, v)?;
db.insert(&[b"users"], b"alice", Element::new_tree(None), None, None, v)?;

// Insert data
db.insert(&[b"users", b"alice"], b"age", Element::new_item(b"30"), None, None, v)?;

Because every secondary index is itself a pre-computed subtree, a query on any indexed field stays O(log n) and can return a compact multi-layer proof.

I’ll explain!

Think of a traditional Merkle tree as a single filing cabinet whose drawers are locked with one master seal. GroveDB is an entire building full of filing cabinets. Each cabinet has its own seal, and the seals of the lower cabinets are recorded inside the higher ones.

Open any drawer, prove what is (or is not) inside it, and still verify the entire building with a single, universal root seal.

The hierarchy is the key difference from both a plain Merkle tree and an Ethereum-style Merkle Patricia Trie. Flat structures efficiently prove primary-key lookups, while secondary (or range queries) force expensive scans.

“GroveDB’s nested design turns secondary indexes into first-class, already-authenticated citizens,” as my AI agent summarized it for me.

The “Motivation” section in GroveDB’s documentation also provide a clear explanation on that. In this section, they explain previous database management systems have notable trade-offs while dealing with secondary indices.

Consider an authenticated data structure, like a Merkle tree built on a database of restaurants for example. Each restaurant has certain attributes, such as price and type:

struct Restaurant{
ID uint32;
name: String;
type: String;
isVegan: bool;
};

Four restaurants would be easily committed (and queriable) to a Merkle tree under IDs 0, 1, 2, and 3 (an array like {Restaurant 1, Restaurant 2, Restaurant 3, Restaurant 4} ).

“Querying by primary key is easy and efficient. However, querying by a secondary index is not efficient at all; it’s likely that you will have to iterate over the entire structure,” grovedv.org/documentation.html explains.

GroveDB is a classic time-space tradeoff. It enables efficient querying on secondary indices by precomputing and committing them. A subtree of each possible queryable secondary index (up to a cap) is built and committed to our authenticated data structure. A tree of subtrees; a grove. For the same data, part of the analogous GroveDB structure might look like this:

The Problem GroveDB Solves for Blockchains

Blockchain nodes must do two things at once:

1. apply new blocks quickly

2. answer application questions while proving the answers are correct

Without secondary-index proofs like the ones enabled by GroveDB, light clients either trust the server or download far more data than they need, which consumes gas and storage.

In particular, GroveDB excels in six core points:

1. Secondary-index queries remain fast and produce membership, non-membership and range proofs

2. A single root hash still authenticates the entire structured state

3. Aggregates (sums, counts) are maintained automatically by SumTree and CountTree elements.

4. Operations stay deterministic and cost-accountable, so they fit inside block times

5. The same database can hold both mutable and immutable data

6. It is ACID-compliant and reports operation costs in advance — useful for fee estimation

Easily explained, most authenticated stores can prove “this exact key holds this value.” GroveDB can also prove “these are all the items whose city field equals Phoenix, and nothing else matches,” without forcing the verifier to re-scan the whole dataset. This is super valuable, especially for complex cryptographic systems like shielded pools.

FOLLOW DASH ON X

Empirical Use Case: Dash Orchard

We already talked about that in my dedicated article explaining how Dash Evolution (or Dash’s Platform Chain) implemented Orchard to enable Zcash-like privacy for certain operations.

This is the clearest production case of GroveDB I know of — and my first contact to the tool.

Orchard brings Zcash’s Halo-2 zero-knowledge proofs onto Evolution. The entire shielded state lives inside GroveDB under a single SumTree:

ShieldedBalances (SumTree root)
└── "M" (Credit Pool)
    ├── 128 → Notes          (CommitmentTree)
    ├── 64  → Nullifiers     (ProvableCountTree)
    ├── 192 → AnchorsInPool / AnchorsByHeight
    └── 32  → TotalBalance   (SumItem)

Because the notes, nullifiers and running totals are themselves Merk trees (or specialized count/sum variants), the network can maintain cryptographic commitments, generate compact proofs and still atomically perform the six new state transitions we talked about there: Shield, Unshield, ShieldedTransfer, ShieldFromAssetLock, ShieldedWithdrawal, and IdentityCreateFromShieldedPool.

GroveDB’s structured, append-only layout is also what makes BLAST fast-sync possible: a fresh wallet can reconstruct the necessary note set in roughly twenty-one seconds instead of hours.

It excites me to see that the same hierarchy that stores ordinary documents and identities also host a full shielded pool without sacrificing either privacy or light-client verifiability. True decentralization ethos through clever optimization and accessibility.

What GroveDB + Evolution Let You Do That Others Can’t

Taken together, GroveDB and the Evolution platform give developers a practical combination that many other systems either cannot offer or can only approximate with some trade-offs.

Basically, you can store richly structured (documents, identities, data contracts) with secondary indexes and still hand a light client a compact cryptographic proof that the result is correct. All that without forcing the client to run a full node or trust an external indexer. Groundbreaking!

Other platforms typically push complex queries to off-chain services, accept larger proofs, or require heavier client-side scanning.

With GroveDB, we can know keep both ordinary application data AND advanced cryptographic structures (like Orchard shielded pool) under the same hierarchical root, with automatic aggregates and atomic cross-tree updates that stay deterministic inside block times. This should not be overlooked.

Achieving the same combination elsewhere usually means layering multiple specialized stores, accepting slower sync, or sacrificing either privacy, query flexibility, or light-client security.

How GroveDB Helps Developers, Infra, and Users

For developers: path queries, batch applies, prove/verify helpers, and automatic index maintenance. Cost estimation is built in, Rust and Node.js bindings exist, and the library works with any RocksDB-backed system. Infrastructure operators gain deterministic roots and crash-safe transactions that stay inside block constraints. End users and light clients receive answers that carry the same security guarantees as a full node.

// Generate and verify proofs
let path_query = PathQuery::new_unsized(vec![b"users".to_vec()], Query::new_range_full());
let proof = db.prove_query(&path_query, None, None, v)?;
let (root_hash, results) = GroveDb::verify_query(&proof, &path_query, v)?;

Inside Dash the same grove already organizes identities, data contracts, documents and secondary indexes.

Outside Dash the pattern is reusable wherever hierarchical data must be both queryable and cryptographically verifiable: decentralized identity systems with attribute indexes, supply-chain provenance that needs secondary proofs, private-plus-public hybrid ledgers, or any application that currently leans on external indexers and would prefer on-chain proofs instead.

Other blockchains should definitely give a better look into what Dash developers have built here and consider implementing GroveDB into their own nodes for higher performance.

It is funny, though, because low-level protocol and infrastructure are already often overlooked by many people in crypto. Databases like GroveDB sit underneath that and get even less attention from community and investors.

Just imagine a core dev having to justify this change for decision makers and stakeholders. 🥲

Nevertheless, these things still fascinate me a lot and I believe we should always look for improvements even in the lowest layers because these layers are what set strong (or weak) foundations for everything that goes on top of them.

The Orchard integration shows the design is already production-ready for sophisticated cryptographic structures and, as noted in my previous article, already brings practical benefits for everyone with increased performance and efficiency. The secondary-index proofs show it is fully ready for everyday application queries.

If you are building on a platform that needs rich, trust-minimized state, the GroveDB documentation, tutorials and the open repository are a “must check.” The gap between “we have a ledger” in blockchain and “we have an efficiently queryable, provable application layer” is smaller than it used to be.

Quickstart With GroveDB Tutorials

You can find GroveDB Tutorials to quickstart your database in the official repository on Github. For that, first clone the repo and navigate to the tutorials/ directory.

git clone https://github.com/dashpay/grovedb.git
cd grovedb/tutorials
cargo build

After running cargo build, you can run a tutorial:

cargo run --bin <tutorial name>    ## open, insert, delete, query-simple, query-complex, proofs

• open - Covers how to open a GroveDB instance and perform basic operations.

• insert - Explains how to insert data into GroveDB, including inserting items and subtrees.

• delete - Demonstrates how to delete items and subtrees from GroveDB.

• query-simple - Introduces simple querying capabilities in GroveDB, including retrieving a set of items.

• query-complex - Covers more advanced querying in GroveDB, including conditional subqueries and sized queries.

• proofs - Demonstrates how to generate an inclusion proof for a simple query.

Or use the minimal API directly:

let db = GroveDb::open("./my_db")?;
let v = GroveVersion::latest();
db.insert(&[], b"users", Element::new_tree(None), None, None, v)?;

Drop your thoughts or questions in the comments.

I’ll answer everything I can, or point you to the right person.

Leave a comment

Thanks for reading 「thecoding」!

Follow me on X at vinibarbosabr and subscribe for free to [en] thecoding.substack.com or [pt-br] codigoaberto.substack.com for more pieces like this.

Check thecoding.dev to start working with me on technical content, docs engineering, devrel partnerships, and more.

Today I’m very excited to officially announce a project I’ve been building with Michael (@michael2xl), Zcash Brazil Lead, ZK researcher and contributor: 0xramp.app.

0xramp (zero-x-ramp) is an easy and non-custodial crypto on-ramp and off-ramp that values your privacy, security, and user experience while allowing buying and selling most of the top cryptocurrencies with fiat curre—-ncies like BRL (Brazil), INR (India), ARS (Argentina), VEN (Venezuela), IDR (Indonesia). More fiat corridors and countries are planned for the future.

This fiat access is only possible thanks to the P2P.ME fiat-USDC marketplace that connects merchants from each of these countries with our users via onchain orders (currently running on Base), all managed by the p2pdotme-SDK.

Users can login via an EVM wallet (Rabby and Phantom) to sign the Base transactions for the orders (this will require ETH for gas); or a smart account login powered by thirdweb that has its gas subsidized (effectively gas-free).

New accounts start with a SELL limit of $300 and a BUY limit of $0. Making transactions may organically increase this limit that can also be boosted by logging in with the same smart account on app.p2p.me and completing some tasks there.

Thanks to the NEAR Intents implementation via the 1Click API, users can easily interact with the app using their favorite cryptocurrencies (as long as it’s supported by the implementation — you can request support for cryptocurrencies that are not listed yet) and do not have to worry with swapping them to the Base-USDC, that is the native currency on p2pdotme’s marketplace.

Access 0xramp.app

Join the Open Beta

In this first moment, the 0xramp.app is still in open beta, meaning we are conducting public tests and looking for constructive feedback and suggestions. The app has already been tested relentlessly in the past few weeks and everything should be running well, but we strongly recommending doing small operations only at first.

We are excited to invite all of you who have been following us and waiting for this moment to be part of it.

1. Access 0xramp.app and navigate through it

Take notes of your first impressions:

→ what works well?

→ what could be better?

→ is it clear what needs to be done?

2. Follow our account on X (@0xramplabs) and join our Telegram group t.me/zeroxramp

Share your feedback in the comments or in the group.

Be deadly honest about everything!

We are really looking for constructive feedback and suggestions that help us improve and offer a better ramp.

3. Share with your friends and invite others to join

Don’t keep it to yourself... Spread the news!

Share the app and the Telegram group with your friends.

The more people helping us stress test it, the better it will become for you to easily on-ramp and off-ramp your crypto!

My technical curiosity on Quai has been sitting in the back of my head for a while. Every time Matt or Alan appeared on X posts & spaces the itch came back, but something else always took priority. I finally decided to stop putting it aside.

Quai Network seems to me as one of the more ambitious attempts to keep Proof-of-Work relevant at scale. For all these months of delaying this research, one thing I’ve always been sure: the tech stack is super intriguing and it’s definitely an interesting project worth studying.

In this piece we will look carefully at the architecture, the consensus innovations, the two-token system (QUAI + QI), the privacy proposal of QI, and a brief look at the tokenomics — it may deserve its own economic-focused article later, though.

Subscribe now

Introduction

Quai is a hierarchical, sharded Proof-of-Work network backed by a dual-token system. Its consensus is called Proof-of-Entropy-Minima (PoEM).

Instead of simply racing for the highest difficulty block, miners compete on the total entropy removed from the system.

It’s a pretty smart design, if you ask me. This gives continuous, measurable finality rather than the binary “longest chain” design of classic Nakamoto consensus — thinking about Bitcoin and similar, here.

The execution layer is sharded. If you follow me long enough, you know I’m a huge enthusiast of sharding, having written and contributed to NEAR, MultiversX, and Radix, for example.

Quai uses a Prime → Region → Zone hierarchy. In theory, documentation claims this structure can scale to 50,000+ TPS once enough zones are active. This is purely theoretical, though, and I’m highly skeptical of purely theoretical claims. I would need to see some real tests backing these numbers before I could endorse them.

Public tests before mainnet reached roughly 4,700–7,000 TPS in a nine-shard topology, which is already impressive for a PoW chain. These are the numbers I’m looking to and am also excited about.

As of August 2026 only the Cyprus-1 zone is live on mainnet; additional shards are expected to activate automatically according to demand, when block gas usage and uncle rates cross certain thresholds.

Transactions are cheap and confirmation is fast because of short block times and the entropy-based ordering. The network also supports multi-algorithm mining (KawPoW, SHA-256, Scrypt) through a mechanism called workshares and a protocol-level subsidy system named SOAP (Subsidized Open-market Acquisition Protocol).

On top of this infrastructure sits a deliberate dual-token design:

• QUAI — account-based, EVM-compatible, intended as a programmable store of value.

• QI — UTXO-based, fixed-denomination, energy-linked medium of exchange with cash-like privacy features.

Miners choose which token they want as reward on a per-block basis. This is the foundation of Quai’s monetary experiment, which I also find interesting while holding some reservations about.

We will dive into all that now!

FOLLOW QUAI NETWORK ON X

Quai and QI Easily Explained

Easily put, QUAI is positioned as the “digital gold + smart-contract fuel.” It lives on an account model like Ethereum, on top of the Quai Network. You can write contracts, deploy DeFi, and it aims to become a scarce asset as issuance slows down backed by strong maths.

QI is closer to digital cash. It lives on a UTXO ledger (like Bitcoin) but with strict rules that enforce more privacy and more fungibility by default (more than BTC, at least).

Its value is designed to track the real energy cost of producing it. There is no pre-mine and no fiat collateral (like dollar-pegged stablecoins). Every new QI enters circulation only through mining or conversion from QUAI.

Because the two tokens serve different roles, miners and users can express different preferences. Someone who wants programmable money and long-term scarcity can hold QUAI. Someone who wants everyday payments with better privacy can prefer QI. This is the design.

Conversions between the two exist on-chain (with a current two-week lock) so the system can rebalance.

On the tech side, the infrastructure operates similar to Bitcoin. Miners point their computers to the network and generate proof of computational work (hashrate).

However, instead of basing its consensus on a minimum difficulty threshold alone (as Bitcoin does), it requires precise entropy scores. The official documentation example is perfect to easily understand this difference:

Traditional Proof-of-Work asks a simple question: “Does this block meet the minimum difficulty requirement?” If yes, the block is considered valid. If no, it’s rejected.The Issue: This ignores the actual work done. Imagine two students taking a test:

• Student A scores 85%

• Student B scores 95%

• Both pass the 80% requirement, but Student B clearly did more work

Traditional PoW treats both blocks as “equally valid” once they pass the threshold. PoEM recognizes that one block always represents more work than another.

Intrinsic block weight is like a “work certificate” - it measures exactly how much computational work went into creating a specific block.Think of it as the difference between:

• Pass/Fail grading (traditional PoW): “Did you meet the minimum?”

• Precise scoring (PoEM): “Exactly how well did you do?”

This precision allows PoEM to make instant, objective decisions about which block represents the most work and should be accepted by the network.

READ MORE ABOUT QUAI

PoEM, SOAP, Merged-Mining and Related Mechanisms

Proof-of-Entropy-Minima

Classic Proof-of-Work orders competing chains by the highest cumulative difficulty (the “heaviest chain”). Every block that meets the difficulty target is treated as equal. PoEM changes that.

Instead of adding difficulty thresholds, PoEM measures the intrinsic entropy removed by each block — how much randomness the hash actually eliminated from the genesis state. The more leading zeros (or more precisely, the higher the intrinsic block weight), the more entropy was removed.

Single-block entropy ≈ 1 / 2^leading_zeros

Example:
• 16 leading zeros → removes 1 in 65,536 possible states
• 17 leading zeros → removes 1 in 131,072 possible states

Total chain entropy is the product of every block’s entropy (stored in practice as the sum of bits for efficiency). Because multiplication is strictly ordered, two honest nodes that see the same set of blocks will always pick the exact same tip. There is no temporary split that later needs resolution.

This produces two concrete advantages:

1. Statistical finality arrives faster: a short sequence of high-entropy blocks quickly becomes astronomically expensive to rewrite, meaning more resistance against forks.

2. All valid work contributes. There is no “orphan tax” on near-misses the way classic PoW has. Miners are always contributing and being rewarded according to their workshares.

Workshares and Proportional Reward Splitting (PRS)

Workshares are lower-difficulty proofs of work. They do not create a full Quai block, but they still remove entropy and get included in the next valid block.

The protocol runs a soft economic target of 8 workshares per block (params.ExpectedWorksharesPerBlock = 8). This value sets both the share difficulty and the denominator used for proportional payout. There is also a hard protocol-enforced cap of 32 workshares that can be included in any single block (raised from 16 at the Singularity fork).

Because workshares are generated far more frequently than full blocks, they give the protocol a much more accurate real-time sample of who is actually contributing work. Quai uses this sample for Proportional Reward Splitting: the block reward at each height is divided among the block producer and every included workshare, proportional to the work each one proved.

Solo miners therefore receive direct payouts for their shares without needing a centralized pool — something most PoW ecosystems have failed to achieve in a decentralized way. At the same time, research on PRS shows that the threshold for profitable selfish mining rises (an attacker needs >38 % hashrate under realistic parameters before the strategy becomes rational).

In short: workshares turn near-misses into paid, entropy-contributing objects and make reward distribution fairer than any traditional pool approximation.

SOAP and Multi-Algorithm Merged Mining

SOAP (Subsidized Open-market Acquisition Protocol) inverts the economics of other merge-mining systems we are used to in crypto.

Miners can point existing SHA-256 (BCH) or Scrypt (LTC/DOGE) hardware at Quai if they want -- and only if the mining pool they are using supports this feature.

When a parent-chain block is found, 100% of its coinbase is forced to a protocol-controlled address (QADDR). That address sells the parent coins (BCH, LTC, DOGE) on the open market, buys QUAI, and burns every token purchased. The miner is compensated in QUAI through the workshares that were included in the KawPoW block.

The best part: miners have full autonomy into deciding and adjusting their workshare pointed to each algorithm (and chain). The market sets the pace and drives the incentives.

Nevertheless, only KawPoW miners produce Quai blocks.

The other algorithms contribute pure external hashrate and continuous buy-and-burn pressure on QUAI. The net effect is external security budget that might even contribute to the deflationary elements of the token.

As of early August 2026 the mechanism is live and the cumulative parent-chain revenue routed through SOAP already sits in the millions of dollars, with more than 165 million QUAI permanently burned.

QI: The Cypherpunk Energy Cash

QI’s value proposition is straightforward: it is money whose issuance is tied to real energy expenditure and whose privacy model tries to recreate the properties of physical cash.

Cypherpunk enough? I think so.

Let’s see what privacy properties it has.

QI uses four structural rules that aim for privacy, rather than zero-knowledge proofs (Zcash) or FMCP++ (Monero):

1. Enforced non-address reuse — every output address in a transaction must be unique.

2. Payment codes (BIP-47 style) — a reusable identifier that lets the sender derive a unique one-time address via Diffie-Hellman. The payment code itself never appears on-chain (I’ve tested it!).

3. Fixed denominations — only 16 rounded allowed values (0.001 QI up to 1,000,000 QI). Arbitrary amounts are impossible; every payment looks like a collection of standard “bills.”

4. Incentivized cooperative reaggregation — consolidating many small UTXOs into larger ones requires interaction with other users and is restricted, increasing mixing.

// TxOut defines a Qi transaction output.
type TxOut struct {
    Denomination uint8     // Fixed denomination index (0–16)
    Address      []byte
    Lock         *big.Int  // Block height the entry unlocks. 0 or nil = unlocked
}

The result is described by the team as “transparent but untraceable.” In a private chat, this design decision was described to me as a focus on “scalable privacy”.

Full nodes see the complete UTXO set, but linking payments to a long-term identity becomes very expensive, especially at scale.

There are currently no plans to add native shielded or zero-knowledge features to the QI ledger or to the base protocol, primarily because of the latency and state-storage costs that would come with them on a high-throughput sharded PoW chain.

That said, the EVM-compatible QUAI side can already host existing privacy applications (Railgun-style, TornadoCash-style, or any other ZK circuit deployed as a smart contract). Native QI privacy remains structural by design.

Privacy comparison (tech wise)

• Stronger than plain Bitcoin UTXOs.

• Slightly weaker to Zcash Orchard/Ironwood (Halo 2 proofs) and Monero (FCMP++)

• Intentionally chosen for scalability over absolute cryptographic privacy, but good enough for most use cases.

• Focused on increasing its anonymity set through scale (having more users using the privacy feature, which strengthens the overall privacy experience for everyone)

My concerns on the two-token design

Separating the three classic properties of money (medium of exchange, unit of account, store of value) creates real economic challenges.

First, because liquidity is already hard enough to bootstrap and maintain for single-token systems. This challenge is already seen in many other crypto projects with good tech but low adoption and liquidity. Splitting the design risks splitting liquidity as well, which could slow down adoption.

Constant mining sell pressure on QUAI, the current two-week lock on conversions, and the need to grow two separate markets all increase the coordination problem. SOAP and the Singularity burn help offset some of the sell pressure, but the dual-token experiment is still young and liquidity remains thin.

Second, because all three properties are desirable for a monetary system that people can really use at scale and trust, in my opinion. Remove one pillar and the system weakens significantly.

Matthew Poletiek (@mattman), disagree with my second take, offering a clear counter-view in private conversation:

“Most people with a fundamental understanding of economics wouldn’t consider the USD a store of value. TradFi has gold and mutual funds for this very reason. So if we agree USD isn’t a store of value we can understand why it might not be a good idea to force 1 token to be both a store of value, medium of exchange, and unit of account.”

Alan (@0xalank) made a related point: crypto has never actually produced a true network-native unit of account — only hypothecated ones.

Both observations are fair.

Whether Quai’s deliberate separation of roles will prove more robust than forcing a single token to do everything remains an open empirical question. The experiment is worth running, as long as all participants are aware of its experimentation nature and stay clear-eyed about liquidity and coordination risks involved.

Closing Thoughts

I believe Quai is one of the most technically ambitious PoW projects of the current cycle, with a super interesting tech stack.

PoEM, workshares, hierarchical sharding, and SOAP form a coherent attempt to keep energy-based security competitive at high throughput, scale, and performance.

QI’s cash-like privacy model is a thoughtful, scalable alternative to heavy zero-knowledge or ring signature systems and provides a very satisfactory level of privacy and confidentiality to its users. It’s a true cypherpunk project in my opinion.

The open questions are mostly theoretical, economic and operational:

• can the dual-token system maintain balanced liquidity, foment adoption, and generate demand?

• how far the sharding architecture can lead the chain to meet real demand?

• will the structural privacy of QI prove itself in adversarial environments?

I will be watching closely from now on, while trying to have these questions answered.

Drop your thoughts or questions in the comments — I’ll answer everything I can, or point you to the right person if I don’t know the answer myself.

Leave a comment

Thanks for reading 「thecoding」!

Follow me on X at vinibarbosabr and subscribe for free to [en] thecoding.substack.com or [pt-br] codigoaberto.substack.com for more pieces like this.

I suddenly hit a wall while trying to access my smart account powered by ERC-4337 account abstraction. So, I built a tool (erc4337-driver) to help others facing the same issue I faced there.

The issue: The private key I correctly exported and backed up from an app was not returning the same 0x address holding my funds on that app when imported into any of the most popular EVM wallets (Rabby, Phantom, MetaMask).

This, I discovered, is an intentional behavior. Nevertheless, explicit and intuitive documentation and warnings were lacking in the app — leading to confusion and even a brief fear of having lost my funds. Proper education, documentation, and tools are very much needed to improve the user experience and self-custody assumptions, which is what this article will address.

Let’s talk about that!

Subscribe for free to 「thecoding」

Subscribe now

How account abstraction breaks old self-custody assumptions

In blockchain, we learned that exporting and backing up a private key equals self-custody and immediate, full access to our funds. However, tech is evolving and different wallet implementations sometimes break this mental model.

Account abstraction via ERC-4337 smart accounts is one of these models where a simple private key export + import may not work the way most OG crypto-native people (without this specific knowledge) would expect. I was a victim of that myself, despite having over six years of experience producing technical content for blockchain.

The usual self-custody assumption is really intuitive:

1. User creates a wallet account by generating a private key and a public key derived from it.

2. User receives and stores funds in this address (the public key) that can later be spent by signing transactions with the private key.

3. User can export the private key (or a seed) and back it up to guarantee permanent access to the funds even when the wallet app they were using stops working or clears the login data.

4. All the user needs to do is to import this seed (or private key) into a wallet that supports the same derivation/recovery path.

Easy, right?

However, it wasn’t easy enough for most Web2 users. So, blockchain devs started building account abstraction solutions like the ERC-4337 smart accounts to improve the user experience.

Now, apps like p2pdotme can implement solutions like thirdweb that allows users to create wallets with abstracted logins via Google, email, phone number, or other passkeys.

Sounds great, right? Users can now easily login into their wallets with digital credentials they are already used to, but with a problem: what happens if the user loses access to their Google account, email, phone (this may happen more often than most people realize — see post below)…

…Or if the app (p2pdotme) and/or the wallet provider (thirdweb) stop working or close?

Not that great anymore, right? This, however, is not a today’s issue. Crypto and blockchain emerged and gained popularity exactly as solution to this very problem by introducing self-custody and ownership primitives. Are we going backwards, then? Not really (technically speaking), but education (and proper documentation) is needed.

When presented this issue, many account abstraction enthusiasts will say: “actually, these are still self-custody wallets. you can still export and backup your private key. see? easy!”

They are not wrong, but they are not entirely right neither. The fact is that most of them have probably never really tried to recover their ERC-4337 smart account via the in-app exported private key. ACTUALLY, most of them would have had the same surprise I had a while ago when doing it for the first time: the address is not the same and no popular wallet app can easily find this address.

No, you did not. I’ll explain.

How ERC-4337 smart accounts work under the hood

In a classic externally owned account (EOA), the relationship is simple and direct:

• One private key

• One public address derived from it

• That address holds the funds

• Whoever controls the private key controls the funds

When you export the key and import it into another wallet, you get the same address. No surprises.

ERC-4337 smart accounts (especially the ones created by in-app wallet providers such as thirdweb) work differently. There are two addresses involved:

1. The admin (or “personal”) account
   This is a regular EOA. Its private key is what the app lets you export. This key is the owner of the smart account.

2. The smart account itself
   This is a smart contract. It is the address the user actually sees in the app and the address that holds the funds, tokens, reputation points, etc.

When you log in with email, Google, or a passkey, the provider creates (or recovers) the admin EOA behind the scenes and uses it to control the smart account. The smart account is usually deployed through a factory contract using a deterministic address (CREATE2). The salt for that address is typically derived from the admin key (and sometimes some extra data).

thirdweb-dev/contracts/BaseAccountFactory.sol

/// @notice Deploys a new Account for admin.
function createAccount(address _admin, bytes calldata _data) external virtual override returns (address) {
    address impl = accountImplementation;
    bytes32 salt = _generateSalt(_admin, _data);
    address account = Clones.predictDeterministicAddress(impl, salt);

    if (account.code.length > 0) {
        return account;
    }

    account = Clones.cloneDeterministic(impl, salt);
    // ... registration ...
    _initializeAccount(account, _admin, _data);

    emit AccountCreated(account, _admin);
    return account;
}

/// @notice Returns the address of an Account that would be deployed with the given admin signer.
function getAddress(address _adminSigner, bytes calldata _data) public view returns (address) {
    bytes32 salt = _generateSalt(_adminSigner, _data);
    return Clones.predictDeterministicAddress(accountImplementation, salt);
}

/// @dev Returns the salt used when deploying an Account.
function _generateSalt(address _admin, bytes memory _data) internal view virtual returns (bytes32) {
    return keccak256(abi.encode(_admin, _data));
}

This is the precise mechanism:

• The admin (the EOA whose private key you can export) is passed in.

• The salt is keccak256(abi.encode(admin, data)).

• The smart account address is deterministically predicted / deployed via Clones (CREATE2-style).

• The admin is then set as the owner of that smart account.

When data is empty (0x), which is the common case for standard thirdweb accounts, the address depends only on the admin key + the factory.

So the real ownership chain looks like this:

When you export the private key from the app and import it into Rabby, MetaMask, Phantom, or any other standard wallet, those wallets correctly show you the admin EOA address. They have no knowledge that this key also controls a completely different smart-account contract. That is why the address is different and why the funds appear to be missing.

The funds were never lost. You simply recovered the key that owns the smart account, not the smart account interface itself.

import { inAppWallet } from "thirdweb/wallets";
import { smartWallet } from "thirdweb/wallets";

// 1. User logs in → this creates/recovers the admin EOA behind the scenes
const adminWallet = inAppWallet();
const personalAccount = await adminWallet.connect({
  client,
  strategy: "google", // or "email", "passkey", etc.
});

// 2. That admin EOA is used to control the smart account
const wallet = smartWallet({
  chain: sepolia,
  sponsorGas: true,
  // factoryAddress can be passed or uses thirdweb’s default
});

const smartAccount = await wallet.connect({
  client,
  personalAccount, // ← the admin EOA
});

The personalAccount is the admin whose address is fed into the factory’s getAddress / createAccount under the hood.

This design is intentional. It allows gasless transactions, social login, session keys, and other UX improvements. But it breaks the mental model most people carry from years of using normal wallets: “I exported the private key → I should see my funds.”

In the next section I’ll show exactly how to reconnect to the smart account using the exported admin key — and why I ended up building a small open-source tool for it.

Reconnecting with the exported admin key

Once you understand the two-address model, the recovery path becomes clearer, but still not super intuitive.

You exported the private key of the admin EOA. That key controls the smart account. To use it you have two main options:

Option 1 — Reconnect through the thirdweb SDK

You can take the exported private key and feed it back into thirdweb’s own stack:

import { privateKeyToAccount } from "thirdweb/wallets";
import { smartWallet } from "thirdweb/wallets";

const personalAccount = privateKeyToAccount({
  client,
  privateKey: "0x...", // the key you exported
});

const wallet = smartWallet({
  chain: base,
  sponsorGas: true,
  // factoryAddress if you need a specific one
});

const smartAccount = await wallet.connect({
  client,
  personalAccount,
});

// Now smartAccount.address is the real smart account that holds the funds

note that the exact import path can vary slightly between thirdweb SDK versions

This works. It is the official path. But it still requires:

• the thirdweb SDK

• a valid clientId

• knowledge of the correct factory / configuration

Most users who just exported a private key and opened Rabby or MetaMask will never do this. They expect the key itself to be enough.

Option 2 — Drive the smart account directly

Because the admin is allowed to call execute / executeBatch on the account contract (the onlyAdminOrEntrypoint path), you don’t actually need the full thirdweb stack. You only need:

1. The admin private key (or the key loaded in Rabby)

2. The factory address (or the already-known smart account address)

3. A way to call the account contract

That is the exact wall I kept hitting. There was no small, focused tool that would let me take an exported admin key, open it in a normal wallet, and immediately act as the smart account — without going back through the original provider’s SDK.

So I built one.

Introducing erc4337-driver

erc4337-driver is a thin TypeScript library (MIT) that does exactly what I needed:

• Predict the smart account address from factory + admin

• Verify the connected key is actually an admin (isAdmin — fail-closed)

• Attach via any EIP-1193 provider (wallets like Rabby, MetaMask, etc.)

• Call execute / executeBatch directly on the smart account

No thirdweb clientId required for the core path. No bundler required for the basic admin-driven flow.

import { attach } from "erc4337-driver";
import { base } from "viem/chains";

const session = await attach({
  provider: window.ethereum, // Rabby
  factory: "0xfactoryaddress", // factory placeholder
  chain: base,
});

console.log(session.address); // the real smart account
await session.execute({
  to: target,
  data: calldata,
});

The library is intentionally narrow. It is not a full wallet. It is a recovery/driver tool for an already-deployed ERC-4337 account whose admin key you control.

It’s also still in the version v0.1.0 and only tested against the thirdweb SDK and the p2pdotme implementation. I plan to build integrations with other ERC-4337 providers, cover edge cases from different apps, and add more functionalities that could be useful for devs and advanced users.

You can find it here:

github.com/vinibarbosabr/erc4337-driver
npmjs.com/package/erc4337-driver

Open for contributions!

This library is also being implemented in production by a project I’m building with Michael2xl: 0xramp. It is an on-ramp & off-ramp app built on top of NEAR Intents and the p2pdotme-sdk. You can follow our work at x.com/0xramplabs.

Ah, I recently made a contribution to p2pdotme/docs clarifying the self-custody and recovery path. This will help avoiding confusion from other users (like me), as the information (and FAQ) will now be properly documented.

Closing thoughts

Account abstraction improves onboarding. Social logins and gas sponsorship are real wins that we can’t ignore. But they also quietly change what “I backed up my private key” means.

The key is still sufficient on-chain. The recovery path, however, is not obvious enough to most users. When documentation and tooling lag behind the architecture, people experience that gap as lost funds — even when nothing is lost.

Better education, clearer warnings at export time, proper documentation, and small focused tools help close that gap. Self-custody only works when people can really exercise it.

Privacy has never been more important as in this era of pervasive digital surveillance and escalating data breaches.

Financial privacy is a very important extension of that and the usual on-ramp to other privacy tools that need to be paid for and maintained. There is no real privacy without financial privacy and Dash is one fantastic project I like that is building with that in mind.

This article is a Dash special with some privacy advocacy. We will understand Dash’s orchard implementation on Evo, how it can keep high performance thanks to GroveDB and what the heck GroveDB is. As usual, it will have a technical outlook, an easier explanation, and some utility- and security-focused perspectives.

Subscribe now

Introduction: Privacy on Dash

According to the IBM Cost of a Data Breach Report 2025 (covering 2026 data), the global average cost of a data breach reached $4.44 million, with the United States hitting an all-time record of $10.22 million per incident. Breaches often involve human elements and take an average of 241 days to identify and contain, leaving sensitive financial and personal data exposed for extended periods.

In the cryptocurrency space, compromised account data frequently appears on dark web markets, with values ranging from $20 to over $2,650 per record, underscoring the real-world risks of traceable transactions on public ledgers, often leading to kidnapping or other threats in the meat world.

Dash has built privacy solutions since its early days. In 2014, it introduced PrivateSend (a CoinJoin-based mixing feature), making it one of the longest-running blockchains with built-in protocol-level privacy tools. This foundation positioned Dash as a valuable payment network that balanced usability with confidentiality long before many competitors entered the space.

FOLLOW DASHPAY ON X

In February 2026, Dash announced plans to integrate Zcash’s Orchard shielded pool technology into its Evolution chain (also known as Dash Platform). With that, Dash brings advanced zero-knowledge privacy features to it’s application-focused layer.

I wrote about that when it happened:

The implementation stands out for combining Orchard-level cryptographic privacy with GroveDB-powered performance advantages and a fully on-chain design that avoids new third-party dependencies. We will dive more into that later.

Platform 4.0, which includes this Shielded Pool, was released earlier this month (July 2026). This timing makes now an ideal moment to understand how Dash is delivering shielded privacy with high performance and scalability.

Evolution Chain: The Foundation

Dash operates on two interconnected layers. The original Core chain handles the primary payment functionality and has long relied on its masternode network for governance and features like PrivateSend.

Evolution, also called Dash Platform, is the newer application-focused layer built on top of it — and the one that now has its own version of the Zcash-forked Orchard.

Evolution runs as a fully Proof-of-Stake system and is loosely based on Cosmos-style architecture. This gives some very practical advantages:

• blocks are produced roughly every second (one-second block time)

• and finality is deterministic, not probabilistic (as in Proof-of-Work chains)

Meaning that once a block is validated, it’s deterministically final. There is no need to wait for multiple confirmations like happens with Bitcoin, Zcash, Monero, and Litecoin, for example. This speed and certainty matter a lot when you’re dealing with private transactions that involve zero-knowledge proofs.

The real secret sauce here is GroveDB, Dash’s custom structured database layer that powers the entire Evolution chain. I have to say I didn’t know about GroveDB before and it is a fantastic open-source tool for storing and querying large chunks of data efficiently.

Instead of a simple key-value store, GroveDB organizes data as a hierarchical forest of Merkle AVL trees. It supports secondary indexes, cryptographic proofs for queries, sum trees for aggregates, and efficient append-only structures.

This design is what makes advanced privacy features practical at scale. Without a database layer built for structured, provable, and fast access, running something as computationally heavy as an Orchard shielded pool on-chain would likely come with major performance trade-offs.

We’ll take a closer look at how GroveDB works later.

Understanding Zcash Orchard

First of all, it’s super important to say I’m a HUGE FAN of Zcash. It is, easily, one of my favorite crypto projects for many reasons.

Zcash introduced shielded transactions back in 2026 with its original Sprout shielded pool. It was groudbreaking at the time because it allowed users to send and receive funds without revealing the sender, receiver, or amount on the public blockchain. However, Sprout came with a trusted setup ceremony and relatively heavy computational requirements.

In 2018, Zcash upgraded to Sapling. This version made shielded transactions much more practical by significantly reducing proof generation time and improving overall efficiency. Sapling removed most of the trusted setup concerns from everyday use and became the standard for private Zcash transactions for several years.

Orchard, activated in 2022, represents the current state of the art. It was built from the gound up using the Halo 2 zero-knowledge proof system. Unlike earlier versions, Orchard requires no trusted setup at all. This removes a long-standing point of criticism and potential attack surface.

It’s worth noting that Zcash is now migrating to another shielded pool: Ironwood. The design logic is the same of Orchard and the migration is happening only to verify the total shielded ZEC supply, following an already-fixed bug found in the old code base — but that’s a topic for another article.

At a high level, shielded pools work by using special “notes” instead of regular transaction outputs. When you receive funds in a shielded pool, you get a note that contains the amount and is encrypted to your viewing key. To spend it later, you create a zero-knowledge proof that proves you own a valid unspent note and that the total value is conserved — without ever revealing which specific note you are spending or who you are sending it to.

Think of it like putting money inside a sealed envelope. Anyone can verify that the envelope contains exactly the right amount and that it hasn’t been tampered with, but nobody can see who put the money in or who is allowed to open it. The nullifier acts like a unique serial number that gets publicly marked as spent once the envelope is used, preventing double-spending without linking it back to the original note. Brilliant!

Orchard’s strength include strong privacy guarantees, better performance than previous generations, and support for future scalability improvements through recursive proofs. In practice, millions of ZEC now sit in the Orchard pool (and will soon migrate to Ironwood), showing real adoption.

That said, Orchard on Zcash still has noticeable limitations. Wallets must scan and trial-decrypt large portions of the blockchain to find incoming notes, which makes initial sync slow. The growing set of commitments and nullifiers also contribute to increasing state size over time, which affects both node operation and long-term scalability (Tachyon is is an ongoing development that aims to address some of these trade-offs).

This is exactly where Dash’s approach starts to diverge in interesting ways.

Dash’s Implementation of Orchard

Dash didn’t just copy Zcash’s Orchard code and released this copy with a different name. They took the mature cryptographic foundation and adapted it specifically for the Evolution chain and GroveDB’s unique storage model. It’s a well-thought Dash-specific implementation of what talented cryptographers built for Zcash, but the Dash adjustments are equally important (and very exciting).

The core cryptography is the same as Zcash’s Orchard. It uses the Pallas and Vesta elliptic curves, Sinsemilla for the note commitment tree, RedPallas signatures for spend authorization, Halo 2 for the zero-knowledge proofs, and ChaCha20-Poly1305 for encrypting notes.

Key derivation also follows the ZIP-32 standard. This means Dash benefits from years of security review and real-world testing that Zcash’s Orchard has already undergone.

Where Dash diverges is in how it integrates and optimizes the system. Instead of using Zcash’s full orchard crate directly, they maintain a Dash-parameterized fork inside the grovedb-commitment-tree crate (part of the GroveDB repository). This fork lives comfortably inside GroveDB, which is the structured database layer that powers the entire Evolution chain.

The shielded pool is stored under a dedicated ShieldedBalances root tree in GroveDB. This root is itself a SumTree, which automatically maintains aggregate balance checks across the pool. Inside it sits a single credit pool (keyed as “M”) that contains five carefully positioned subtrees. The most important ones are:

• A CommitmentTree (using Sinsemilla) that stores note commitments and encrypted payloads in chunks.

• A ProvableCountTree for nullifiers that prevents double-spends with strong atomic guarantees.

• Additional trees for anchors and running totals.

// Shielded pool storage layout in GroveDB (Platform 4.0)

ShieldedBalances (SumTree root)
└── "M" (Credit Pool)
    ├── 128 → Notes          (CommitmentTree, chunk_power=11)
    ├── 64  → Nullifiers     (ProvableCountTree)
    ├── 192 → AnchorsInPool  (NormalTree)
    ├── 96  → AnchorsByHeight (NormalTree)
    └── 32  → TotalBalance   (SumItem<i64>)

This design lets the network efficiently verify balances and spent notes without scanning everything from scratch every time. It leverages a smart mapping architecture and GroveDB’s efficient querying for that.

Dash also made several practical modifications. Memos are much more compact (36 bytes instead of Zcash’s 512-byte memos). Addresses use a clean Bech32m format with the dash1z prefix for easy identification.

// Dash-specific modifications in the Orchard fork

// 1. Much smaller memos (36 bytes vs Zcash's 512 bytes)
pub struct DashMemo {
    pub kind: u32,           // 4 bytes
    pub payload: [u8; 32],   // 32 bytes
}

// 2. Custom Platform sighash (binds Dash-specific fields)
fn platform_sighash(
    bundle_commitment: &[u8],
    extra_data: &[u8], // identity keys, withdrawal scripts, etc.
) -> [u8; 32] {
    let mut hasher = Sha256::new();
    hasher.update(b"DashPlatformSighash");
    hasher.update(bundle_commitment);
    hasher.update(extra_data);
    hasher.finalize().into()
}

// 3. Address format (no Unified Addresses / F4Jumble)
let address = "dash1z..."; // Bech32m with HRP "dash1z"

One very interesting aspect: there’s no fee bidding mechanism. Fees are flat for a given transaction size, which reduces fingerprinting based on different fee patterns that could be used for profiling and chain analysis. The sighash is also customized to bind Dash-specific fields like identity keys and withdrawal scripts.

On the functionality side, Platform 4.0 introduces six new state transition types that make the shielded pool usable in real applications:

• Shield and Unshield (move credit funds in and out of the pool)

• ShieldedTransfer (credit private transfers inside the pool)

• ShieldFromAssetLock and ShieldedWithdrawal (bridge with the Core payment chain)

• IdentityCreateFromShieldedPool — a particularly interesting one that lets users create new identities funded entirely from shielded credits, using fixed denominations to strengthen the anonymity set.

Perhaps the biggest practical advantage comes from how GroveDB handles network synchronization. Because the shielded state is stored in well-structured, append-only trees with efficient chunking, wallets can sync from scratch very quickly.

Dash calls this fast sync capability BLAST sync, and early testing shows it can complete in around 21 seconds on a fresh wallet — a massive improvement over traditional shielded implementations that often take hours or days.

The team also put serious effort into hardening the implementation before release. Platform 4.0 included extensive testing and stability work (with help from newer AI-assisted tooling) to make sure the shielded pool would be reliable once activated.

Finally, the known counterfeiting vulnerability that affected Zcash’s Orchard has been addressed in Dash’s version before the pool goes live on mainnet.

Alpha Insight!

Talking to ⁨Joël Valenzuela⁩, he revelead some alpha from internal discussions. These are not confirmed directions yet, but some insights worth considering while studying Dash’s Orchard implementation.

He expanded on the plans about the shielded token implementation, which comes with a different flavor than the plans for Zcash Shielded Assets (in research by Zooko’s Shielded Labs).

In Zcash, the idea is to combine all tokens and regular ZEC value transfer in the same pool for maximum anonymity set.

In Dash, the idea is to have a separate pool for tokens as fr regular DASH credit transfers.

“This splits the anon set, but makes it more efficient. It’s seen as an acceptable trade-off,” Joël said. “I’ve heard plans of allowing token users to create a shielded pool for just their token for maximum cost-effectiveness, but I’m not sure.”

Personally, I prefer a larger anonymity set, considering Dash already has many performance optimizations. But it’s a valid approach.

Utility: Practical Use Cases & Benefits

Now that the shielded pool is built into Platform 4.0, what can people actually do with it?

The most immediate use case is private credit transfers on the Evolution chain. Users can convert their DASH (from the core, payment chain) into credits (in the evo, platform chain) and then move funds into the shielded pool.

Once shielded, they can send these funds privately to others, and pull them back out when needed, all while keeping the amounts and counterparties hidden from the public ledger. Private fee payment is also supported, so even the cost of using the network can stay confidential.

A particularly interesting feature is IdentityCreateFromShieldedPool. This allows someone to create a new Dash identity on Evolution using only shielded credits. The system uses fixed denominations for these identity-creation transactions, which helps strengthen the anonymity set: every transaction of the same denomination looks identical from the outside. This opens the door to creating private identities and profiles without linking them to transparent on-chain activity.

In the near future, Dash plans to extend shielded functionality to tokens. While the initial release focuses on credits, the team has already signaled that shielded token transfers are coming next. This would let users move tokenized assets (including RWAs) with the same level of privacy currently available for regular credits.

Privacy is the utility. Both for users and for builders who will be able to ship more privacy-focused solutions built around Dash and the Evolution ecosystem.

Developer & Ecosystem Perspective

For developers, the shielded pool is now part of the core Platform 4.0 state machine, which means it can be used directly through the existing Dash Platform tooling once wallets and SDKs add support.

The main places to explore the implementation are:

• dashpay/platform — the primary repository containing the state transitions and shielded pool logic.

• dashpay/grovedb — where the actual cryptographic storage lives (specifically the grovedb-commitment-tree crate).

• dashpay/orchard — Dash’s parameterized fork of the original Zcash Orchard code.

Most developers won’t need to work directly with the low-level cryptography. Instead, they’ll interact with the shielded pool through higher-level Platform SDKs (JavaScript, Rust, etc.) and updated wallet libraries. Wallets will need to add support for the new shielded state transitions and the specialized sync endpoints that GroveDB exposes for fast note retrieval.

// Example: IdentityCreateFromShieldedPool state transition

pub enum StateTransition {
    // ... other transitions

    IdentityCreateFromShieldedPool {
        identity_id: Identifier,
        public_keys: BTreeMap<KeyID, IdentityPublicKey>,
        shielded_proof: OrchardBundle,           // Halo 2 proof + notes
        value: u64,                              // Must be in allowed denominations
    },
}

This opens up interesting possibilities for builders. You can now create applications that use private identities, confidential document handling, or shielded credit flows without having to build privacy from scratch. Once shielded tokens are added in future upgrades, the design space expands further: private token transfers, confidential DeFi primitives, and more.

If you’re building on Evolution and care about privacy, this is worth keeping an eye on. A deeper technical follow-up on how to actually integrate shielded functionality into applications could be valuable once more wallets and SDKs have mature support.

My Opinion on Dash’s Orchard Implementation

Dash’s Orchard implementation stands out because it brings mature zero-knowledge privacy to a chain that prioritizes speed and usability, supported by an OG community of users.

By integrating it directly into GroveDB, Dash avoids the slow sync issues common in other shielded systems while keeping everything fully on-chain and recoverable with a standard seed phrase. Security + efficiency and scalability already built in the system.

One caveat: I expect this implementation to slowly start differing more and more from Zcash’s orchard implementation as time goes by and updates are shipped into each code base. It’s the natural expected path for a fork, which has pros and cons.

Cons: Dash’s implementation doesn’t have the native dev-capital that built the original solution they’ve forked and are now using. Zcash-related improvements may not be added in the future, either due to compatibility issues with the moving code base, or due to the lack of specialized contributors, who are focused on Zcash. The same goes for bug fixes and security audits.

Pros: At the same time, Dash’s Orchard can move faster for Dash-specific needs and adjustments. Becoming more and more unique, requiring a different set of skills and source code knowledge, meaning it may see performance and scalability benefits sooner, given Dashpay’s focus on these attributes.

Overall, both ecosystems can benefit from this fork.

Zcash developers can watch what Dash developers are building and treat Evolution as some sort of testnet for experiments around speed, scalability, and shielded tokens, which are being researched by ShieldedLabs, for example. Meanwhile, Dash can already benefit from ZEC’s mature shielded pool and further open-source development to strengthen the privacy offerings for its users and builders.

We all win with more privacy tools built for different needs and the tech advancements that come from experimentation and deployment. These are very interesting times we are living in.

Drop your thoughts or questions in the comments — I’ll answer everything I can, or point you to the right person if I don’t know the answer myself.

Leave a comment

Thanks for reading 「thecoding」!

Subscribe now

Follow me on X at vinibarbosabr and subscribe for free to [en] thecoding.substack.com or [pt-br] codigoaberto.substack.com for more pieces like this.

In this article, we will take a deeper look into storage cost attacks and storage staking on NEAR smart contracts. The goal is to understand the concept of storage into the NEAR Protocol, the storage cost attack vector in smart contracts, and security good practices.

This article is useful for anyone who wants to increase their knowledge on NEAR:

• NEAR enthusiasts

• NEAR users

• NEAR builders

• blockchain developers

• security researchers

• smart contract auditors

• bug bounty hunters

However, it’s important to note that this article aims to provide an easy explanation for a broader public. Developers and security researchers who want to dive deeper into the things discussed here may need to study NEAR docs and other sources as well.

Subscribe now

NEAR Storage Staking Easily Explained

The blockchain is a shared and distributed database. NEAR is no different than that.

Computers run the node software (the protocol) and connect with other computers doing the same thing in a network to validate and store data (the state). Data can be financial amounts, usually represented as account balances. This is probably the most popular use for blockchains: cryptocurrencies. But it can be anything else.

One way or another, it is still data that needs to be stored by these computers—which consume physical storage space in a disk. Just like happens with our personal desktop computers or mobile smartphones for stored photos, videos, contacts, and messages.

One of the big questions for blockchain architects to answer is: who is paying for this data’s storage cost?

In our personal computer and mobile, we pay for it via the built-in disk that comes with the device or by buying extra hardware like USB flash drives or microSDs. In cloud or host services, we can pay for it via subscription plans with predefined, limited available storage.

So, if you want to store more data, you buy more disk or upgrade your cloud/hosting plan. Blockchains work similarly, but the way to pay for it may vary.

Storage Costs on NEAR vs. Other Blockchains

Many legacy blockchains pass on the burden directly to validator nodes and their usual staking rewards (from fees and token emission). Validators are supposed to pay for storage with these rewards received from block production and that’s it.

NEAR addresses the problem differently.

On NEAR, validators are rewarded with token emission—currently at 2.5% per year over the total circulating supply, providing ~4.5% APY with ~45% of all NEAR in circulation being staked. Gas fees paid in transactions and contract calls are fully burned, creating potential deflationary economics.

Meanwhile, storage costs are paid via storage staking, also known as state staking.

For every 100kb of data stored in a smart contract, the contract needs to stake 1 NEAR in storage staking. This is a hard coded protocol setup that can change via governance votes. A change can be proposed and voted, for example, If physical storage costs or NEAR/USD exchange rate change significantly.

This cost is paid automatically every time a smart contract needs to store more data, staking the required amount directly from the contract’s account balance. The transaction will fail if there isn’t enough NEAR balance to cover these costs. On the bright side, the storage stake can be recovered if data is deleted—which frees space.

Smart contracts can absorb the storage cost alone or they can pass it on to the users. For that, they need to calculate and request users to add enough NEAR in the transaction to cover for the amount of data they will store.

Notably, the near-sdk-rs has environment variables to help with storage management.

env::storage_usage() // ← current storage used by this smart contract in bytes
env::storage_byte_cosy() // ← current storage cost per byte in yoctoNEAR
env::attached_deposit() // ← amount in yoctoNEAR attached to the call
env::account_balance() // ← balance of this smart contract, including attached deposit
env::account_locked_balance() // ← balance of this smart contract that is locked

Nevertheless, smart contract developers still need to be careful while managing its storage, as storage cost attacks are a known attack vector in NEAR.

Security Checklist: Storage Cost Attacks on NEAR Smart Contracts

The storage cost attack vector is an important item in the security docs for NEAR smart contracts development. It has an entire section for itself, and there are three brief checklist items related to storage in the security checklist.

In summary, the checklist warns developers to make sure the contract has enough balance to cover the storage cost as it grows organically, but also to make sure it’s protected against storage drain attacks, which may try to artificially inflate it and cause harm.

How to verify:

• Calculate storage cost for each state change

• Check contract balance before storing data

• Require users to attach deposit for their storage

• Monitor contract balance regularly.

As a critical rule: “If your contract doesn’t require users to cover their own storage costs, attackers can drain your contract’s balance by creating many small storage entries.”

The Attack Vector

Basically, if users are not paying for storage rent, there is an economic imbalance that attackers can exploit. A low-cost data spam can quickly become a high-cost storage for the contract owner.

Imagine an attacker who creates a script that sends thousands of transactions with storable arbitrary data. For each 100kb, 1 NEAR is locked from the contract’s balance. 100MB of data will cost the contract 1,000 NEAR in staked storage and this can be very easily achieved with a script and NEAR’s low gas fees.

The result is an unusable contract, huge amounts of NEAR locked. and a lot of wasted time managing this storage by depositing more stake or deleting data to free space.

Common attack patterns are:

1. Small Deposit Attack

2. Data Spam Attack

3. Collection Growth Attack

The Solution

The solution is simple: contracts must require users to cover storage cost.

Here’s an example:

pub fn add_message(&mut self, message: String) {
    let storage_cost = self.calculate_storage_cost(&message);
    assert!(env::attached_deposit() >= storage_cost, "Insufficient deposit for storage");
    
    // Store the message
    // Storage cost is covered by attached deposit
}

• Calculate the storage cost for the data being stored

• Require users to attach at least that amount as deposit

• The attached deposit covers the storage cost automatically

• Users who want to store data must pay for it

• Implement data expiration or explicit deletion of old data to free storage

• Test with attack scenarios, simulating many small storage operations

This safe-guard should, for example, be added to the near-examples/guest-book-examples/…/lib.rs, which is vulnerable to storage cost attacks as is.

This is it for today! Let me know if you liked this format and topic.

Join the discussion in the comments

Leave a comment

Like and share this article with others

Share

Follow me on X (/vinibarbosabr), LinkedIn (/in/viniciussb90), and subscribe for free for thecoding.substack (en) or codigoaberto.substack (pt-br).

# command for staking using near-cli-rs
# replace <your-account.near>, <amount>, and <signature> placeholders
near staking delegation <your-account.near> deposit-and-stake '<amount> NEAR' thecoding.pool.near network-config mainnet <signature> send

• 600ms to 200ms

• parallelization

• preparation for atomic transactions

In this video I go through what is SPICE, why the Separation of Consensus and Execution matters for NEAR Protocol users, and give an easier explanation on what happens under the hood.

Subscribe now

WHAT CHANGES

⚡️ The first and must obvious improvement is transaction finality.

10-20x faster than VISA, as fast as physical limitations allow a network to be (lightspeed), from 600ms (today) to 200ms (post-SPICE).

🌐 Then, parallelization improves network efficiency and scalability, as many complex transactions can execute in the background at the same time.

One big execution (tx) doesn’t delay other transactions.

⚛️ Looking ahead, SPICE sets the ground for upcoming improvements that aim to bring atomic transactions to NEAR, solving one of the current main criticisms and security concerns for NEAR that is async cross-contract calls.

But this is a topic for another video

EASILY EXPLAINED

I like to think of SPICE as this:
Imagine NEAR is a restaurant’s kitchen.

🧑‍🍳 The chef receives orders from the tables and add them to a list that will guide execution from his team, but he still needs to oversee every single dish and process.

The chef can only receive new orders and add them to the list after his team finishes what they are currently working on.

This is how NEAR is today (simplifying for how a single shard works).

What SPICE allows is that the chef can add new orders in the list while different teams are preparing, in parallel, different dishes or parts of previous orders.

He doesn’t need to check every single delivery.
Just receive the team’s confirmation that execution is done.

---

From a technical perspective, validators can continue producing blocks and agreeing in their ordering (CONSENSUS) even if a complex transaction is still executing in the background (EXECUTION).

Add that to a sharded architectures (which effectively means many kitchens working together for the same restaurant) and the possibilities are huge.

---

Other blockchains already implement some sort of parallelization (solana, sui, aptos...) and monad already has something like SPICE.

But none of them are sharded.

Sharding add some real complexities to implementing these optimizations, but when it’s done right, the benefits are much bigger as well.

Study NEAR.

There is a malware built to steal your crypto from the clipboard ( CTRL + C or copy functions) in two ways:

1. replacing the copied address to an address controlled by the threat actor.

2. sending copied seed phrases and private keys to the threat actor’s server.

—

## EXPLANATION

On (1), you can still avoid losing money even if infected by this malware -- just double-check the address you are sending to.

So, when you try to send transactions to alice by copying her 0x123alice...789 address, the script will change the data inside the windows clipboard to 0x123mallory...789 (mallory is the threat actor).

Double-checking protects you (and you should immediately disconnect from the internet and start scanning your device for the malware, or take it to someone who can help you getting rid of the threat).

(2) is self-explanatory: you copy your seed or private key and the attacker receives it in their machine, so they can later import into a wallet and drain your funds freely.

Once you copied it, it’s done. Not much you can do here.

Subscribe now

## HOW TO FIND THE MALWARE AND PROTECT YOURSELF

Microsoft says one way to spot the malware is finding 4-6 random character folders in /Documents/ with .js and other unknown files and extensions

Be careful out there!

(and never, NEVER, insert unknown USB drivers and autorun USB files, as this is how you can get infected by this malware in particular).

Rhea was formed from the merger of two OG projects: Ref Finance and Burrow and now accounts for roughly 96.5% of all TVL on the NEAR ecosystem.

TRY RHEA FINANCE NOW!

In the piece and in this video, I break down how the platform works across swaps, lending, and liquid staking (rNEAR).

I also go over the tokenomics of RHEA, including the xRHEA and oRHEA system, current stablecoin yields, and the latest numbers as of Q2 2026.

Despite being sponsored, you will find my authentic and honest take on where things stand (including the temporary closed-source decision) and why I believe Rhea Finance is well positioned to benefit from any renewed momentum in NEAR.

If you’re following NEAR or looking at DeFi opportunities in the ecosystem, this article and video gives a clear picture of the current state of its largest player.

The NEAR network has been growing and drawing a lot of attention from the market. Industry leaders have shown genuine interest in the ecosystem thanks to its efficiency, security, privacy, scalability, and technological edge.

Amid all of this, the NEAR token has been performing exceptionally well, with solid price gains and higher on-chain and off-chain trading volumes. In this context, a good chunk of on-chain transactions are happening on a DeFi protocol that’s still relatively unknown to anyone outside the community.

Rhea Finance is the leading decentralized finance platform on the NEAR network. It’s already fully integrated with NEAR Intents and offers fast cross-chain operations with low fees across more than 35 blockchains in addition to the native network. Built-in perpetuals and Zcash DeFi are also part of its stack.

In this article, we’ll check out the current state of the protocol, the RHEA token, and the DeFi opportunities available on the platform.

A Quick (and Honest) Introduction to Rhea Finance

Rhea Finance is a name that popped up recently in the NEAR ecosystem (July 2025), but its roots go back further. The app is the result of a merger between Ref Finance (DEX) and Burrow (lending), with smart contracts live on mainnet since 2021.

Today, the platform is a unified cross-chain DeFi hub thanks to its implementation of NEAR Intents.

Users can swap tokens from the NEAR ecosystem or from over 35+ other blockchains and interact with liquidity pools using the traditional automated market maker (AMM) model you’d find on DEXes like Uniswap.

On top of that, there’s also a system similar to Aave. Users can interact with deposit and loan contracts (lending and borrowing) that automatically pay or charge interest (APY) based on the law of supply and demand—total borrowed versus total available to borrow.

Moreover, the hub has recently launched (June 3) Hyperliquid perps built-in in its platform, allowing Rhea users to fund Hyperliquid accounts and open positions with ease.

The source code for the contracts used by Rhea was open-source until recently (April). The team decided to close it temporarily over security concerns, following AI developments and a wave of attacks against DeFi protocols.

If you know me, you know I’m not a fan of this decision. I criticized the same move from the CalCom team and even published an article on HackenProof addressing exactly this point.

My opinion hasn’t changed when it comes to Rhea’s decision either, and I hope to see the smart contracts open-sourced again as soon as possible. That said, the solution RHEA implemented isn’t one of the worst. In fact, I think they pulled off the code closure in the best way possible, which leaves me pretty optimistic.

In an article published on April 27, the team explained their intention to return to open-source, along with plans to strengthen the contract layer, grant source code access to trusted institutions, and create proofs that users are actually interacting with secure, audited contracts—validated by community members.

FOLLOW RHEA ON X!

In short, the contract will be used as input to generate an encrypted hash. Private audits will attach that hash to their reports to confirm the current state. The community can then verify the input using the same cryptography algorithms and get the exact same hash as output—creating a verification layer that doesn’t replace open-source but can still be really useful.

I myself was promised access to the source code for an independent audit and I’m waiting my turn. I plan to publish something about it when it happens, so follow me on X (@vinibarbosabr) and subscribe to my two free Substack newsletters (thecoding.substack.com and codigoaberto.substack.com) to stay in the loop!

How Liquidity Pools, Swaps, and Lending Contracts Work on Rhea Finance?

Rhea Finance’s core primitives—liquidity pools + swaps for DEX and lending/borrowing—run via smart contracts. Primarily written in Rust compiled to WebAssembly on NEAR, with key contract references like v2.ref-finance.near.

It supports permissionless pools, advanced AMM variants, multi-pool routing, over-collateralized lending with dynamic rates, LP tokens as collateral, and a NEAR liquidity staking protocol and derivative token (rNEAR). Cross-chain access uses NEAR Chain Signatures and Intents for native interactions from other chains without wrapping.

Subscribe now

Rhea Finance Easily Explained

Liquidity Pools & Swaps (the DEX part)

The liquidity pools are a shared digital “pot” (smart contract) holding two tokens, say NEAR and USDC, deposited by everyday users and professional market makers called Liquidity Providers (LPs).

Instead of traditional stock exchange where buyers and sellers must find each other via order books, the pot itself act as the automatic counterparty using math to set prices.

• Want to swap NEAR for USDC? The contract calculates the exchange rate based on how much of each token in currently in the pot (literally the rate between their liquidity supply) and executes instantly.

• LPs earn a small fee on every swap (like a commission for providing the “market”). They receive LP tokens representing their share of the pot, which can be staked for extra rewards.

• Different “flavors” of pots exist: normal ones for any tokens, stable ones for similar assets (like USDT/USDC) with less price variation, and advanced “concentrated” ones that focus liquidity in popular price ranger for better efficiency.

Anyone can create a new pot for any token pair (the permissionless part). Prices adjust automatically. If lots of people buy one token, it gets more expensive in the pot.

SWAP NEAR on RHEA!

Lending & Borrowing

Think of it as a decentralized bank run by code.

• The user deposits (supply) tokens into the lending pool and earn interest automatically from the protocol itself (like a savings accounts).

• Others borrow those tokens but must first lock up more value in collateral than they borrow (e.g., borrow $100 worth of USDC but lock $150+ of other assets, like NEAR). This over-collateralization protects the system against bad debt.

• If the collateral value drops too much (e.g., NEAR crashes), the position gets automatically, partially liquidated (sold off) by anyone to repay the loan and protect lenders.

• Borrowers will see their loan amount increase overtime (borrow APY) and they need to repay the updated amount to unlock their collateral. This repayment adds to the pot and is what guarantees lenders’ interest accrual.

Everything is self-custodial, meaning users keep control via their crypto wallets. The cross-chain implementation allows deposits or interactions from Bitcoin, Ethereum, Solana, Zcash, or other major networks using a NEAR account.

TRY LENDING ON RHEA!

Liquid Staking (rNEAR)

Staking NEAR natively via the protocol is probably the most secure, self-custodial, and decentralized way to get a 3.5%-4.5% APY over your NEAR holdings but has some trade-offs.

NEAR is locked and has a 48-72 hours unbounding period and becomes illiquid, meaning you can’t use it to pay, swap, or supply as collateral. That’s why liquid staking was invented for and Rhea offers its own liquid staking protocol and derivative token. I’ll explain.

Instead of staking their NEAR token to a validator like myself (thecoding.pool.near), holders may opt to stake it in Rhea’s liquid staking contract. Rhea will them distribute it all to a list of handpicked validators, managing the staking rewards itself.

The user receives some sort of an IOU called LST (Liquid Staking Token). Rhea’s is rNEAR. This can be exchanged for NEAR, wNEAR, or any other ecosystem token at any time, used as collateral on Rhea Finance’s lending or transferred to other NEAR accounts (e.g., for payments).

Interestingly, rNEAR has an automated system that makes it increase in value against NEAR, according to the staking rewards the protocol’s contract is receiving—proportional to the network’s staking APY minus protocol fees.

LIQUID STAKE NEAR ON RHEA!

RHEA Tokenomics

The RHEA token launched via TGE (Token Generation Event) in July 2025, right alongside the platform. There were seasonal airdrops rewarding REF and BRRR holders (the tokens from Ref and Burrow, respectively) plus active users of the app.

RHEA has a maximum supply of 1,000,000,000 RHEA (1 billion), with roughly 400 million currently in circulation.

The project’s tokenomics revolve around a three-token system: RHEA, xRHEA, and oRHEA.

RHEA is the exposure token and the project’s core asset that unlocks the functionality of the other two. It can be staked and used to pay for RHEA fees in some cases. This asset captures protocol growth and revenue generated from trading fees, lending, and treasury activity.

Every staked RHEA earns the holder a corresponding amount of xRHEA—like a liquid staking derivative that appreciates in price relative to the base asset over time.

Holding or depositing xRHEA into lending contracts or liquidity pools also unlocks benefits in the form of higher APY, multipliers, or oRHEA airdrops. It serves as valid collateral to increase borrowing power on the platform.

oRHEA is the reputation and points system for Rhea Finance users. It’s non-transferable (soul-bound) and can be converted into RHEA or xRHEA under certain condidtions. Distribution is seasonal and based on the points generated from using the platform.

Right now, staking RHEA is yielding around 3.5% APY and depositing xRHEA into lending is yielding around 0.1% APY—with a total of 124,000 RHEA borrowed from a pool of 75M RHEA deposited.

Lending USDC and USDT can pay up to 10% interest to lenders with a boosted APY powered by xRHEA. Lending ZEC is paying up to 4% under these conditions.

1 RHEA is currently costing $0.015 at the time of publication of this article. Some voices on X see RHEA as the best “beta” play in the NEAR ecosystem—one that should ride and amplify the performance of the native NEAR token.

For example, zhynx describes the project as a $2.5 million mcap monopoly inside a network with a $3 billion market cap, responsible for ~95% of the entire ecosystem’s TVL.

The DeFi State of Rhea in Q2 2026

Data from DefiLlama paints a positive picture for Rhea Finance as the leading DeFi hub in the NEAR ecosystem.

As of this writing, NEAR has $150.25 million in total value locked (TVL). Out of which, $145.08 million (96.5%) come from Rhea smart contracts. It’s a clear dominance and highlights the project’s importance for the chain.

LiNEAR Protocol and Meta Pool Near have the second and third positions respectively, with $59.14M and $52.29M in TVL. Both are NEAR’s leading liquid staking protocols.

Notably, they have more than double of Rhea’s liquid staking TVL ($25.87M), which accrues for only 17.8% of Rhea Finance’s total TVL and 19% of NEAR LSTs—at a total of $137.3M staked in these protocols.

Rhea’s lending has the highest TVL, with $91.38 million, while Rhea’s Dex has $27.83 million.

Overall, the ecosystem’s total value locked has been growing overtime when measured in NEAR, but faces temporary challenges when measured against the US Dollar. As the massively dominating protocol, RHEA’s history is similar—with ups and downs, but growing when measured in the network’s native token, weighted by NEAR’s price performance when measured in USD.

I honestly believe RHEA may benefit a lot from the current momentum, as soon as macro conditions improve. With an increased market interest and demand for NEAR, Rhea is very likely the first ecosystem project to see direct benefits, which may impact its own token’s performance.

I’m cautiously optimistic. “Cautiously” because of macroeconomics and the temporary closed source code. Optimistic because NEAR is gathering momentum, Rhea Finance’s team has been shipping and demonstrating solid work even under adversarial conditions, and because much of the ecosystem’s DeFi volume will inevitably rotate through the platform.

Let me know your thoughts in the comments and make sure to try using RHEA! I would also love to know your experience there.

Leave a comment

I spent three years learning to hack and in this article I explain what I think is coming and give the roadmap for security research. The article was published as a guest post published on HackenProof’s blog, exploring my journey as a technical writer diving in security research.

https://hackenproof.com/blog/how-to-become-a-bug-bounty-hunter

READ THE ARTICLE ON HACKENPROOF

You will find:

- How AI is changing security research
- Why open-source is not dead
- How new hunters can start building real skills

Today, Sui Mainnet experienced a significant network stall triggered by what looks like a failure in its settlement process.

The root cause, seems to center on gas underflow combined with accumulator underflow during address-balance gas payments.

As of this writing, the network had been halted for approximately 7 hours based on on-chain data from the last confirmed checkpoint → JADcW9fZqJRf6khgBsagfxSx8xpq6EfbK7FDvySxuy3L

Validators across the network hit a fatal assertion, stopping consensus and checkpoint production while the core team worked on a fix. User funds remain completely safe—this was an accounting invariant violation, not a loss of assets.

Subscribe now

TL;DR Easily Explained

Todays problem was a technical mix-up in how the system handles gas fees and an internal account balance tracker called the accumulator.

• Some users paid gas using a newer “pay from your address balance” feature.

• One (or more) of those transactions ran into an error early and tried to cancel.

• Because of a bug, the system still recorded a small withdrawal from the user’s balance — even though the transaction was failing.

• This made the internal balance tracker go negative for some accounts (which is never allowed).

• When Sui tried to “settle” everything at the end of the checkpoint, it hit a hard stop and crashed all the validators.

What Happened: A Technical Breakdown Based on GitHub Activity

Sui’s architecture relies on a sophisticated gas and settlement system to handle high-throughput execution. Two key internal components are at the center of today’s incident:

• The Accumulator: Implemented in the Sui framework (`accumulator.move`), it tracks net balance changes for addresses/accounts during transaction execution and final settlement at checkpoint boundaries. It aggregates merges (deposits/credits) and splits (withdrawals/debits) in a base value.

  • The thing is: `value + merge - split` must never go negative. Any violation during settlement triggers a failure in the `construct_and_execute_settlement` path, which is designed to never fail—leading to a node-fatal panic.

• Gas Underflow: This occurs in the gas metering and charging logic (primarily in `gas_charger` and `deduct_gas` paths). When a transaction aborts early—such as with `InsufficientFundsForWithdraw` (IFFW)—an “AB-filter” (address-balance filter) drops invalid payment entries. In certain edge cases involving the newer address-balance gas payment flow (which can use `FundsWithdrawal` arguments or coin smashing), the system could still attempt to deduct more gas than remained available, causing a u64 arithmetic underflow in Rust.

I spotted a bunch of emergency PRs (26811–26819) on Sui’s repo today, providing a forensic trail we can use to speculate on what’s going one while we wait for the official postmortem.

These changes directly address the failure path involving address-balance gas payments, early aborts, accumulator underflow, and settlement diagnostics. While the exact triggering transaction has not been publicly confirmed, the PRs allow us to reconstruct the most likely sequence of events:

1. A user transaction (or batch) paid gas using the address-balance / `FundsWithdrawal` method and hit `InsufficientFundsForWithdraw` during execution.

2. The AB-filter correctly dropped some invalid payment entries, but the pre-fix gas-smashing/withdrawal logic still performed (or recorded) a withdrawal from the address balance even though the transaction was aborting early.

3. This produced an invalid net funds change that fed into the accumulator (`value + merge - split` underflowed for one or more accounts).

4. At checkpoint settlement time, the `construct_and_execute_settlement` transaction (supposed to never fail) hit the accumulator underflow. This triggered a `fx.status().is_ok()` assert → node-fatal panic across validators → full network halt.

The Fixes: Key Code Changes Explained

Here are the most relevant code changes from the emergency PRs, with direct explanations: \

1. Core Bug Fix – Prevent withdrawal from address balance on early abort
(PR #26818: “Do not withdrawal from address balance when transaction aborts early”; also referenced in the related #26816)

In sui-execution/latest/sui-adapter/src/execution_engine.rs:

// On an early `InsufficientFundsForWithdraw` abort we drop every address-balance
// payment except the smash target (index 0). ...
if matches!(
    execution_params,
    Err(ExecutionErrorKind::InsufficientFundsForWithdraw)
) && gas_data.payment.len() > 1
{
    gas_data
        .payment
        .retain(|entry| ParsedDigest::try_from(entry.2).is_err());
}

This change ensures that on an early IFFW abort, address-balance withdrawals are not recorded in the accumulator. The prior behavior allowed a partial withdrawal to be logged even as the transaction aborted, violating the accumulator invariant downstream.

2. Gas Charger Hardening – Clamp gas_budget to prevent deduct_gas underflow
(PR #26819)

In crates/sui-types/src/gas.rs:

/// Lower the `gas_budget` if `new_budget` is smaller...
pub(crate) fn reduce_gas_budget(&mut self, new_budget: u64) {
    if new_budget < self.gas_budget {
        self.gas_budget = new_budget;
    }
}

And in GasCharger::new:

if let PaymentMetadata::Smash(metadata) = &payment
    && metadata.total_smashed < gas_status.gas_budget()
{
    gas_status.reduce_gas_budget(metadata.total_smashed);
}

After the AB-filter drops entries, the signed `gas_budget` could exceed the remaining smashed coins. This clamp prevents later subtraction code from underflowing.

3. Replay Safety – Gate the fix on accumulator version
(PR #26817)A new constant was introduced:

const ADDRESS_BALANCE_SMASH_FIX_MIN_ACCUMULATOR_VERSION: u64 = 692949576;

The fix is applied only for transactions whose accumulator version meets or exceeds this threshold. This prevents replay forks on already-certified history while allowing immediate safe behavior on new transactions—no epoch or protocol version change required during the live incident.

4. Emergency Recovery Tools
(PR #26811)

Hardcoded skips for specific consensus rounds:

const HARDCODED_SKIPPED_CONSENSUS_COMMIT_ROUNDS: &[u64] = &[824333];

Plus a new config flag to temporarily disable address-balance payments entirely. These acted as “kill switches” to drop the problematic transactions and resume checkpoint production.

5. Improved Diagnostics – Why settlement failed
(PR #26814: “debug(settlement): diagnose accumulator underflow on settlement failure”)

New helper in crates/sui-core/src/execution_scheduler/settlement_scheduler.rs:

fn log_underflowing_accounts(
    &self,
    fx: &TransactionEffects,
    funds_changes: &BTreeMap<AccumulatorObjId, i128>,
) {
    // Logs each account where projected balance (balance + funds_change) < 0
    // including the exact shortfall
}

And `dump_batch_transactions` to output every transaction in the settlement batch along with its `accumulator_events().

These run right before the fatal assert, providing visibility into exactly which account underflowed and which user transactions contributed—critical because a Move abort normally clears effects.

Remember: this is all speculation based on code activity and not the official postmortem.

Thanks for reading!

Follow me on X (vinibarbosabr) and subscribe for free to thecoding.substack.com for more.

I have been wanting to write about Ika for a while now.

The opportunity finally came up now that the project is migrating from Sui to Solana and conversations about security in MPC (Multi-Party Computation) solutions have heated up following the exploit against THORChain's MPC.

So, let's break down what Ika is and why it matters right now. As always, I'll cover the technical side and explain how everything works in an easy way.

Subscribe now

If you follow my content, you know I'm a big fan and active user of NEAR Intents and other cross-chain protocols (like THORChain and Maia Protocol), plus I'm a NEAR validator. None of that changes with this article, even though there's some obvious competition between these projects.

I don’t mind, really. IKA is a genuinely impressive project that deserves the highlight (just like NEAR).

As a user and researcher, I love the redundancy here. It's healthy to have strong projects competing to deliver the best solutions, each making different trade-offs — giving us the flexibility to use whichever one (or all of them) makes the most sense depending on each situation.

Enough with the intro, let's get into the IKA protocol!

Meet IKA: Bridgeless Capital Markets

“Ika enables a bridge-less capital market,” is how the team positions the product that is now focused on Solana infrastructure, while promising to “move value between any blockchain without bridges, wrapping, or centralized custody. Powered by dWallets and 2PC-MPC cryptography.”

I’ll explain.

The core idea here is to abstract away the fragmentation between different crypto networks. You get a single wallet (dWallet) running on one network (Ika), secured by strong cryptography, that can control native accounts across many other blockchains.

IKA is a decentralized network of MPC signers. It functions as a trustless cryptographic bridge between chains, but it’s not a bridge in the traditional sense we’re used to in crypto.

Think of it as a shared, programmable signature service running on its own chain (a fork of Sui).

The signers work like validators in a traditional blockchain. They stake a minimum amount of the token (40M IKA, currently) and get the right to sign transactions in the network’s behalf. We will expand on that soon.

Right now the network has 68 active operators (producing signatures) out of 115 total operators. Anyone can spin up a node and join — it costs roughly $100–200/month in rented hardware, according to David Lachmish, CPO of dWallet Labs.

There’s already 4.91 billion IKA staked, and the top five operators control about 11.5% (~567 million). However, the signing capacity is not influenced by the staking amount. Worth noting: some of these operators are controlled by the same entities. For example, dWallet Labs runs five operators under the labels “dWallet Labs 1 through 5.”

Then, instead of relying on centralized custodians, traditional bridges, or small trusted committees, IKA lets smart contracts and users control native accounts on other networks (Bitcoin, Ethereum, Solana, Sui, etc.) through a decentralized network.

Even better: without ever exposing the full private key to any single party (it's not really a private key, we will get there).

This opens the door to advanced cross-chain operations while keeping solid security and decentralization standards. That’s especially relevant in a world where bridges have been responsible for the largest share of stolen funds from hacks and exploits. The “Bridgeless Capital Markets” north star makes a lot of sense and feels genuinely valuable, in my opinion.

The approach is similar to the MPC solution behind NEAR Intents and Chain Signatures (which I’ve written about before), but with some key differences, of course. The two biggest ones:

1. IKA is a permissionless network — anyone can participate by running a node and staking or receiving delegations.

2. It uses the 2PC-MPC Protocol (implemented by dWallet), which enables the Zero Trust setup where the user also holds private key shares in a 2-of-2 signing threshold. More on that below.

dWallet and the 2PC-MPC Protocol

Before we go further, it’s worth clarifying the solution is not built for casual retail users, but aimed at developers and advanced users who are fine with programming and the CLI (command line interface).

On that, there is no colorful, cute dWallet mobile app you can just download and tap around in your iPhone. Anyone can create and use a dWallet through the CLI (I did it myself while testing), but the target audience right now are developers building on Solana (and previously on Sui).

Nevertheless, it’s still useful to understand how the piece of software running inside your favorite wallet works, even if you’re not a developer.

SETUP A DWALLET ON SOLANA

How dWallet Works

dWallet is the main product built on top of Ika and is basically the interface that gives meaning to it. You (the user) can use this interface for three types of wallet that dWallet allows:

1. Imported Key: This mode happens when the user does not generate a new key by dWallet, but imports a seed or private key generated in other traditional crypto wallets. It’s useful mostly for self-custody applications.

2. Zero Trust Mode: This mode uses the 2PC-MPC protocol and generates two shares of the private key through a Distributed Key Generation (DKG) method. One for the user (you) and the other for the MPC network (Ika). No part can see the share of its counterpart and both are needed to sign valid transactions (2-of-2 threshold).

3. User’s Public Share: This one follows the same premise of the second, generating two shares of the private key. The difference is on how the user share is stored. Here, it is stored publicly in the blockchain (e.g., in a smart contract) and can be called by apps or other programs to sign transactions for the user, while Ika’s MPC continues guaranteeing its safety.

Our focus here will be to understand the Zero Trust mode because it is the project’s biggest competitive advantage and also helps to understand the third mode — which we can explore in a future article.

Ika’s Zero Trust Mode

I like to think of it as a safe vault that requires two combinations to open. One by the vault’s owner (you) and the other by a company specialized in vault security (Ika).

When the safe was first configured using a system developed by this company, you entered a dark room, alone, and generated your combination. The other share was generated the same way by an automated system in the company’s database and immediately encrypted before being stored.

Therefore, what the company stores is actually the encrypted version of their combination share and not the combination itself (in plain text). The signing happens using something called homomorphic encryption — performing signing operations on encrypted data without ever decrypting the company’s combination. The MPC network share never gets exposed.

To open the safe, you first need to insert you combination and call the company to do the same. After receiving your request, Ika will call a council made by its operators, where each one has the right to one vote. With two-thirds of the votes, the signing is done and the second combination is inserted, opening the safe.

The full combination is never reconstructed in one place. Everything is encrypted with strong cryptography, and each part’s share is protected from the other part, creating mutual, zero-trust relationship. Beautiful!

Interestingly, you can also store the user share with redundancy in different places with more confidence, as a leak is not as harmful as it usually is in normal crypto wallets because the network share is still needed to move funds.

David recently explained that on X.

Likewise, dWallet allows the user to set custom policies for its use and interactions, all programatically. This policy may enable more complex operations (in DeFi, for example), more or less security according to the user's needs, and other interesting features.

There’s one important limitation that applies to pretty much every MPC solution:

The user will always need the second half of the key held by the Ika operators. That means we can’t just export a full private key and import it into a regular wallet the way we’re used to in crypto.

Unless when using the self-custody, imported key mode.

In short, dWallet controls addresses on other chains by generating valid signatures (ECDSA, EdDSA, Schnorr, etc.). DKG generates two shares (user and network) with secrecy. The wallet is also programmable and transferable — the user can transfer control to someone else with safety.

Also, the public key is derived as usual and looks exact the same as public addresses from the supported networks (Bitcoin, Ethereum, Solana, Sui, etc.). No over-complication for the user while managing crypto addresses and receiving payments.

There’s more interesting detail worth covering (pre-computed MPC signatures for improved performance, wallet transfers and other functionalities, for example), but this article is already getting long. I’ll save some of that for a follow-up if there’s interest. I would also like to write about the economics around IKA’s token.

Yet, I hope this one gave you a solid first look at the project and got you curious to dive deeper.

My Take on IKA

The project feels solid, technologically innovating, and genuinely promising. The team comes across as highly competent, with cybersecurity and engineering backgrounds, and they love to discuss and explain these and other things on X.

FOLLOW IKA ON X

IKA is easily one of the few projects I have in my radar this cycle. I’ve been studying and discussing it for a while (especially with David), and the solution feels elegant on multiple levels.

Decentralization, permissionless network, cryptographic security, and open-source development (a lot of it in Rust, btw) are all things I value a lot.

The move to Solana makes complete sense (though I’d still love to see native dWallets on NEAR someday, lol). I’m confident we’ll be hearing a lot more about IKA in the months ahead.

Drop your thoughts or questions in the comments — I’ll answer everything I can, or point you to the right person if I don’t know the answer myself.

Leave a comment

Thanks for reading 「thecoding」!

Follow me on X at vinibarbosabr and subscribe for free to [en] thecoding.substack.com or [pt-br] codigoaberto.substack.com for more pieces like this.

+ price is going up, which is great

+ NEAR is building amazing stuff in privacy and AI

But not everybody is talking about what I believe is one of the most exciting developments in blockchain infrastructure → DYNAMIC RESHARDING.

Here’s what is happening and why it matters ↓

Subscribe now

A blockchain network is only useful if it can be used at scale

Price going up and influential crypto people talking about near is cool, but if all the new users and investors that will come from that can’t use it flawlessly -- it becomes meaningless.

NEAR needs to be able to continue working under high load (and it has, with no downtime since mainnet launch in 2020).

However, NEAR is building to become the place were millions of agents will transact, make payments, call smart contracts, and do other onchain operations.

So, it needs to improve how it scales.

Right now, new shards are added mannually (as was done in April 2025, adding the 9th shard after splitting shard 0).

Manual resharding takes a lot of time, coordination efforts, and solid code writing and reviewing to prevent bugs.

By the end of Q2 2026, NEAR will start to do all that automatically.

• demand increased?

• near has more users?

• needs one more shard?

done. automatically. at the protocol level. securely.

No other chain can do that (yet).

This is why it matters.

UPDATE!

The video and post below were made before THORChain’s official report and are based on independent community investigations using only publicly available information. We now have more details suggesting the exploit targeted THORChain’s MPC infrastructure, which became possible because they never updated a TSS library (the MPC signature scheme) in the THORChain source code—even though the vulnerabilities in it had already been fixed earlier.

THORChain had ~$10M drained from one of its vaults.

Let's take a look at what happened, the exploit, and the interesting timeline of another vault churn/migration security issue discussed in THORChain's gitlab repository that I discovered earlier today and posted on X:

THORChain is one of the most used decentralized cross-chain networks, which makes these events super relevant to the entire ecosystem!

According to /theoblivionsage's analysis, the attacker was able to get _vaultAllowance over a THORChain vault during what looked like a legit ERC20 vault migration.

Allowance was given via an Ethereum transaction caling the transferAllowance() function, allowing the attacker to sign outbound transactions from this THORChain vault they now control.

Think of it like a company that has a bank account.

Interestingly, the attacker operated the vault as a legit validator for 2 days before executing the drain.

/banteg points the exploit to a commit (af46db22) from 6 days ago in the thornode repository by THORChain on gitlab: fix(common): sign full ObservedTx wrapper to prevent proposer forgery.

The rest is history.

I really hope the THORChain devs can come out stronger from this hack (and I believe they will) as the chain and RUNE are really important to crypto's decentralization as a living ecosystem, in general.

I'll keep monitoring the situation and posting about it.

Make sure to follow me on X and subscribe for free to [en] thecoding.substack or [pt-br] codigoaberto.substack.

By the way, I only got to know about this bug thanks to Mullvad VPN’s post on X earlier today, which is a strong reason to keep sharing and educating others on what’s going on.

So, Mullvad posted about the issue on May 12, but the original report has been live since April 30 on lowlevel-fun as “The Tiny UDP Cannon: An Android VPN Bypass.”

Interestingly, the reported issue [510393733] on issuetracker.google now has an “Access is denied to this issue” message, meaning Android Security Team has deliberately hidden it from the public. This happened after the team closed the issue as “Won’t Fix (infeasible)”. GrapheneOS has already released a patch that fixes it, though.

Anyone can reproduce the exploit using cybaqkebm’s open-source PoC at 0x33c0unt/quic-vpn-bypass on GitHub.

How to Fix Android’s VPN Bypass

To fix it you will need to debug your Android via terminal and you should only do it if you understand the implications of changing device config files. Follow the steps below (on Linux only, as I don’t know how to access it via WIndows or MacOS):

1. Install android-tools or other Android debugging tools. On Arch Linux I ran:

sudo pacman -S android-tools

2. Go to your device → Settings → About Phone → Software Information

3. Look for the “Build Number” field and click seven times on it to enable “Developer Options”

4. If using Samsung, go to Security and Privacy and disable “Auto Blocker”

5. Back to Developer Options, enable USB Debugging

6. Connect the device via USB cable to your Linux and authorize access (trusted device)

7. On your Linux terminal, check if the device is connected using Android Debug Bridge’s command:

adb devices

8. Still on terminal, execute the code that will disable Android’s close_quic_connection feature with the -1 flag and reboot the device:

adb shell device_config put tethering close_quic_connection -1
adb reboot

9. To check if the new config was applied, look for a false boolean to “Close QUIC Connection”:

adb shell dumpsys connectivity | grep "Close QUIC"
## Close QUIC connection: false

10. You can revert the config and test the other way around by force-enabling the function with the 1 flag.

adb shell device_config put tethering close_quic_connection 1
adb reboot

Thank you for reading and watching the video!

Share

Follow me on X at vinibarbosabr and subscribe for free to thecoding.substack [en] or codigoaberto.substack [pt-br].

On May 5, more details were publicly disclosed about a high-severity vulnerability in Bitcoin Core code, the Script Interpreter Remote Crash (CVE-2024-52911).

The bug was discovered by Cory Fields (theuni on GitHub) in November 2024, and the fix was shipped in April 2025 with Bitcoin Core version 29.0.0.

However, data from bitref.com shows that over 32% of Bitcoin nodes are still running unpatched versions older than v29 — meaning they’re still exposed to the bug.

According to Niklas Gögge, this was the first memory-safety bug in Bitcoin Core’s C++ codebase. The Rust community (a language that fixes many memory-safety issues) is already using the moment to push for porting Bitcoin to Rust.

But what exactly is this bug, how does it work, and what attack vectors does it open up for the Bitcoin network?

Subscribe now

What Is the Script Interpreter Remote Crash (CVE-2024-52911)?

Bitcoin nodes are basically computers (or servers) running Bitcoin software (mostly Core or Knots) connected to each other. Together, they form the Bitcoin network.

These nodes validate blocks and transactions sent by miners to make sure they’re legit. Valid blocks get stored on disk and become the permanent transaction record for the whole network — basically the ledger that tracks every BTC balance in every wallet.

When a node receives a block, it has to check every transaction against the protocol rules. To make this efficient, the validation happens as a background thread through CScriptCheck.

Think of nodes like a logistics warehouse that receives trucks (blocks) packed with packages (transactions) that all need to be inspected and stored. The warehouse manager has other duties, so he hires a team of workers to handle the package checks in the meantime (the script check).

To know what to do, the manager gives the workers an instruction sheet. That sheet is the PrecomputedTransactionData function, which stores a bunch of pre-calculated data to speed up transaction validation. Every action the CScriptCheck workers take points back to more detailed info on that precomputed data “sheet.”

On top of that, the manager also hired a supervisor to oversee the whole operation. In code terms, that’s CCheckQueueControl.

The whole system runs smoothly as long as the node only receives valid blocks with valid transactions. The problem shows up when an invalid block arrives and needs to be thrown out.

This stems from how C++ handles objects that need to be removed (destroyed) from memory. Destruction happens in the reverse order the objects were created.

In our analogy, the manager first hired the supervisor (CCheckQueueControl), then the workers (CScriptCheck), and finally handed out the precomputed data sheet (PrecomputedTransactionData).

When the invalid block has to be discarded, the manager throws away the data sheet first. Now both the workers and the supervisor are left pointing at instructions that no longer exist, creating total chaos.

At the code level, the script-check pointers now point to data that’s already gone, so the node crashes and restarts. If done on purpose, exploiting this vulnerability creates a denial-of-service attack.

Some theories also suggest a skilled attacker could achieve remote code execution (RCE) on the affected server — for example, installing malware or other exploits. In theory this is possible, but the Bitcoin protocol’s handling of arbitrary data makes it much harder in practice (that’s a topic for another post).

Any node running outdated software (pre-v29) is vulnerable. Updating to a patched version fixes the issue and stops the node from crashing.

Check out the video version of this article.

I hope this made the situation with Bitcoin crystal clear. If it helped, drop a like, leave a comment, and share it with your friends so more people understand the bug.

Share

Thanks for reading 「 thecoding 」!

A high severity vulnerability was found and publicly disclosed

In this video I (try to) easily explain the bug and what’s happening with the BTC network around the Script Interpreter Remote Crash (CVE-2024-52911).

+ 32% of all Bitcoin nodes are still running an unpatched version, per bitref-com data

+ this is a memory safety issue, related to C++

+ should Bitcoin be rewritten in Rust?

Article may be published soon with the explainer on X (/vinibarbosabr) and at both thecoding.substack (en) and codigoaberto.substack (pt-br).

Which one is the best one, though?

+ TAO
+ NEAR

It depends...

This article that I wrote in April has been one of my most read articles so far, so I decided to try this new format going through the research in a commented, no-edition video.

Let me know if you like this new format and if I should do more of it for my other articles as well.

Share