xpert.page - Latest Articles

Xahaud & Its Exclamation Points!

Hodor — Tue, 23 Jun 2026 14:17:51 GMT

The latest release notes for Xahaud, the code base for the Xahau network, contained a list of items that were very well-received by the developer and fan base ...

... and two items received an exclamation point by Richard Holland, chief architect of the Xahau network:

IOURewardClaim

Xahau has long offered a native balance rewards system for its no-counter-party asset, 'XAH'. It amounts to - roughly - 4% per annum paid to all XAH holders.

"IOURewardClaim" extends this same mechanic to issued tokens. Issuers can now optionally enable reward logic for their own currencies, calculated based on hold time and amount.

This means any project - a stablecoin issuer, a DAO, a DeFi app - can build loyalty programs or yield incentives directly into their token, powered by the protocol itself rather than through smart contracts.

NamedHooks

Hooks are small, efficient WebAssembly (WASM) modules that add smart contract functionality to Xahau - they can block or allow transactions, track internal state, and even autonomously initiate new transactions.

"NamedHooks" lets developers assign human-readable names to specific Hook functions during installation, so an incoming transaction can call a particular Hook by name.

The result?

Multiple distinct behaviors coexisting on the same account - a payment Hook, an admin Hook, a compliance Hook - all modular and independently invocable.

Tequ's Corner

The release notes called out one code contributor, in particular: Tequ, who also provided his own take on several items in the release notes:

Better And Better

Together, these code improvements push Xahau closer to a platform where both issuers and developers have expressive, composable, protocol-native tools at their disposal.

For code contributors to Xahaud, seeing these pieces click into place is the kind of thing that earns an exclamation point. X>

Sources

https://x.com/RichardXRPL/status/2068957252145631574?s=20

Richard Holland's tweet announcing the release: https://x.com/RichardXRPL/status/2068957252145631574

https://github.com/Xahau/xahaud

https://x.com/RichardXRPL

https://x.com/_tequ_

Q & A With The Creator Of xahau-mcp

Hodor — Mon, 15 Jun 2026 21:42:49 GMT

I was startled ... by a very positive announcement!

It was a post from a community developer whose content had ended up on my FYP intermittently ... it was exciting news, in the form of a multi-part thread explaining his accomplishments in compartmentalized chunks:

When I started digging into what he'd accomplished, my amazement continued to grow - he has single-handedly, it seems - contributed several key development tools that will supercharge hooks development on Xahau! 😳

When I reached out to him over 'X', he was gracious enough to do a written Q&A with me.

Here is that Q&A, verbatim.

Question: What's your background with the XRP Ledger and Xahau?

Answer: I've been in the XRPL since 2020 - started as an investor, then got pulled deeper through X Spaces, following the news and learning the ecosystem.

I remember David Schwartz talking about Hooks coming to the XRPL and being genuinely excited about programmable logic on the ledger. When Hooks didn't make it to XRPL mainnet I was disappointed - but that's exactly what gave us Xahau, so it worked out. Along the way I launched an NFT project on the XRPL, and I host an X Space when time allows. So Xahau and Hooks weren't a pivot for me; they're the thing I'd been waiting on since Schwartz first described it.

Question: What motivated you to create xahau-mcp & the Flight Simulator?

Answer: Two gaps.

First, there was no MCP (Model Context Protocol) for Xahau at all - AI agents had no structured way to read the ledger, decode HookOn, or reason about Hooks.

Second, and bigger: there was no way to know what a Hook would do before you signed. Hooks are real WASM smart contracts that can reject or reshape your transaction - but you found out on-chain, after the fee burned. So I built the Flight Simulator: it runs a transaction's actual Hook bytecode in a local VM against live ledger state and tells you the accept/rollback outcome before you sign. As AI agents start moving real value on Xahau, "simulate before you sign" stops being a convenience and becomes a safety requirement.

Question: What feedback have you received from other developers thus far?

Answer: The response on X has honestly exceeded what I expected - encouragement and attention from developers I deeply respect, including Wietse, Tequ, Fomo and others. The one that floored me: when I launched xahc-prover - the tool that formally proves a Hook is safe - Richard Holland, who designed Hooks, engaged with it publicly and encouraged me to keep adding invariants.

Richard is the reason any of this is even possible: he made Hooks not-Turing-complete and guard-bounded, which is the exact property that lets you prove them. Having the people who shaped the XRPL and Xahau ecosystems take an interest has been both validating and motivating. It tells me the gap I was trying to fill is one the community actually feels.

Question: Any plans to create a website endpoint for public use?

Answer: It's already running.

The simulator sits behind a hardened HTTP shim - sandboxed WASM execution with hard timeout and memory caps, rate-limiting, read-only, never signs - deployed on Railway and integrated into Kairo Vault's Hooks Lab. So today you can paste a compiled hook's WASM and have it analyzed and run as real bytecode without spinning up a node or the MCP locally.

The next step is standing up a raw public API endpoint anyone can hit directly - including the full live-ledger simulation path.

Question: Are you working on any other (unrelated / related) projects on Xahau?

Answer: Most of my work lives under Kairo Vault - my broader effort to build tools for users and developers across both the XRPL and Xahau. xahau-mcp is one piece of what's become a four-tool toolchain for safe Hooks — a quartet that takes a Hook from idea to deployed:

xahc ("Xahau Hooks, Checked") - the authoring side: write a safe C Hook, build it, lint it, test it, and emit a ready-to-sign install transaction. xahc writes the Hook, xahau-mcp audits and simulates it. Already testnet-proven: an AI-agent spending-guardrail Hook installed and enforced its own limit on-ledger.
xahc-prover - the part I'm proudest of. xahau-mcp simulates one transaction; xahc-prover proves a Hook is safe for every possible transaction. It symbolically executes the real compiled WASM and uses an SMT solver to either prove a safety invariant holds - spend limits, destination locks, no double-spend, balance conservation, and more - or hand back the exact transaction that breaks it.
It's only possible because Hooks are bounded and decidable. And it fails closed: anything it can't model soundly returns INCONCLUSIVE, never a green check it didn't earn.
evernode-mcp - the build layer above the Hooks: scaffold, lint, cost-estimate, and deploy HotPocket dApps on Evernode, with a determinism linter so a contract doesn't stall consensus across
nodes.
x402-xahau - making Xahau a settlement chain for the x402 agent-payments protocol, with a guardrail Hook as the layer-1 spending authority.

The thread tying it together: as AI agents start transacting autonomously, Kairo Vault is building the safety and tooling layer for them to do it on XRPL and Xahau - write the on-chain rules (xahc), simulate before signing (xahau-mcp), prove them safe for all inputs (xahc-prover), build and deploy the dApp (evernode-mcp), and settle within policy (x402-xahau). All four core tools are open source and MIT-licensed.

Question: How is "proving" a hook different from testing it?

Answer: Testing checks the cases you thought of. Proving checks every case there is. A test suite for a money-Hook might fire a few hundred transactions at it; an attacker only needs the one you didn't write. xahc-prover closes that gap. It symbolically executes the real compiled WASM - every branch at once, with the inputs left as unknowns - and asks an SMT solver a single question: is there any transaction that reaches "accept" and still breaks the rule? If the answer is no, that's a proof for all inputs in scope. If it's yes, you get back the exact transaction that breaks it - a real counterexample, not a vague warning.

It checks fourteen invariants today - things like spend limits, destination locks, no double-spend, balance conservation, authorization, reserve safety. And the part I care about most is what happens at the edges: if the prover hits anything it can't reason about soundly, it returns INCONCLUSIVE, never a false "proven." A verifier you can't trust is worse than no verifier, so it fails closed by design. I also reproduced several of its verdicts on the live Xahau testnet - sent the exact transactions it described and the chain agreed - so it's not just math in a vacuum.

None of this would be possible on a chain like Ethereum, where the halting problem means you can't prove an arbitrary contract. Richard made Hooks not-Turing-complete and guard-bounded, so their behaviour is decidable. Bounded execution was always quietly a superpower - xahc-prover is what it unlocks.

Question: Where does evernode-mcp fit?

Answer: The first three tools are about the Hook itself - the on-chain logic. evernode-mcp is the layer above it: the actual application.

Evernode lets you run dApps (HotPocket smart contracts) on hosts secured by Xahau, and evernode-mcp gives an AI agent or a developer a structured way to scaffold one, lint it, estimate what it'll cost to host, and deploy it.

The hard part on Evernode is determinism.

A HotPocket contract runs on many independent nodes that have to reach the same result, byte for byte - so an innocent-looking thing like reading the system clock, iterating a map in hash order, or a locale-dependent sort can quietly break consensus. evernode-mcp ships a determinism linter that flags those patterns before they bite, plus a set of templates that are already clean. I want to be precise here: that's a linter, not a prover - it catches known non-deterministic patterns, it doesn't mathematically prove determinism.

The settlement Hooks in its templates, though, do run through xahc-prover, so the on-chain money logic of a dApp can be formally proven even while the off-chain app logic is linted. Together that's the full span: prove the rules, ship the app.

And it all points back to one home: I plan to integrate the full quartet into www.kairovault.com, so writing, simulating, proving, and deploying a Hook becomes one continuous workflow in the browser - no local toolchain required. The Hooks Lab is already the first piece of that; the rest of the quartet lands there next.

My Take: Incredible Tools For New Hooks Developers

The addition of xahau-mcp and its suite of components, tools, and techniques, represents a powerful and immense leap forward for hooks development on Xahau.

New developers will now have, at their fingertips, the ability to rigorously - and easily - test Evernode dApps & Xahau hooks before deployment, thereby providing an additional layer of confidence in their code and applications. Ultimately, it will be the end-user stakeholders of Evernode & Xahau that benefit the most, from a wide variety of applications that use hooks and Xahau in the background, invisibly benefiting from a highly-efficient development process.

If you or a friend want to try vibe-coding some hooks, now is the time. X> | E >

Sources:

Q&A via 'X' DM ( Hugegreencandle@Cryptocrazy589 on 'X')

Introductory thread: https://x.com/Cryptocrazy589/status/2065012486479175777?s=20

The github repository link: https://github.com/Hugegreencandle/xahau-mcp

The github repository link for the flight simulator: https://github.com/Hugegreencandle/xahau-mcp/releases/tag/v2.0.0

"MCP" = "model context protocol", defined here: https://modelcontextprotocol.io/docs/getting-started/intro

Deeper dive into the MCP architecture: https://modelcontextprotocol.io/docs/learn/architecture

Plain English guide and tutorial to using the MCP: https://github.com/Hugegreencandle/xahau-mcp/blob/main/docs/TUTORIAL.md

Kairo Vault website: https://www.kairovault.com

One Xahau

Hodor — Thu, 04 Jun 2026 19:16:56 GMT

⚠️ As with all my articles, this does not constitute financial advice. Please consult a financial expert before making any financial decisions.

"DeFi"

Decentralized finance - DeFi - has become one of the most talked-about concepts in the blockchain world, promising open, permissionless access to financial tools like lending, trading, and yield generation.

For Xahau, a new smart-contract-enabled network, DeFi is arriving right now - and a developer from Atlanta, Georgia is the one making it happen.

One Xahau is one of the first DeFi platforms built natively on the Xahau network. It's bringing a suite of financial products - automated market making, lending, and perpetual contracts - to a network that, until now, had none of them.

Understanding the Xahau Landscape

To appreciate what One Xahau is doing, it helps to understand what Xahau is - and what it's been missing.

Xahau is, in simple terms, a fork of the XRP Ledger, distinguished primarily by its support for "hooks" - compact, event-driven pieces of code that attach to accounts and execute automatically when transactions occur.

You can think of hooks as the Xahau equivalent of Ethereum smart contracts ... but optimized for the speed and efficiency of the XRP Ledger's architecture.

The network's roadmap is ambitious. Features like a native Automated Market Maker (AMM), a Price Oracle, and a cross-chain capability called FeatureExport are all scheduled for release as early as the beginning of Q4 2026 (October). The native AMM in particular is highly anticipated - it would bring on-ledger liquidity to Xahau's decentralized exchange.

But "anticipated" and "available" are two very different things.

Until those amendments pass a network vote and are activated on-chain, the tools simply don't exist in native form. That gap - the space between what the Xahau roadmap promises and what users can access today - is exactly where One Xahau has stepped in.

One Xahau: Filling the Vacuum

The man behind One Xahau goes by the handle Cbot on X, and his path to DeFi development is not a conventional one. By his own account, he's primarily a construction industry professional who recently picked up coding around 2019 or 2020.

His motivation was less about financial opportunity and more about community.

"It kind of grew from there ..."

That's how he described the transformation of the original project into One Xahau during a recent live session on X. His original project was a data aggregator for tokens on the Xahau network, and it has changed into something far more ambitious. Cbot has also collaborated on the technical aspects of his project periodically with another Xahau community developer known as Gadget78.

His stated goal: to galvanize the Xahau community and push the ecosystem forward.

The result is One Xahau, a hook-powered DeFi platform that doesn't wait for native AMM support to materialize.

Not Just AMMs: A Full DeFi Suite

One Xahau launched with three distinct financial products, each powered by hooks running autonomously on the Xahau network.

Automated Market Making (AMM): One Xahau's AMM allows users to contribute assets to liquidity pools and earn fees from trades ('swaps') executed against those pools.

New token pairings can be bootstrapped through a DAO vote, giving the community a direct say in which assets get listed.

What sets this AMM apart from what a native Xahau implementation might offer is that it was specifically designed to serve the One Xahau DAO - a portion of every fee charged by the AMM is automatically routed upward to fund the platform's decentralized governance structure. It also leverages Xahau's inherited XRP Ledger pathfinding capabilities, uses a yield curve to place strategic orders on the DEX, and even counterbalances the natural XAH accumulation that occurs due to Xahau's native balance adjustment rewards.

Very impressive thoughtfulness here.

Perpetual Contracts: One Xahau offers a futures-like product known as perpetuals - leveraged bets on the future price of an asset. Currently, the platform supports longs and shorts on EVR (Evernode's token) priced against XAH.

The pool absorbs wins and losses, and a system of funding rates keeps positions from becoming dangerously lopsided - if one side (long or short) becomes disproportionately large, participants on that side pay higher rates to compensate the pool for the additional risk.

Position sizes are also capped relative to the pool's total size, so no single trade can drain the pool. As Cbot noted during the X space:

"There was a lot of talk about creating a side chain to the XRPL for perps ... Xahau could drive perpetual contracts right now - this could be put in a hook."

Lending Protocol: One Xahau's lending product is a one-sided, collateralized lending system.

Users who want to earn yield contribute to a lending pool. Borrowers then post collateral and take loans of up to 50% of that collateral's value, at a current rate of 10% interest.

If a borrower fails to repay, the hook automatically claims their collateral on behalf of the pool. Notably, the current implementation does not liquidate based on collateral price drops - a feature Cbot is eager to add once Xahau's planned Price Oracle goes live. The 10% interest earned on loans flows directly to LP token holders, making the lending pool an income-generating position for liquidity providers.

The DAO: Governed by Hooks

All three products - the AMM, the lending protocol, and the perpetual contracts - funnel a percentage of their fees into a central, autonomous treasury: the One Xahau DAO. On the website, this appears to be referenced under 'Protocol X':

The organization is governed by 5 to 6 hooks operating entirely on-chain, handling everything from fee collection to vote execution to profit distribution. When escrow thresholds are reached, hooks send funds to the DAO without anyone needing to press a button.

Every major platform parameter - fee rates for the AMM, interest rates for lending, which assets can be traded in the perpetuals pool - can only be changed through a DAO vote. That vote requires the use of XXX tokens, the platform's governance token, which are consumed when cast. This gives XXX a built-in deflationary mechanic: every governance decision reduces the token's circulating supply.

To protect against coordinated attacks or bad-faith voting, the DAO also features a council - a group of elected members who function similarly to a validator list in the XRP ecosystem.

Major decisions require council members to vote in alignment with the broader community vote, acting as a check against any single actor trying to weaponize raw voting power against the platform.

The XXX Governance Token

The XXX token is the connective tissue of the One Xahau ecosystem. Here's how it works in practice:

When users participate in any of the three DeFi products - the AMM, lending, or perpetuals - they receive LP (liquidity provider) tokens representing their share of the pool. Those LP token holders can then register with the DAO, at which point a hook reads their account, notes their LP positions, and issues XXX tokens to them.

The issuance schedule is designed to reward early adopters most generously - the earlier a user participates, the higher their relative XXX token earnings. As the platform matures, the per-user issuance rate declines, following an epoch-based schedule typical of token distribution models.

XXX tokens serve two functions: voting power within the DAO, and access to a share of the DAO's profits when staked. Approximately 10% of the DAO's revenue - including the XAH balance adjustment rewards earned by all XAH held across the platform - is earmarked for distribution to XXX token stakers. This creates a layered incentive: provide liquidity, earn LP tokens; hold LP tokens, earn XXX; stake XXX, earn a cut of platform revenue.

Balance Adustment

One of the attractive characteristics of Xahau is that both infrastructure providers and holders alike are able to access a 'reward' based on how much XAH they are holding. While infrastructure providers that occupy a governance seat on Xahau are rewarded much more than ordinary holders, all holders are able to access the basic balance adjustment.

Currently that balance adjustment rate is set to 4% APY.

Cbot indicated that, generally, anywhere where XAH is held in the autonomous One Xahau system - whether as part of the liquidity pools or as part of the DAO - that balance adjustment is leveraged for an increased return.

It's a way that One Xahau leverages the native reward mechanism to boost its earnings for liquidity providers and DAO participants.

It's Not Blackholed - Yet

There's an important caveat that any serious participant in One Xahau should understand: the hooks are not yet blackholed.

In Xahau's hook ecosystem, "blackholing" an account means permanently revoking the owner's ability to modify the code attached to that account. Once blackholed, the hooks run exactly as written - forever - with no possibility of alteration by anyone, including the original developer. It's the ultimate form of trustless operation, because it eliminates any single point of human control.

One Xahau isn't there yet.

Currently, changes to the hook code require a multi-signature process involving Cbot and approximately three other individuals. This means that, in theory, the code could still be altered by those parties acting in concert.

This is a deliberate choice. With any new platform, unexpected bugs or edge cases emerge as real users interact with the system in ways that testing couldn't anticipate. Cbot has opted to keep the multi-sig safety net in place while the platform accumulates usage data and proves its stability in the wild.

"In probably thirty-to-sixty days we'll be blackholed ... Right now, we're not."

For users evaluating risk, this is a meaningful distinction. The platform is backed by multi-sig security rather than the absolute trustlessness of a blackholed account.

Significance for the Xahau Ecosystem

Xahau has long held the theoretical promise of powerful DeFi capabilities through its hooks architecture. What has lagged thus far for the new network is the application layer - the number of actual platforms where users can put those capabilities to work. One Xahau is one of the few applications to bridge that gap at scale, demonstrating that hooks can power sophisticated, multi-product financial applications without relying on native protocol upgrades.

There's also the matter of timing.

With Xahau's native AMM, Price Oracle, and FeatureExport feature all queued up for potential activation in Q4 2026, the ecosystem is on the cusp of a significant expansion. One Xahau positions itself as a foundation - a platform already battle-testing the concepts that native features will eventually offer, and one with a governance structure capable of adapting as those new features come online.

Perhaps most significantly, Cbot has announced plans to release the hook code for the AMM, lending, and perpetuals as open-source tools (without DAO integration) for other developers to use. If successful, One Xahau won't just be one of Xahau's first DeFi platforms - it may become the reference point for the next generation of Xahau applications.

For a network that has focused relentlessly on layer one tools and utility, that's no small thing. X>

Sources

https://onexah.io/defi

One Xahau on X: https://x.com/One_Xahau

Cbot on X: https://x.com/Cbot_Xrpl

Gadget78 on X: https://x.com/gadget78

"DeFi is Live on One Xahau on XahauNetwork" — X Space recording: https://x.com/i/spaces/1vJpPPgDrwdJE?s=20

Xahau Network Roadmap: https://xahau.network/roadmap/

Xahau: Not Just A Sidechain

Hodor — Fri, 22 May 2026 11:59:22 GMT

Xahau launched as a mainnet near Halloween of 2023.

The original vision wasn't just a simple sidechain bolted onto the XRP Ledger - it was a fully independent network, one that would be inextricably linked to the XRP Ledger through trustless, cryptographic bridges.

Due to regulatory uncertainty with some types of bridge architectures, the first of those bridges was a non-custodial one known as xPoP (based on XLS-41). The mechanism it powered, called Burn2Mint, let users burn XRP on the XRP Ledger mainnet, generate a cryptographic proof of that burn, and mint equivalent XAH on Xahau - all without trusting a custodian.

Although the negative gap in chain-specific asset prices prompted the validators to vote for the amendment to be deactivated, it was an elegant, trustless approach to cross-chain value transfer, and it set the tone for how Xahau's creators thought about the relationship between the two networks.

XRP Plus

Here's a piece of Xahau's origin story that doesn't get told often enough: XAH wasn't always called XAH. Early on, the token was referred to internally as XRP Plus - a name that perfectly captured how the creators envisioned the two networks working together, and explains the idea behind 'burn-to-mint'.

The tokenomics were intentional.

The burn-to-mint model, the higher fee burns triggered by smart contracts ("hooks"), the incentivized validators - all of it was designed with a "rapid adoption" scenario in mind, one where Ripple itself might embrace a smart-contract-capable companion chain running its own native asset alongside XRP.

Imagine a parallel reality where the largest champion on the XRP Ledger, Ripple, burned billions of its XRP (minting billions of new XAH) so that they can then use XAH to address any use cases that their customers desire, that involved more complex account interactions. If that had happened, Ripple would have been, by far, the largest holder of XAH on Xahau, and the XAH tokenomics model would have been a huge benefit to XRP holders, given its much smaller supply. (Imagine a scenario where retail XRP holders used burn-to-mint if XAH was priced 4 times higher than XRP!)

Ripple chose a different direction, pursuing EVM-compatible sidechain initiatives.

But Xahau's creators - the Xahau Launch Alliance - didn't walk away from the idea of a compliment network. They kept building: bi-network block explorers, DEX overlay software, and shared tooling that made the two networks feel like they belonged together. The identical address format (r-addresses work across both chains) wasn't an accident - it was a design decision that lowered the barrier for any XRPL user or developer to interact with Xahau.

You can read more about that topic here: One Secret Key: Two Networks

Technical

Xahau's xahaud software is a fork of XRPL's rippled, and the two share the same foundational layer: identical Layer 1 cryptographic algorithms, r-addresses, and the consensus mechanism. Developers who know the XRP Ledger will find Xahau immediately familiar, and much of the documentation on xrpl.org applies directly.

Where Xahau diverges is in what it adds:

Hooks - lightweight, account-level smart contracts that execute logic on transactions flowing to or from an account
URITokens - a leaner alternative to XLS-20 NFTs, optimized for metadata and asset representation
Incentivized Infrastructure - validator rewards and tokenomics designed to sustain a programmable network
Faster Consensus - Project L-10K; scale up to 10,000 transactions per ledger

The result: all of XRPL's proven strengths - 3–5 second settlement, low fees, energy efficiency - plus programmability, without sacrificing performance.

Finternet Use Cases

There's a concept gaining traction called the Finternet - a term coined by the Bank for International Settlements (BIS) to describe an Internet-like vision for financial systems: interconnected, tokenized, user-centric, and capable of seamless cross-border flows.

Within the XRPL-family ecosystem, a compelling fan-driven framework has emerged that maps three networks onto that vision:

Network	Role
XRP Ledger	Fast, deterministic settlement - the standard for payments and tokenization, requiring no incentives
Xahau	The smart contract layer - Hooks-powered programmability with incentivized infrastructure
Evernode (EVR)	Decentralized compute and hosting (dePIN) - neutral infrastructure for off-chain and heavy computation

Together, this trio covers the full spectrum of conceivable use cases: real-time payments, programmable finance, tokenized assets, compliance automation, decentralized hosting.

In this vision, each network plays a distinct role, and the shared DNA between XRPL and Xahau makes interoperability intuitive rather than bolted on.

Xahau Also Stands Alone

While the complementary perspective is compelling, Xahau is also pursuing its own path.

The clearest proof of this is a recent project involving three organizations - Cooperative Bank of Oromia (Ethiopia), Quantoz Payments (a regulated digital asset issuer), and TerraPay (a world-wide payments network). Together, they're using Xahau as the settlement layer for Euro-denominated remittances flowing from Europe to Ethiopia.

This is a real-world, regulated blockchain settlement system targeting significant transaction volumes. It leverages Xahau's speed, determinism, and account-level smart contract functionality for compliance and efficiency. And notably, it doesn't rely on the XRP Ledger or Evernode to function. It's all Xahau.

It signals that enterprise-grade financial institutions are evaluating Xahau on its own merits.

Xahau Is More Than A Sidechain

Xahau started as a vision of what the XRP Ledger could be with smart contracts. It has since become something more: a full Layer 1 network with its own growing ecosystem (200,000+ accounts, millions of transactions), its own enterprise integrations, and its own roadmap.

It remains, by design, the ideal smart contract complement to the XRP Ledger - identical addresses, shared tooling, and trustless bridges make that relationship as seamless as any two independent networks can be. But the label "sidechain" undervalues what Xahau has become.

The 2026 roadmap - focused on scalability, accessibility, and security - reflects a network charting its own course. X>

Sources

Xahau roadmap: https://xahau.network/roadmap/

BIS Finternet Paper: https://www.bis.org/publ/work1178.htm

Xahau Network announcement: https://x.com/XahauNetwork/status/2051927674365300854?s=20

https://x.com/Quantoz/status/1986366890906694090?s=20

https://support.gatehub.net/hc/en-us/articles/14752835197842-Introducing-Xahau#

https://xahau.xrplwin.com/apps/xapp:xahau.teleport

xPoP: https://xls.xrpl.org/xls/XLS-0041-xpop.html

Coopbank official announcement: https://coopbankoromia.com.et/coopbank-and-terrapay-launch-blockchain-based-remittance-settlement-to-enhance-cross-border-transfers/

TerraPay press release: https://www.terrapay.com/media/terrapay-launches-cross-border-blockchain-remittances-to-ethiopia/

InFTF news: https://inftf.org/news/blockchain-settlement-euro-remittances-ethiopia/

Quantoz: https://x.com/Quantoz/status/1986366890906694090?s=20

Authoritative Links:

xrpl.org (applicable across both networks)

Xahau Official Site

xahaud GitHub Repository

New Version Of Clarity Act: Grok (And Me) Review

Hodor — Thu, 14 May 2026 15:48:20 GMT

Caveat: As with all my articles, this does not constitute legal or financial advice. This article was researched with the assistance of Grok (xAI) due to the sheer size of the document being reviewed.

What Is the Clarity Act, and Where Are We?

The Digital Asset Market Clarity Act of 2025 - commonly called the CLARITY Act - is landmark legislation aimed at finally drawing a clear regulatory map for digital assets in the United States.

On May 12, 2026, the Senate Banking Committee released a new, updated 309-page version of the bill, timed ahead of a scheduled markup hearing on May 14, 2026. This Senate version builds on the House-passed H.R. 3633 from July 2025.

General Concerns for All of Crypto

Developer Protections

One of the bill's strongest areas.

Title VI ("Protecting Software Developers and Software Innovation") creates explicit safe harbors from federal and state securities laws for developers and network participants engaged in activities like compiling transactions, running nodes, building and maintaining protocols, or developing user interfaces - as long as they are non-custodial and non-controlling.

Open-source developers who don't hold custody of user funds and can't unilaterally alter a protocol are well-protected.

This might be enough to stop high-caliber developers from relocating (a.k.a. 'brain drain').

Protections for DeFi Participants

Title III dedicates significant space to decentralized finance. The key principle: regulation follows control, not code. Truly decentralized protocols - those where no single operator can censor transactions, alter rules, or hold special privileges - are carved out from most intermediary requirements. Pure liquidity providers and peer-to-peer users are not treated as financial institutions.

Centralized front-ends and platforms that route to DeFi carry more compliance responsibility.

Tax Treatment

The Clarity Act is primarily a market structure bill, not a tax bill. It doesn't directly reform capital gains treatment or provide sweeping DeFi tax clarity. That said, clearer regulatory classification (commodity vs. security) should reduce headaches around reporting and may lay groundwork for better tax legislation down the road.

Authority Between the SEC and Others (Primarily the CFTC)

This is the bill's centerpiece. The SEC's ability to claim "everything is a security" is significantly curtailed. Instead, the bill creates a clear framework: the SEC handles securities-like aspects (primarily fundraising via "ancillary assets"), while the CFTC takes jurisdiction over digital commodities - including spot markets and intermediaries like brokers and exchanges - for mature blockchains.

The two agencies are required to coordinate on joint rules. This SEC-to-CFTC handoff, once a chain qualifies as a "Mature Blockchain System," is one of the most important provisions in the bill.

Concerns Specific to XRP Ledger | Xahau | Evernode

Are validators in these networks protected?

Yes. Section 601 and the DeFi provisions of Title III explicitly protect validators, node operators, and relayers for their core infrastructure activities, provided they operate non-custodially and without unilateral control. The incorporated Blockchain Regulatory Certainty Act (BRCA, Sec. 604) further protects these participants from money transmitter classification at the federal level, with federal law taking precedence over state law where there's a conflict.

For XRPL specifically, the validator ecosystem (the dUNL, amendment voting requiring ~80% support over two weeks) appears well-positioned. Xahau's multi-party governance game and Evernode's distributed host network similarly align with the "no single entity in control" requirement.

Are liquidity providers of AMMs protected?

Yes. LPs interacting with decentralized AMMs - like those on the XRP Ledger or Xahau - are not classified as brokers, intermediaries, or money transmitters, provided the underlying protocol is sufficiently decentralized. Users depositing into decentralized liquidity pools are exercising self-custody, not acting as operators.

Centralized interfaces or pools with special administrative privileges could face different treatment, but pure LP activity on a decentralized protocol is protected.

Are developers of non-custodial wallets protected?

Yes, explicitly. Section 601's safe harbor covers developing, publishing, and maintaining self-custody tools, non-custodial wallets, key management systems, and user interfaces that read and display blockchain data. The BRCA reinforces this by protecting non-controlling developers from money transmitter liabilities federally.

This is good news for wallets like Xaman and similar open-source tools across these ecosystems, as long as they don't take custody of user funds.

Are there hard-and-fast objective criteria for deciding what chain is a "true" crypto chain versus a security?

There are statutory criteria, but not purely mechanical ones. The bill defines a "Mature Blockchain System" as a blockchain plus its related digital commodity that is not controlled by any person or group of persons under common control. Supporting factors include functional operation, open-source code, transparent pre-established rules, and broad distribution of tokens and voting power - with commonly referenced benchmarks around no single party holding ≥20% of supply or voting power.

Certification is available: issuers, affiliates, or decentralized governance systems can file a certification with the SEC, which then has a limited window (approximately 60 days) to review or rebut it. Transition safe harbors of up to four years provide runway for qualifying projects.

Quick assessments for each chain:

XRP Ledger / XRP: Strongly positioned. Long operational history, increasing validator diversity (~150 active validators), the 2023 Ripple court ruling on secondary sales, and an escrow structure for XRP that is transparent and non-discretionary all work in its favor. Ripple's reduced day-to-day influence, combined with ongoing community decentralization efforts, strengthens the case further.

Xahau / XAH: Well-positioned. Xahau's Governance Game, which distributes decision-making across community seats, exchanges, developers, and infrastructure providers, demonstrates the kind of multi-stakeholder control structure the bill is looking for. No single entity appears to control >20% of the network long-term, and the chain is operationally independent from Ripple.

Evernode / EVR: Solid position. Evernode operates as a decentralized hosting network with its digital asset issued on Xahau, with a fixed max supply (~72.25M EVR), programmatic distribution of rewards over ~118 years via hooks, and a permissionless host model. Its distributed operator base and governance through hosting and membership NFTs reflect the decentralization ethos the bill rewards.

Could the SEC Still Be Weaponized?

This is the hardest question — and the most important one for long-term holders to think about.

The honest answer: yes, partially - but the risk is reduced compared to today.

The bill's "Mature Blockchain System" framework is far more objective and predictable than the old Howey test. Statutory guardrails, certification timelines, and the shift of mature-chain oversight to the CFTC all act as common-sense constraints. Courts can review arbitrary certification denials. Prior court rulings (like the 2023 Ripple decision) provide additional safe harbor for XRP.

That said, any future SEC leadership hostile to crypto could still use available discretion: issuing aggressive rulemaking interpretations of "control," slow-walking certification reviews, or choosing what to rebut and when. The facts-and-circumstances nature of the "control" test will require agency rulemaking to flesh out - and rulemakings can reflect the priorities of whoever is in power.

The structural safeguards - the CFTC handoff, judicial review, bipartisan bill support, and strong industry lobbying - make wholesale weaponization much harder than it was under pure enforcement-by-litigation. But perfect protection through legislation alone doesn't exist. The best defenses for these communities remain continued decentralization and political engagement.

Would the XRP Ledger, Xahau, and Evernode Be Considered "Mature"?

Based on the current bill framework: very likely yes, for all three - though final determinations depends on rulemaking and SEC review.

All three ecosystems were designed with decentralization as a core principle. Governance is distributed, token supply is broadly allocated or programmatically distributed, validator/node diversity is meaningful, and source code is open. The certification pathway exists and is intended to be navigable for projects exactly like these.

The biggest risks are not structural flaws but implementation details: how exactly the SEC interprets "common control" via rulemaking, and whether any entity's historical or ongoing holdings attract scrutiny. For XRPL, Ripple's escrow holdings are the most frequently cited concern, but the structured, transparent, and non-discretionary nature of those releases has generally been viewed favorably. For Xahau and Evernode, the newer vintage means less precedent, but the design choices are well-aligned with the bill's framework.

Next Steps

Here's where the Clarity Act stands procedurally and what to watch:

Senate Banking Committee Markup - Scheduled for May 14, 2026. This is where committee members debate, amend, and vote on the bill. With 100+ amendments filed, the outcome could still shift the text.
Full Senate Vote - If the bill clears committee, it moves to the Senate floor, where it will likely need 60 votes to advance (overcoming a filibuster). This requires meaningful bipartisan support, which the bill currently appears to have in principle.
House-Senate Reconciliation - The Senate version must be reconciled with the House-passed H.R. 3633. Differences will be negotiated, potentially through a conference committee.
Presidential Signature - The reconciled bill then goes to the President. As of this writing, the current administration is generally supportive of crypto-friendly legislation.

Realistic timeline: If markup goes smoothly and Senate leadership prioritizes floor time, a final bill could reach the President by late 2026, though delays are common with complex financial legislation. Optimists point to bipartisan momentum; pessimists note that stablecoin provisions and banking industry influence remain friction points.

Sources

Full Clarity Act Bill Text (Senate May 2026 Draft, PDF)
https://www.banking.senate.gov/imo/media/doc/ehf26374.pdf

Section-by-Section Summary (Senate Banking Committee, PDF)
https://www.banking.senate.gov/imo/media/doc/section-by-section.pdf

Senate Banking Committee — Clarity Act Resources
https://www.banking.senate.gov

House-Passed H.R. 3633 — Congress.gov
https://www.congress.gov/bill/119th-congress/house-bill/3633

Congress.gov — Digital Asset Market Clarity Act of 2025 (Tracking)
https://www.congress.gov

SEC.gov — Digital Assets Regulatory Resources
https://www.sec.gov/digital-assets

CFTC.gov — Digital Asset Oversight
https://www.cftc.gov/digitalassets

Blockchain Association — Clarity Act Analysis
https://theblockchainassociation.org

Ripple / XRPL.org — Decentralization and Regulatory Resources
https://xrpl.org

Evernode Official Documentation and Resources
https://evernode.org

Stablecoins Will Destroy Trad-Fi

Hodor — Tue, 12 May 2026 19:22:29 GMT

Traditional finance had a good run.

Like the advent of Internet-based banking, a new technological marvel is waiting in the wings as an inevitable disrupter. And it's not something flashy like 'artificial intelligence'; it's the simple concept of stablecoins.

Stablecoins Unlock Micropayments

When was the last time you paid someone $0.003 for something?

Answer: You haven't.

It's not your fault ... you can't. Traditional payment rails - ACH, SWIFT, Visa - carry transaction costs that make micropayments economically unfeasible. Sending ten cents through a bank costs more than ten cents to process.

Stablecoins eliminate that constraint. On modern crypto networks, very small payments are technically and economically rational. This opens entire categories of commerce that cannot exist in traditional finance:

pay-per-article journalism
per-second streaming royalties
machine-to-machine payments in the IoT economy
real-time freelancer compensation
AI subscription credits

When the unit of value can be as small as the transaction itself, entirely new business models emerge. And trad-fi's existing cost structure can't support it.

Crypto Rails Are Dirt Cheap - And Nobody Owns Them

We all pay for Visa's network.

You do. Merchants do. Everyone does - through interchange fees, processing fees, and currency conversion markups that take away material amounts of each payment.

Crypto infrastructure is financed differently. Layer-1 protocols like Xahau and Solana fund their networks through validator incentives baked into the protocol itself. The cost isn't heaped onto a corporation that then multiplies it before charging the consumer. Instead, It's distributed across the network infrastructure providers that are focused on meeting the performance requirements to retain their incentives. Competition between validators drives the cost toward its natural floor.

The result: Transaction fees that are fractions of a cent - for a payment network that is world-wide, 24/7, and permissionless.

No correspondent bank taking a cut
No settlement windows measured in "business days"

Traditional financial infrastructure is not just expensive - it's structurally expensive. That's not a problem that can be fixed with better software; It's a consequence of the business model.

Central Banks Want Stablecoins

Programmable money gives regulators tools they've never had before. And no, I'm not talking about the dystopian concept of a 'central bank digital currency' (CBDC).

Consider fractional reserve banking. Right now, banks are legally required to hold a fraction of deposits as reserves and restrict how much risk they can handle. But enforcement is reactive. Regulators audit after the fact, issue fines after the fact, and intervene - if they're lucky - before a contagion spreads.

With tokenized assets on a public blockchain, the rules can be encoded directly into the money. Reserve requirements don't need to be audited - they can be enforced by smart contracts in real time. Regulatory risk limits are measurable instantly, verifiable by all stakeholders.

Customers Already Know What They Want

People want to be paid immediately for work done.

Gig workers, freelancers, contractors, and traditional employees share a common problem: you complete the work, and then you wait. Two weeks. A month. The money sits somewhere ... earning interest for others.

Stablecoin payments settle in seconds.

Example: A freelancer in Brazil completes a project for a client in London, and the payment arrives as soon as the work is reviewed. In the crypto world, the client can push a button, releasing an escrowed payment of Euros.

This isn't a feature that needs to be sold; it's a feature that sells itself.

Credit Card Processors Know

The headlines were fast and furious throughout the last two years; credit card processors taking the difficult steps to integrate with the new payments rails.

The Future Belongs to Better Technology

Kodak didn't lose to a better film company. Blockbuster didn't lose to a better video store. They lost to technologies that made the old model unnecessary.

Traditional finance is facing the same structural challenge. It's not that stablecoins are a little better at moving money - it's that they're way, way better.

Cheaper rails
Programmable compliance
Instant settlement
Worldwide access
Micropayments

Stablecoins won't destroy traditional finance because they're fashionable. They'll destroy it because they're better.

Sources

https://bitwage.com/en-us/blog/stablecoin-micropayments-unlocking-new-business-models

https://mmc.vc/research/stablecoins-entering-their-untethered-growth-era/

https://www.federalreserve.gov/econres/notes/feds-notes/banks-in-the-age-of-stablecoins-implications-for-deposits-credit-and-financial-intermediation-20251217.html

Stablecoins: Growth Potential and Impact on Banking
https://www.federalreserve.gov/econres/ifdp/files/ifdp1334.pdf

https://cryptoslate.com/visa-is-quietly-building-stablecoins-into-mainstream-payment-plumbing-without-you-knowing/

Visa Tests Stablecoin Payouts to Speed Payments for Creators, Gig Workers
https://www.coindesk.com/business/2025/11/12/visa-tests-stablecoin-payouts-to-speed-payments-for-creators-gig-workers

Xahau Settlement: TerraPay, COOP Bank, & Quantoz

Hodor — Fri, 08 May 2026 14:31:09 GMT

The Inclusive Financial Technologies Foundation (InFTF) has announced a new three-way partnership bringing together global payments infrastructure company TerraPay, the Cooperative Bank of Oromia (Coopbank), and stablecoin provider Quantoz Payments - using the Xahau network as the settlement layer for remittances to Ethiopia.

Quick History

In October of 2024, the Coop Bank of Oromia and the InFTF made headlines. Coop Bank was the first bank in Ethiopia - and arguably in Africa - to launch a blockchain-powered remittance service. The solution ran on the Xahau network and was delivered through a dedicated "Coop Remit" xApp built into the Xaman non-custodial wallet. It allowed members of the Ethiopian diaspora - many working in Europe, the Middle East, and the U.S. - to send funds home in a matter of seconds, at a fraction of traditional costs.

The xApp was live, with real money.

Xahau's inline smart contract functionality (called "hooks") enabled each payment to be automatically screened for compliance, making the process both fast and regulatory-friendly. The InFTF brought the technical expertise to wire it all together, while Coop Bank - with over 13 million account holders and 760+ branches - provided the on-the-ground banking reach.

That project is now being retired.

The New Deal

The new arrangement scales the original concept to a larger size.

TerraPay, a world-wide, (B2B) cross-border payments network with established relationships across the remittance industry, now has an additional EURO-to-ETB rail for money transmission. While they do not deal with end-users directly, they provide the infrastructure that is used by others to send money into Ethiopia.

Their proprietary network of clients then, theoretically, take over the role that the Coop Remit xApp previously played for end-users.

This means Ethiopian families abroad can now access the service through TerraPay's broader network of various money transmitter partners, rather than a niche wallet app.

Quantoz Payments handles the liquidity and stablecoin conversion, providing a regulated digital Euro settlement infrastructure that bridges the gap between the sending currency and the local Ethiopian Birr (ETB). Coopbank then completes the "last mile" - routing the converted funds to the correct destination bank account across Ethiopia, drawing on its nationwide branch network.

The InFTF continues to play a coordinating role, having facilitated the Xahau integration points.

Benefits

The shift from (one) wallet-based xApp to (potentially) many remittance providers is a meaningful upgrade for everyone involved. For end-users, it means accessing Ethiopia-bound transfers through existing, familiar, widely-available platforms - rather than needing to download a specific wallet and learn its interface. For TerraPay and Coopbank, it's a chance to deepen their corporate footprints in one of Africa's fastest-growing remittance markets, where annual inflows exceed $5 billion USD.

Easier for the sender
Familiar interface(s)
Better reach for the banks
More volume flowing through the Xahau network

How Xahau Is Used

The exact technical mechanics are kept somewhat close to the chest - the parties involved understandably don't want to hand competitors a blueprint. What the announcement does confirm, though, is that Xahau is the settlement layer, and that Quantoz is the named stablecoin provider for the Euro leg of the transaction.

This is notable because Quantoz had already signaled its intentions for Xahau in November of last year:

The stablecoin groundwork was laid ahead of time.

The Real Deal

This is not a 'coming soon' type of item.

It's a live, operational expansion of a service that was already working. This new deal upgrades it - larger partner, broader user base, more settlement volume.

Xahau is well-suited to this kind of use case.

Its hooks architecture is easily understood, and allows smart contracts to trigger inline with each payment, meaning compliance checks can happen automatically, attached to each account. That's a significant advantage in regulated financial services.

And ... with the AMM amendment on the horizon, Xahau's toolset for powering similar projects is only going to grow.

The End-User Experience

The original Coop Remit xApp put simplicity first - a streamlined way for end-users to send money home without navigating complex banking systems. The new TerraPay arrangement has the potential to make that experience even smoother, reaching senders through a variety of platforms that their money transmission partners already have in place.

For the Xahau community - developers, speculators, and crypto fans - this is the kind of real-world traction the ecosystem has been building toward. Interested parties will be watching closely to see how far this model can scale. X>

Sources

Coopbank official announcement: https://coopbankoromia.com.et/coopbank-and-terrapay-launch-blockchain-based-remittance-settlement-to-enhance-cross-border-transfers/

TerraPay press release: https://www.terrapay.com/media/terrapay-launches-cross-border-blockchain-remittances-to-ethiopia/

InFTF news: https://inftf.org/news/blockchain-settlement-euro-remittances-ethiopia/

https://x.com/IncFinTech/status/2051922102895198602?s=20

Xahau Network announcement: https://x.com/XahauNetwork/status/2051927674365300854?s=20

https://inftf.org/

https://coopbankoromia.com.et/

https://xahau.network/roadmap/

https://x.com/Quantoz/status/1986366890906694090?s=20

https://www.quantoz.com/

https://www.terrapay.com/

What Is The "Finternet"?

Hodor — Mon, 04 May 2026 15:12:31 GMT

The term arises from a BIS (Bank for International Settlements) working paper authored by Agustín Carstens and Nandan Nilekani.

The paper defines the term 'Finternet' as:

"... multiple financial ecosystems interconnected with each other, much like the internet, designed to empower individuals and businesses by placing them at the centre of their financial lives.

It advocates for a user-centric approach that lowers barriers between financial services and systems, thus promoting access for all. The envisioned system leverages innovative technologies such as tokenisation and unified ledgers, underpinned by a robust economic and regulatory framework, to dramatically expand the range and quality of financial services.

This integration aims to foster greater participation, offer more personalised services and improve speed and reliability, all while reducing costs for end users. Most of the technology needed to achieve this vision exists and is fast improving, driven by efforts around the world."

The authors of the paper do not have a monopoly on the term's definition, but what they've written here seems to get at the heart of the concept for many people - including me.

How It All Fits Together

In contrast, traditional finance ("trad-fi") places the authority and control of the old financial system in the hands of intermediary institutions, like banks and brokers.

The 'Finternet' goes in the opposite direction, and places the control back in the hands of the people who have a financial stake in crypto networks, along with holding tokenized fiat currencies - a.k.a. 'stablecoins' and real-world assets (RWAs).

It changes the paradigm through tokenization, which is a further step down the road of dematerialization, a controversial development where paper-based ownership like stock certificates were replaced with electronic representations at third parties.

The danger of course, to the consumer, from (traditional) dematerialization, is that their interest in these electronic representations has been methodically removed to that of a 'creditor' ... most people find this concept repugnant, or don't even really understand the danger, until it presents itself in the form of a bankruptcy ... like what happened to Bear Stearns during the 2008 financial crisis.

While the sharks on Wall Street like the idea of 'creditor layers', most ordinary people do not. Ordinary people want to truly 'own' what they buy, without the risk that their ownership rights can be removed or diminished by unknown third parties as part of an invisible collateral agreement.

For more information about the dangers of traditional finance's definition of dematerialization, I recommend people watch a documentary called 'The Great Taking', which is an extended interview with David Webb, a former Wall Street investment banker:

[YouTube id="dk3AVceraTI"]

The 'Finternet' has the potential to restore property rights to their intuitive state before dematerialization even occurred; it's difficult to argue against a consumer's property rights if they can simply point to a decentralized source of information as proof of their interests ... a.k.a. a 'blockchain' (decentralized ledger).

Three Networks

My own speculative crypto holdings reflect my beliefs about where I'd like to see the future go, in terms of financial self-sovereignty. The three networks that I believe can work together to address any conceivable use case for cryptocurrency, are the XRP Ledger, Xahau, and Evernode.

The three networks have one thing in common: they use the agreement protocols to achieve transaction consensus and finality, instead of 'proof of work' or 'proof of stake'. This means that they do not depend on massive amounts of electricity to verify transactions, like the "Bitcoin" series of networks - BTC, BCH, and BSV.

The XRP Ledger is the first mover of agreement protocols, and has proven the concept by running successfully for well over a decade, and houses billions of dollars of financial value, including material levels of tokenized, real-world assets (RWAs).

The Xahau network is essentially the same code as the XRP Ledger, with similar capabilities, but with one major difference; this 'child' network of the XRP Ledger supports smart contracts associated with individual accounts. The smart contracts are known as 'hooks'.

The Evernode network is a decentralized infrastructure & smart contract network (DePIN), that removes the dangerous dependency on centralized infrastructure providers, like Amazon Web Services. In heated political climates, these third parties cave quickly to popular demands at the expense of individual freedom. Decentralized infrastructure raises the level of censorship-resistance for applications.

Finternet Requirements

It's not enough for crypto to offer novel proofs-of-concept.

Consumers demand the same level of service and protection for their interests that traditional finance currently provides. Ideally, the 'working' version of the finternet will provide banking services so that people can pay their day-to-day bills with the money that they earn.

In addition, people expect their finances to be private from anybody other than those with a legal interest, such as the government, or judicial representatives in various countries.

They also prefer to have an option for absolute control over their property, to mirror what physical coinage provides.

Can the Finternet meet these requirements, which are currently fulfilled by traditional finance?

"How" Is The Question

So how would all the cryptographic machinery work together? Consider a few potential ideas.

Zero-knowledge proofs ("ZKP") have the potential to protect the privacy of people, even as they use public ledgers.
Black lists and white lists have the potential to enforce (existing) compliance requirements, such as KYC & AML.
Decentralized infrastructure has the potential to address nation-state independence concerns between countries about hosting metadata frameworks for these new interconnected ledgers.

Regardless of what ideas work, many times, what develops is a result of un-anticipated adoption of new technology in an asymmetric fashion.

My Take

Like many people that have been a part of the crypto revolution from the early years, I prefer technology that allows me to control my own property.

In the crypto world, this means only trusting yourself to manage your cryptocurrency; this desire is met through non-custodial wallets, such as the Xaman wallet.

If it were available - and possible - I'd like to store my other ownership proofs on-chain as well. I'd also like to handle my own government-issued identification in a secure manner, and share different levels of this information, as required by third parties.

The Finternet Is What We Make It

If we all collaborate to provide our opinion on the new financial system, the Finternet can take the shape of whatever we wish it to take.

Future generations deserve financial systems that empower and uplift them; if we contribute to building and using the first versions of these systems, we can create brilliant and unlimited possibilities, rather than dependence on weak, potentially-corrupt intermediaries.

The new Finternet will be what we decide.

Sources:

https://www.bis.org/publ/work1178.htm

https://en.wikipedia.org/wiki/Bear_Stearns

"The Great Taking" via YouTube: https://www.youtube.com/watch?v=dk3AVceraTI

https://csrc.nist.gov/csrc/media/presentations/2024/wpec2024-3b1/images-media/wpec2024-3b1-slides-akira-tjerand--ZKP-Overview.pdf

https://github.com/Xahau/Whitepaper (whitelists)

https://xumm.app/?lang=en

https://xrpl.org/

https://www.evernode.org/

https://xahau.org/

Evernode (EVR) Tokenomics

Hodor — Mon, 27 Apr 2026 20:24:01 GMT

Evernode is a decentralized infrastructure ("DePIN") network that houses its governance and token on the Xahau network.

Evernode's purpose: to enable anyone to run smart contracts & applications in a fully decentralized way, without relying on a central company or point of weakness. Instead of servers in a data center, Evernode runs on a cross-border network of independent host computers that earn its native token, EVR (also called “Evers”), in exchange for providing computing power.

What makes Evernode interesting from a speculator's perspective is not just what the network does, but how its token supply is structured. The designers built a tokenomics model - a set of rules governing how tokens are created, distributed, and earned - that is creative ... and deflationary.

This article reveals that model.

Epochs, Halving, and Automated Rewards

The core of Evernode’s tokenomics is a system called “epochs.” Think of it like Bitcoin’s halving schedule, but applied to infrastructure rewards rather than mining.

Here is how it works.

Every hour, the Evernode network triggers what it calls a “moment” ... a heartbeat during which eligible host computers submit proof that they are online and running properly. The network then distributes a pool of Evers proportionally among all active, reputable hosts. There is no committee deciding who gets paid. The entire process runs automatically through “hooks” - lightweight smart contracts attached to accounts on the Xahau network.

Each epoch contains exactly 5,160,960 EVR set aside for host rewards. Once that amount has been fully distributed, the epoch ends and a new one begins ... but with the hourly reward rate cut in half. This halving mechanic has a key implication: as each epoch passes, Evers become harder and slower to earn.

Early hosts captured the highest rewards; later hosts operate with increasing scarcity.

The schedule of epochs looks like this:

Epoch boundaries are triggered automatically when the previous epoch's full allocation of 5,160,960 EVR has been paid out.

Because each epoch's hourly payout rate is fixed by the protocol, the duration of each epoch is actually highly predictable ... you can calculate it years in advance with simple division. Epoch 1 pays out at the highest rate; Epoch 2 pays out at exactly half that rate and therefore takes roughly twice as long to exhaust; Epoch 3 takes twice as long again; and so on.

The only real-world variable is whether individual hosts occasionally go offline or fail their hourly heartbeat check, which can slow the drain on the pot very slightly. In practice this is a minor edge effect. The overall schedule - stretching 118 years - is baked into the protocol math from day one.

Who Got What: The Initial Distribution

Here is a timeline of the key events and how the initial supply was distributed.

September 2023: The Snapshot

On September 1st, 2023, a snapshot was taken of every XRP Ledger account holding XRP. This snapshot - recorded at Ledger #82237135 - determined which XRP holders would be eligible for the upcoming airdrop.

Holders were capped at 50,000 XRP per account for eligibility purposes; larger holders had to split across multiple accounts to fully participate.

December 2023: Network Launch and Airdrop

Evernode launched on December 18, 2023, on the Xahau network. On launch day, all 72,253,440 EVR were pre-minted in a single transaction by the official issuer address (rEvernodee8dJLaFsujS6q1EiXvZYmHXr8). That issuer address was then “blackholed” - permanently disabled so that no one, including the founders, can ever create additional EVR.

Simultaneously, 20,643,840 EVR (about 28% of the total) were distributed in a structured airdrop:

The airdrop to XRP holders was proportional to the qualifying XRP balance each participant held at the time of the September snapshot.

Over 38,000 wallet addresses registered.

January 2024: Rewards Begin

Host rewards kicked off on January 15, 2024, marking the start of Epoch 1. The 51.6 million EVR allocated to the host reward pool are held inside the Evernode Heartbeat Hook - a smart contract that cannot be tampered with. Hosts earn from this pool exclusively through the automated heartbeat process.

Now: Epoch 5

According to the XRPLWin Evernode Dashboard, the network is currently operating in Epoch 5.

To put that in perspective: Epoch 1 lasted only about six weeks (from mid-January to late February 2024). Epoch 2 ran for roughly twelve weeks. Each subsequent epoch doubles in length, because the reward rate halves while the total EVR to be distributed per epoch stays the same.

Epoch 5 is estimated to run for approximately 96 weeks - nearly two years. That pace of distribution will continue to slow ... dramatically ... through the later epochs, with Epoch 10 projected to last roughly 59 years! 😵

This is by design.

The slow, predictable release of tokens creates a long-tail incentive structure that is meant to attract and retain quality infrastructure providers over decades, not just months.

Max Supply: A Number That Cannot Change

The total maximum supply of EVR is 72,253,440 - and that number is genuinely fixed. Unlike many cryptocurrency projects where “max supply” is a stated intention that can be overridden by a governance vote or a protocol upgrade, Evernode’s supply cap is enforced by the fact that the issuer account has been permanently blackholed.

It is not possible to mint a single additional EVR.

Of that 72.25 million:

About 28% (20.6 million EVR) was distributed in the initial airdrop to founders, labs, beta testers, and XRP holders.
About 72% (51.6 million EVR) funded the host reward pool and is being distributed across 10 epochs over an estimated 118 years.

At the current rate of distribution - we are in Epoch 5 with approximately 36 million EVR now in circulation - more than a century of scheduled distribution remains.

Distribution So Far: The Rich List

The EVR rich list is an interesting data point, but it requires some context: the rich list currently reflects holdings on the Xahau network only.

Since EVR also trades on the native XRP Ledger DEX, and a small number of centralized exchanges, a significant portion of circulating supply sits in exchange wallets or with traders who hold their EVR as Gatehub IOUs on the XRP Ledger.

This means the top-wallet concentrations visible on the rich list are somewhat inflated in appearance. As the ecosystem matures and more wallets convert their IOU balances to Xahau, the distribution picture will naturally become more granular.

There are a total of ~ 36,000 wallets containing EVR on the Xahau network alone; counting the XRP Ledger wallets with EVR tokens may significantly expand that number. It's a metric on par with some layer one chains.

Intentional Scarcity

The designers of Evernode built increasing scarcity directly into the system - and tied it deliberately to infrastructure quality.

Here is the logic: as EVR becomes scarcer and more valuable, the cost of registering as a host (currently a 500 EVR deposit) rises in real terms. That rising barrier naturally filters out low-quality or unreliable hosts over time. Only operators who are serious about providing good, consistent computing resources will find it profitable to participate.

The result, in theory, leads to an iterative loop: higher EVR value → higher quality hosts → better network performance → greater demand for hosting slots → further upward pressure on EVR. The tokenomics are not just about speculative value; they are meant to directly incentivize the quality of the infrastructure underpinning the network.

While this does not guarantee any specific price of EVR, it's a fascinating, intentionally-designed component of the overall network economics.

How EVR Supply Compares to XRPL and Xahau

Although EVR lives among complimentary agreement protocol networks, its supply is more akin to the early Bitcoin projects:

That scarcity, combined with the slow release schedule across 118 years, means there is no imminent supply shock from unlocking events or large new issuances. The emission schedule is known, deterministic, and fully visible on-chain.

More Than Fascination

Evernode’s tokenomics stand out for multiple reasons:

The supply is permanently capped and immutably enforced.
Distribution is fully automated by on-chain smart contracts, with no human discretion in the process.
The halving schedule creates predictable, ever-increasing scarcity designed to reward long-term participants over short-term speculators.
The link between EVR value and infrastructure quality gives the token genuine utility beyond speculation.

We are currently in Epoch 5 - early enough that the most dramatic halvings lie ahead, but late enough that the system has already demonstrated it works as designed. For those watching the XRPL ecosystem and the broader decentralized infrastructure space, EVR’s tokenomics are worth understanding carefully. The 118-year emission clock has only just started ticking. E>

Sources:

https://xahauexplorer.com/en/distribution

https://www.evernode.org/evers

https://www.evernode.org/news-listing/xrp-holder-airdrop-process

https://uphold.com/en-us/prices/crypto/evernode-evr

https://cryptopotato.com/airdrop-update-for-ripple-xrp-holders-evernode-details-reviewed/

https://xahau.xrplwin.com/evernode

Data for Richlist Graphic from @XRPLWin

Marine them for rich list from https://x.com/XRPBags

https://medium.com/@ilaNihas/evernode-become-a-pioneering-host-9ef88a0756d4

https://www.evernode.org/hosts

"The Village Politicians" (1819) by American artist John Lewis Krimmel

https://www.coingecko.com/en/coins/evernode

https://coinmarketcap.com/

HookState Data Viewer: Browse On-Chain State, Build Projections & Manifest

XRPLWin — Sun, 26 Apr 2026 08:02:36 GMT

Part two of our HookState series. In part one we covered why raw HookState bytes are hard to read and how the Hook State Converter lets you decode them into a typed ABI schema. This article picks up where that one ended: what you do with that schema once you have it.

From a JSON segment to something useful

At the end of part one, you had a JSON ABI definition — a typed map of your HookState key and value bytes. The article closed with a promise: a dedicated projection builder UI exists that uses that schema to automatically decode HookState entries on the explorer.

It does three things. It lets you browse any hook's raw on-chain state by namespace. It lets you build projections — readable, filterable tables that decode state entries according to your ABI. And it lets you publish a hook manifest, so those projections are available to everyone visiting your hook on the explorer, permanently, without anyone needing to convert themselves.

Browsing namespaces

Every Xahau account can have multiple hooks installed, and each hook stores state under its own namespace — a 32-byte identifier derived from the hook hash. The Data Viewer exposes this structure directly.

Open the tool and navigate to any account. The left panel lists all namespaces active on that account, each showing how many total state entries it contains. Clicking a namespace loads its content into the main panel as a set of tabs.

If a manifest has already been published for that hook, the namespace label resolves from a raw hash to a human-readable hook name, and the hook's projections appear as named tabs alongside the raw view. If no manifest exists yet, the namespace shows as a truncated hash and only the raw tab is available — which is your cue to build one.

A namespace can contain state from more than one hook. In that case each hook gets its own tab group within the namespace, with its projections listed beneath it in the sidebar.

All states (raw)

The first tab in every namespace is All states (raw). This is the unfiltered view of everything stored in the namespace, with no decoding applied.

The table shows four columns: HookStateKey, HookStateData, Flags, and OwnerNode — exactly as they exist on the ledger. Keys and values are displayed as full hex strings. This is the ground truth view: no interpretation, no type assumptions, nothing inferred.

It's most useful when you're first exploring an unfamiliar hook and want to see the raw shape of its state before building any projections, when you suspect a projection is missing entries and want to verify against the full set, or when you're debugging a key encoding issue and need to compare raw bytes directly.

The raw table is fully searchable, sortable, and exports to CSV and Excel — so you can pull the complete state of any namespace into a spreadsheet for offline analysis without writing a single API call.

Hooks and their projections

Below the raw tab, each hook installed in the namespace gets its own section. If a manifest exists for the hook, its name appears as the tab label and its projections are listed beneath it in the sidebar — each one a named, filtered view into a subset of that hook's state entries.

The Evernode Governor Hook, for instance, carries over 25,000 state entries across projections ranging from single-entry config values like Issuer Address and Mint Limit, to large paginated sets like Host Address (12,029 entries) and Token Id (12,086 entries). All decoded, all browsable, all exportable — because a manifest exists for it. Without the manifest, you'd be looking at 25,000 rows of raw hex.

The projection

A projection is a named view over a subset of a hook's HookState entries. It defines how to decode the key bytes and the value bytes into typed columns, applies optional filters to scope which entries appear, and gives each column a human-readable label.

You can think of it as a schema-driven query: show me all HookState entries where the key matches this pattern, decode them as these types, and display the result as a table.

One important detail: a projection doesn't claim exclusive ownership of the HookState entries it targets. The same state entry can appear in multiple projections simultaneously, and this is intentional. A hook might expose one projection showing all fields of a record for technical auditing, and a second projection scoped to the same entries presenting only the fields relevant to a specific integration — different column selections, different filters, different renderers, same underlying state. This is how a single hook with a complex storage schema can surface multiple clean, purpose-built views without duplicating any data on-chain.

Each hook manifest can contain as many projections as needed, and several of them can deliberately overlap on shared state keys by design.

Building a projection

To create a projection, click Add projection in the Data Viewer. This opens the Edit Projection modal.

At the top you select which hook this projection belongs to and give it a name and optional description.

The modal has four tabs: HookStateKey, HookStateData, Projection preview, and ABI.

Defining the key (HookStateKey tab)

The HookState key bytes appear as a row of clickable hex buttons. You select a span of bytes by clicking — selecting byte N means you've selected bytes 1 through N as a single segment. As you do, the UI immediately shows how many state entries in the namespace match that byte pattern so far. This live match count updates in real time as you narrow the key definition, giving you instant feedback on whether your filter is scoping entries correctly before you've committed to anything.

Once you've selected a span, the type picker appears showing every ABI type that fits that exact byte length. The Suggest button runs the same autoscan as the Hook State Converter — it scans across all supported types simultaneously and surfaces the most plausible matches with decoded values shown inline.

After selecting a type, a segment options panel appears. When you have unapplied changes the panel is highlighted with an orange border and a "You have unapplied changes" warning — a useful guardrail against navigating away mid-edit without realising you haven't committed a segment:

Column title — the label shown in the projection table header.

Description — optional documentation for the field.

Exclude from view — mark this segment as hidden. Useful for padding bytes, fixed sentinel values, or type prefix bytes you're using only for filtering.

Filtering rule — define a literal term or pattern (with encoding: ASCII, hex, etc.) that this segment must match for an entry to appear in the projection. A single type-byte filter is often all it takes to scope a projection from thousands of total namespace entries down to precisely the records you want.

Render as — controls display format for timestamps, amounts, account IDs, and other types with multiple meaningful representations.

Hit Apply to lock-in the segment.

Defining the value (HookStateData tab)

The value bytes follow exactly the same flow. Select a span, pick a type, configure segment options, apply. Repeat until all bytes are accounted for and the tab is marked Solved.

To give a sense of scale: the Host Address projection in the Evernode Governor manifest decodes 22 typed fields from each entry's raw value bytes — registration ledger, fee, instance counts, heartbeat index, version, timestamps, reputation, lease amount, and more. All of it packed into raw bytes on-chain; all of it readable in the projection table.

Saving and publishing

Once both tabs are Solved, hit Update to save the projection locally. The projection now appears in the sidebar and in the main hook view — but it is not yet live. The main hook view shows a Publish changes button that becomes active whenever you have locally saved projections that haven't been pushed to the manifest yet. This two-step flow lets you build and iterate on multiple projections before making any of them public.

Publishing a hook manifest

A manifest is the container that holds all your projections plus metadata about the hook itself. Publishing one makes everything visible to everyone — not just to you in the Data Viewer, but to anyone who navigates to that hook anywhere on the explorer.

Click on green "Publish changes" buttom to make your manifest version live. In next step you will have change to idenfity hook, give it name, icon, description...

Hook name — the display name that replaces the raw namespace hash across the explorer.
Hook icon — a square image, minimum 256×256px, provided as a URL or direct file upload.
Short description — one or two sentences shown in the manifest header.
Readme — a full markdown field rendered in the About tab on the hook's manifest page. Use it for documentation, storage schema explanation, version history, or anything useful to auditors and integrators coming to the hook cold.
Repository URL — renders as a "Source code" link directly on the hook page.
License — a standard identifier (MIT, GPL-3.0, Apache-2.0) or leave blank for unlicensed.
Publishers — one or more entries, each with a type (Individual or Organization), a name, and an optional URL. Multiple publishers can be added to the same manifest. Publishers are displayed in the manifest header and their combined account weight determines how this version is ranked against others.
ABI — the aggregate JSON of all your projection definitions, auto-populated from your saved projections. A "View/Edit JSON manifest ABI (advanced)" button opens a full editor for direct manipulation when needed.

Hit Publish. The manifest is stored and associated with the hook hash. From this point on, anyone visiting that hook on xahau.xrplwin.com sees the decoded namespace name, the projections as tabs, and the full manifest metadata.

Community manifests and version weight

Anyone with an account on XPLWin can publish a manifest for any hook — not just the hook author. If a hook is deployed and widely used but the author hasn't published a manifest, a community member, an auditor, or an integration builder can step in and create one.

This openness creates an obvious question: if multiple people publish manifests for the same hook, which version does the explorer show by default?

The answer is account weight. Each website account carries a weight value, and when multiple manifest versions exist for the same hook, the explorer sorts them by the combined weight of their publishers. The highest-weight version is shown as the default. Users can switch between available versions at any time using the version selector on the hook page — so no version is hidden, just ranked.

The Evernode Governor Hook is a practical example: built and deployed by Evernode Labs, manifest created and published by XRPLWin. The "Manifest by xrplwin" badge on the hook page reflects this — hook author and manifest author are different entities, and the system handles that cleanly.

In practice this means the hook author, or an established community member with a higher-weight account, will naturally surface at the top. But a lower-weight account can still contribute a manifest — their version remains accessible and switchable. The system accommodates multiple valid interpretations of the same hook's storage schema coexisting without conflict.

The full loop

Part one covered the decoding problem and the Converter that solves it for a single hex string. This article covers what comes after.

The intended flow is:

Write and deploy your hook
Grab a sample HookState key + value from the explorer or your test environment
Run it through the Hook State Converter to produce typed ABI segments
Open the HookState Data Viewer, navigate to your hook's namespace, and build projections — watching the live match count confirm your key patterns as you go
Save projections locally, verify in the Projection preview tab, then hit Publish changes
Fill in the manifest metadata and publish — or build on a community-contributed version if one already exists
Anyone visiting your hook on the explorer now sees decoded, human-readable state — not raw hex

For a hook storing configuration values across dozens of keys, a single afternoon with these two tools produces a manifest that makes it permanently auditable. For something at the scale of Evernode's Governor Hook — 25,000+ entries, community-maintained manifest — it's the clearest demonstration of what this system is designed to enable.

See it in action https://www.youtube.com/watch?v=G86IRZNfNH8

XRPLWin is a explorer for XRPL and Xahau. We build tools for the Xahau ecosystem.

New Features: Xahau Roadmap

Hodor — Fri, 24 Apr 2026 14:03:15 GMT

Team Xahau recently updated its roadmap covering Q2 2026 through Q3 2027.

Among the milestones listed are eight new protocol features - each one deliberate, targeted, and consistent with the network's philosophy of minimal but meaningful change in the base protocol.

Here's a breakdown.

Random Number Generator

Currently in beta development, the native on-ledger Random Number Generator (RNG) brings verifiable randomness directly to hooks and applications - without relying on any off-chain oracle or third-party source.

For a crypto network, trustworthy randomness is harder to achieve than it sounds, and having it available as a native primitive opens the door to fairer lotteries, gaming mechanics, sampling logic, and any application where unpredictability needs to be provable.

FeatureExport

FeatureExport is one of the more significant additions on the list.

It allows a Xahau user or hook to request that the Xahau UNL (Unique Node List) co-sign a transaction destined for the XRP Ledger (XRPL) - structured as an ordinary transaction with a MultiSign block, where each UNL member contributes a signature.

In practical terms, this means Xahau Hooks can effectively control XRPL accounts and issue or manage assets directly on the XRPL. It's orchestration between the two networks, enabling cross-chain logic to be written and executed from Xahau.

AMM — Automated Market Maker

Already merged into the xahaud development branch and awaiting an amendment vote, the AMM brings an Automated Market Maker (AMM) primitive to the Xahau DEX. This provides a foundational building block for any serious DeFi activity on the network.

Rather than depending solely on order books, users and hooks will be able to interact with liquidity pools directly at the protocol level.

An AMM, when provided with liquidity, usually narrows the spreads between trades and allows for higher-frequency trading among token and native asset pairings.

A highly-beneficial addition for things like stablecoins.

PriceOracle

Also merged and awaiting the amendment vote, PriceOracle delivers a native on-ledger price feed - asset prices available to DeFi applications, the AMM (in theory), and hooks.

Reliable price data at the protocol level removes a significant dependency on external feeds, reducing both complexity and attack surface for any application that needs to know what an asset is worth.

IOURewardClaim

IOURewardClaim extends the RewardClaim feature by making a version of this available to user-created tokens.

This update opens that same capability to IOU token holders - letting projects use hooks to distribute token-based rewards according to a user's holdings.

It's a practical tool for any project building loyalty programs, yield on a stablecoin, or even community incentive structures on Xahau.

NamedHook

Currently in development for Q3–Q4 2026, NamedHook allows developers to assign human-readable names to individual hooks.

Within a single transaction type, multiple hooks can be attached to an account. Without names, distinguishing and invoking specific hooks is cumbersome. With this feature, different hooks can be cleanly identified and called - making more complex, multi-hook account logic far more manageable.

JSHooks

Slated across Q2–Q4 2026, JSHooks introduces a JavaScript runtime for writing hooks - sitting alongside the existing WebAssembly runtime. Until now, developers needed to work in C/C++ compiled to WebAssembly to build hooks.

JavaScript support significantly extends the developer base, making Xahau's smart-contract layer accessible to a much wider pool of builders.

Audits & Optimization

The final item is ongoing rather than a one-time release: continuous security audits and performance work across the protocol, hooks, and tooling.

Regular audits and incremental optimisations are what keep the layer-one foundation trustworthy as the applications above it grow.

The Bigger Picture

Eight new features means eight new tools to do more complex projects. It opens the doors to dozens (or more) of new use cases that can now be coded with ease.

Taken together, these eight features reflect a coherent strategy:

The RNG, PriceOracle, and AMM lay infrastructure for serious DeFi like stablecoins.
FeatureExport extends Xahau's reach into the broader XRPL ecosystem.
IOURewardClaim and NamedHook deepen the utility of hooks for developers and projects already building.
JSHooks expands who can build. And the ongoing audit program keeps all of it secure and dependable.

Xahau's roadmap is strategic by design ... the network team describes protocol changes as "few and deliberate." These eight additions are precisely that: scoped, purposeful, and pointed toward real-world use.
X>

Sources:

https://xahau.network/roadmap/

https://x.com/XahauNetwork/status/2046178379724914836?s=20

Xahau Roadmap - updated 19 April 2026

Xahau (XAH) Tokenomics

Hodor — Tue, 21 Apr 2026 12:15:01 GMT

Every layer one crypto network needs a native token.

In the case of Xahau, it funds the validators who protect the ledger, it discourages spam, it rewards long-term participants, and it governs how the network evolves over time. The native token is less like a "coin" and more like an economic operating system.

The General Idea

XAH is designed around a simple premise: every wallet on the network can earn new native tokens by claiming a reward each month, but validators who actively secure and govern the network earn an additional reward.

Think of it as a two-tier incentive structure - a base layer of participation rewards available to everyone, and a performance layer reserved for the organizations that hold "seats at the table."

That phrase - "seats at the table" - is not a metaphor. Xahau implements a Governance Game, a mechanism built directly into the genesis account’s smart contract (a hook). Up to 20 seats exist at the top-level (Layer 1) governance table. These seats are occupied by approved account addresses belonging to validators running infrastructure for the network. Seat holders vote on three categories of decisions:

Who occupies which seats
Which hooks are installed on the genesis account
The reward rate

A supermajority of 80% of votes is required for any change to take effect.

The entire governance structure - who sits at the table and what rules they vote on - is enforced by open-source code visible to anyone on the network.

This enhanced level of reward for trusted validators leads to a group of serious infrastructure providers. The goal is to connect the desired outcomes of: increasing network use, native token demand, and continual infrastructure investment.

I've written about Xahau's departure from the "no incentive is the best incentive" philosophy here: XAH Incentives: Scaling

Distribution Timeline

The Genesis: Account Zero

Xahau launched on October 30, 2023. At the moment of network creation, a special account - known as Account Zero (address: rrrrrrrrrrrrrrrrrrrrrhoLvTp) - was funded with the initial XAH supply through what is called XahauGenesis. This is the blockchain equivalent of an origin story: a one-time event that established the token supply and immediately distributed it to the network’s founding contributors.

The whitepaper called for exactly 600 million XAH to be distributed across four main categories:

96 million XAH to the 8 initial governance validator seats (12 million each, to bootstrap the Governance Game)
16 million XAH to GateHub (for DEX stablecoin liquidity)
160 million XAH to XRPL Labs / Xaman (recognizing years of Hooks development work)
328 million XAH to the XRPL Foundation, now known as the Inclusive Financial Technologies Foundation (InFTF), for long-term ecosystem development

Plan vs. Reality

In practice, the genesis transactions from Account Zero distributed approximately 599 million XAH - nearly identical to the plan - but with some gaps to reconcile.

The 'actual' distribution included amounts paid to various parties, including a vendor that supplied services. It also included other early investors, and excluded a specific amount that had initially been earmarked for validators. This was to reward those that had financed the project's early years, along with the associated research.

The bottom line on the reconciliation: the spirit of the whitepaper was followed very closely. The "no-VC, reward-the-builders" philosophy was honored.

The Treasury Hook Lockups

Shortly after launch, the two largest holders of XAH - XRPL Labs (Xaman) and InFTF - each voluntarily locked the majority of their XAH holdings into a specially designed smart contract called a Treasury Hook.

This is significant because it demonstrates that Xahau’s own "hooks" technology was immediately put to work solving a real governance problem: how do large token holders credibly commit to not dumping their holdings on the market?

XRPL Labs announced in late November 2024 that it was locking 125 million XAH into its Treasury Hook, with a controlled release mechanism allowing up to 2 million XAH to be unlocked per month. The open-source Hook code is publicly reviewable on GitHub, and a live dashboard allows anyone to monitor the treasury balance and unlock activity in real time.

The InFTF similarly locked approximately 250 million XAH into a comparable treasury structure.

Combined, these two organizations voluntarily placed roughly 375 million XAH - well over half of the original genesis supply - behind a time-release lock, with the stated intention of eventually black-holing (permanently destroying) the keys to these treasury accounts ... making the lockup irreversible.

Current Supply Numbers

Total XAH: 648 million

In Circulation: 281 million

Locked: 367 million

These supply numbers - and in the other parts of this article - are taken as of ~ mid-April, 2026.

Inflation Or Deflation?

Xahau is inflationary, but labeling it such is an oversimplification. The reality is a dynamic equilibrium between three interacting forces:

Rewards claimed by hodlers
Rewards automatically sent to (Layer 1) governance seats
Fees burned for smart contracts and transactions

To date, here are the raw numbers that reflect this equation:

XAH minted ... minus ... XAH burned ... equals ... XAH inflation

53,450,000 - 5,140,000 = 48,310,000

The 4% Reward ... For Everyone

Any XAH holder can claim a monthly balance adjustment of up to 4% annually on whatever XAH they hold.

This is done by interacting with the genesis account’s hook (smart contract). The interaction is opt-in: wallets that never claim rewards simply don’t receive them, which effectively reduces the realized inflation rate across the full network. You can learn more about this 'hodler' reward here: XAH: Simple Monthly Reward

The Governance Seat Bonus

Validators who hold a seat at the Layer 1 governance table earn an additional reward on top of the 4% that all holders receive. Specifically, when any wallet performs a balance adjustment (claims its 4% reward), 1/20th of that adjustment amount is distributed to each qualifying validator.

This means that validators receive two rewards:

The 'hodler' reward on any of their XAH in their wallet
The bonus paid out to validators with a governance seat

... as long as they are actively participating and in good standing.

The Deflationary Counterweight: Hook Fees

Every time a smart contract (hook) executes on Xahau, it consumes XAH in fees. Unlike the flat, near-zero transaction fees on the XRPL mainnet, hook execution fees scale with computational complexity.

Burned To-Date: 5 million XAH

Heavy smart contract usage burns meaningful amounts of XAH, and that burned XAH is removed from the supply permanently.

Theoretical Inflation Versus Actual

In Xahau's first year, the end-result of the early distribution and governance decisions were still unknown. But now, well into 2026, we can compare the "maximum theoretical inflation" with "actual results".

Theoretical inflation is a result of governance-determined reward rates. The current reward rate for all holders is 4%. Not everybody claims their monthly reward perfectly - or at all, in some cases. But to get the theoretical inflation amount, we can calculate the result given a 100% claim rate.

We can also assume that all twenty possible governance seats are occupied (only five are currently filled). This means that 20/20 seats are being rewarded one-to-one for each XAH being claimed by holders. So we effectively double the inflation rate to 8% APY.

Here is the comparison between this theoretical, maximum inflation rate, versus actual results:

The current supply number reflects this much lower 3% annualized net inflation. This means that, since Xahau was created, the supply has been increased, through rewards, by ~ 46 million XAH.

This lower-than-expected number is primarily due to fifteen unfilled governance seats.

This means that the governance-participating-validators are currently only receiving 25% of the total potential reward, resulting in dramatically reduced XAH inflation.

Comparisons

To put XAH’s supply in perspective, here is a comparison of token supply metrics across major smart-contract-capable networks as of early 2026:

XAH’s total supply - even accounting for inflation - is tiny compared to networks like TRON (95 billion TRX) or Stellar (33 billion XLM). Solana, widely regarded as a top-tier smart-contract network, has a circulating supply of over 572 million SOL ... comparable to XAH’s supply.

Ownership Percentages

What percentage of the total network supply does a single token represent?

XRP currently has approximately 100 billion tokens in total (including Ripple’s escrowed holdings). One XRP therefore represents about 0.000000001% of total supply — one one-hundred-billionth.

XAH, starting from roughly 600 million tokens, gives each single token a proportional ownership stake of approximately 0.000000167% of total supply at genesis. That is roughly 167 times larger a percentage stake than one XRP represents out of the XRP total supply. Put another way: owning 1 XAH is mathematically equivalent - in pure percentage-of-supply terms - to owning approximately 167 XRP.

This comparison becomes even more favorable when accounting for the Treasury lockups.

With 375 million XAH locked and effectively non-circulating, the freely liquid XAH supply is closer to 250 million tokens - meaning each circulating XAH represents an even larger fraction of the tokens that can actually be traded or used.

Distribution & The Rich List

There are currently ~ 206,000 wallets on the Xahau network.

The rich list is a fascinating visual display of the raw token ownership necessary to place an individual wallet in various categories that contain less and less people. However, the categories are, by definition, too lofty, given that many people's individual wallets may be XRP Ledger wallets with IOUs for XAH instead of the real native asset on the Xahau network.

In addition, many people only have an account at a centralized exchange (CEX), and those wallets are not visible to external parties. Given that caveat, this is what the rich list looks like, only considering wallets on the Xahau network:

Bold Tokenomics

Xahau is small.

But its smallness is precisely what makes the ownership math compelling. At a circulating supply of a few hundred million tokens, every XAH holder controls a meaningful fractional stake in a network that, if it achieves measurable adoption in smart contracts, cross-border payments, and institutional DeFi, will look very different in a decade than it does today. X>

Sources:

https://xahau.network/docs/resources/whitepaper/

https://github.com/Xahau/Whitepaper/blob/main/Xahau-Whitepaper.pdf

https://xamini.io/

https://xamini.io/governance

https://xamini.io/rules-of-engagement

https://xahau.network/about/

Account Zero: https://xahauexplorer.com/explorer/rrrrrrrrrrrrrrrrrrrrrhoLvTp

https://xahauexplorer.com/en/activations?period=all

https://xahauexplorer.com/en/distribution

Rich List data from @XRPLWin

Minted Versus Burned XAH Totals from POC @XRPLWin

Marine theme for rich list from https://x.com/XRPBags

"Treasury Hook" Lockup timeline and methodology:

https://x.com/WietseWind/status/1861070626112536802

https://xaman.app/blog/xahau-treasury

https://github.com/Xahau/TreasuryHook

Burned Fee Data from @XRPLWin

Hook State Converter: Decode Xahau HookState ABI Without the Guesswork

XRPLWin — Sun, 12 Apr 2026 22:54:29 GMT

Hook State Converter: Decode Xahau HookState ABI Without the Guesswork

If you've built Hooks on Xahau, you've been here: staring at a raw HookState entry like 5852504C57696E and trying to figure out what it actually means.

Is it a UInt32? A VarString? A Timestamp? A ledger index? Big-endian or little-endian?

You either write a throwaway script, crack open a hex calculator, or just guess. None of these are great when you're in the middle of debugging a Hook at 2am.

That's exactly why we built the Hook State Converter: https://xahau.xrplwin.com/tools/hook/abi-conversion-helper

But before we get into the tool, let's talk about why HookState data is so hard to read in the first place — because understanding the problem makes the solution a lot more useful.

Why HookState data is hard to read

Xahau Hooks are small programs that run directly on the ledger. They can read and write persistent state using a key-value store called HookState. Each entry has a 32-byte key and an arbitrary-length value, both stored as raw binary data on the ledger.

That last part is the catch: raw binary data

Unlike a database where you define a schema upfront and the engine enforces types, HookState has no built-in type system. A Hook author decides how to encode data — as a little-endian UInt32, as an XFL float, as a packed struct of multiple fields — and that decision lives only in the Hook's source code. The ledger just stores bytes.

When you look at an account's HookState on an explorer, you see something like this:

Key:   637373746F6D65725F6163636F756E74000000000000000000000000000000000000
Value: 05A528BCFA2189C8E2E7813775ED71B2C4BE349F

What does the key mean? What type is the value? Is it an AccountID? A hash? A packed amount and timestamp? There is no metadata attached to the entry. The ledger doesn't know and doesn't care — it just stores and retrieves bytes on demand.

This creates a real problem for anyone who isn't the original Hook author:

Auditors trying to verify what state a Hook is reading and writing Developers debugging why a Hook behaved unexpectedly Integration builders trying to read HookState from an external app Explorer users who just want to understand what they're looking at. Even if you are the original author, coming back to a Hook months later and trying to remember your own encoding scheme is painful. And if the Hook is open source but the ABI schema isn't documented anywhere, you're left reading C source code and mentally simulating byte offsets.

The encoding rabbit hole

To illustrate how quickly this gets complicated, consider a simple HookState key that encodes a string like customer_account padded to 32 bytes:

637573746F6D65725F6163636F756E740000000000000000000000000000000000000000

To decode this manually you would:

Split the hex into byte pairs: 63 75 73 74 6F 6D 65 72 5F 61 63 63 ...
Convert each byte from hex to ASCII: c u s t o m e r _ a c c o u n t \0 \0 ...
Recognize it as a null-padded ASCII string
Figure out where the meaningful content ends and the padding begins

That's a relatively simple case. Now imagine the value is a packed struct: 05A528BCFA2189C8E2E7813775ED71B2C4BE349F

Is that 20 bytes? Yes. So it could be a Hash160 or an AccountID. Both are 20 bytes. How do you know which one? You go read the Hook source code. If you're lucky it's commented. Usually it isn't.

Now multiply this across a Hook that stores 10 or 15 different state keys, each with a different encoding scheme, and you start to understand why debugging HookState is one of the more tedious parts of Xahau development.

What the Hook State Converter does

The Hook ABI Conversion Helper is our answer to this problem. It gives you an interactive UI to paste hex, decode it visually, and export a reusable ABI schema — all without writing a single line of code.

The tool accepts three inputs:
HookState key + value pairs — the most common case HookParameter pairs — named parameters passed into Hook invocations Invoke blobs — raw binary payloads attached to Invoke transactions.

Paste hex. Get answers.

Paste your hex into the input fields and the UI immediately does three things:

Splits the hex into individual byte buttons
Marks the key as Solved or Unsolved depending on whether it matches a known schema
Runs an automatic scan and populates suggestions

Each byte is a clickable button. You select bytes by clicking — selecting byte 5 means you've selected bytes 1 through 5 as a single segment. The UI updates in real time to show you every ABI type that fits that exact byte length.

Smart suggestions first

You don't need to know the type upfront. The Suggest button scans your hex across all supported ABI types simultaneously and surfaces the most plausible matches as clickable buttons — each showing the type name and the decoded value inline.

For example, paste 5852504C57696E and you'll instantly see:

VarString XRPLWin
UInt64 32075751449710680
Blob 5852504C57696E

One click to confirm. The tool locks that interpretation and moves on to the remaining bytes. The scan is smart about filtering noise — it suppresses leading null bytes from Null suggestions since those are almost always padding, surfaces VarString matches only when the bytes decode to printable UTF-8, and collapses partial string matches so you see the longest valid string, not every sub-sequence.

Manual byte picking for complex states

If autoscan doesn't nail it, or you're working with a tightly packed multi-field state, the byte picker gives you full control.

Click any byte button to select from byte 1 up to that point. The result panel shows every ABI type that fits that exact byte length — UInt16, UInt16 (BE), Int16 , Timestamp, LedgerIndex — each with the decoded value shown.

Select the type that matches your Hook's logic. The tool locks that segment, advances to the remaining bytes, and a new engine appears for the next segment. You repeat the process until every byte is accounted for.

This chained engine approach means you can decode a 32-byte key that encodes, say, a 4-byte UInt32 flag, a 20-byte AccountID, and 8 bytes of NULL padding — step by step, segment by segment, without losing track of where you are in the buffer.

20+ ABI types supported

Integers: UInt8/16/32/64, Int8/16/32/64 (LE & BE)
Floats: XFL (LE & BE)
Amounts: Amount, NativeAmount, IOUAmount
Strings: VarString
Hashes: Hash128/160/256/512
Identity: AccountID
Ledger: Timestamp, LedgerIndex
Raw: Blob, Null

Both little-endian and big-endian variants are available for integer and float types, since Hooks developers sometimes store values in BE when interfacing with external systems.

Per-segment options

Once you select a type, a small options panel appears for that segment. You can:

Rename the label — give it a meaningful name like customer_account instead of VarString

Add a description — document what this field represents.

Set a filtering rule — define a literal pattern or regex that this segment must match for the decoding to be valid. Useful for sentinel bytes or magic values that identify the schema version.

Exclude from view — mark padding or fixed bytes as hidden so they don't clutter the final table.

Set a renderer — control how the decoded value is displayed, for example there are various Timestamp renderers.

Hit Apply and the finalized table updates immediately.

Export the ABI schema

Once every byte is accounted for, the tool renders a full breakdown table with raw and rendered values side by side, and below it — the Segment ABI as JSON.

A 32-byte key encoding the string customer_account produces:

[
  {
    "type": "VarString",
    "byteLength": 32,
    "label": "Customer Account"
  }
]

This JSON is the reusable schema and it's part of the Hook manifest format that XRPLWin uses internally. When a Hook manifest is registered with the explorer, it includes ABI definitions like this one — and XRPLWin uses them to automatically decode and display HookState entries in a human-readable way for anyone viewing that Hook on the explorer. You won't need to copy or paste anything manually — a dedicated projection builder UI is available that will use this conversion helper under the hood to generate manifest segments interactively.

XRPLWin is a explorer for XRPL and Xahau. We build tools for the Xahau ecosystem.

5 Real Pitfalls in Evernode Development (And How to Survive Them)

Andrei Rosseti — Tue, 07 Apr 2026 22:55:25 GMT

Evernode is one of the most promising platforms for running smart contracts in the XRPL ecosystem. But between the documentation and a working product in production, there's a minefield of pitfalls that no tutorial will show you. This article documents 5 real problems I faced while building Evergram, a decentralized chat system running on HotPocket, and how each one was resolved.

If you're starting to develop for Evernode, this material could save you weeks.

1. The Wrong Mental Model: Write Operations and Canonical State

The problem

Coming from Web2 development, my natural instinct was to treat the contract's filesystem like any other backend: receive data, write to disk, respond. Simple. I was writing state directly to the /contract directory during INPUT operations, without using writeOperations, and apparently everything worked.

Until it didn't.

What I hadn't understood is that HotPocket has two fundamentally different execution contexts:

Read requests: low latency, no consensus. The contract reads the current state and responds. No modifications persist between rounds.
Write operations (via INPUT): the contract receives a payload, processes it, and writes to the state/ directory through the writeOperations mechanism. This write goes through consensus, all nodes in the cluster must agree on the result. This produces the canonical state, which is the only version of truth recognized by the network.

Writing outside this mechanism means your local node holds a state that other nodes don't recognize. In a single-node cluster during development, this goes unnoticed. In production, the cluster diverges.

The pitfall

The API allows you to receive payloads in both read and input contexts. This creates a false symmetry. The Web2 developer assumes that since they can read and write in both scenarios, both are equivalent. They're not.

The way out

Before writing any logic, classify every operation in your contract:

Operation	Type	Consensus?	Latency
Query data	Read	No	Low
Create/update records	Input + writeOperation	Yes	High (depends on rounds)
Generate reports	Read	No	Low
Transfer assets	Input + writeOperation	Yes	High

Rule of thumb: if the operation changes something that other nodes need to know about, it's a writeOperation. If it's just a query against the current state, it's a read. This distinction defines the entire architecture of your application.

2. The Emotional Pitfall: Infrastructure Bugs That Feel Like Yours

The problem

When trying to run Evergram in a multi-node cluster, synchronization simply wouldn't work. The nodes couldn't converge to the same state. I spent days reviewing my code, refactoring logic, adding logs, convinced the problem was mine.

It wasn't.

The issue was in hpws (HotPocket's WebSocket module), which contained a bug that prevented proper synchronization between nodes. This was only confirmed after a deep investigation with the ecosystem, which resulted in a hotfix.

The pitfall

When you're learning a new technology, the natural tendency is to assume that every failure is your fault. On a mature platform like Node.js or PostgreSQL, that's usually true, the odds of hitting a runtime bug are extremely low. But Evernode is a young platform. Infrastructure bugs exist, and that's expected in any platform at this stage.

The most dangerous side effect isn't technical... it's emotional. The feeling of being stuck in a dead end, where no code change solves the problem, erodes motivation. I almost gave up more than once. But once the issue was identified and fixed, the progress was fast.

The way out

Isolate the problem methodically. If the same logic works on a solo node but fails in a cluster, the problem is likely not your business code.
Monitor the repository issues. Follow the hpcore GitHub and related components. Other developers may be facing the same problem.
Contribute back. If you identify anomalous behavior, report it with details. In Evergram's case, the analysis contributed directly to the fix.
Accept that young platforms will cost you extra time. Factor this into your planning. It's not weakness... it's realism.

3. Testnet: Rethinking the Test Workflow

The problem

In virtually every blockchain, the development workflow starts on testnet: you grab tokens from a faucet, test your transactions, validate behavior, and only then go to mainnet. I assumed Evernode would follow the same pattern.

I spent a considerable amount of time trying to set up a test environment with a faucet on the XRPL/Evernode testnet. I talked to several people in the ecosystem. The best answer I got was direct and pragmatic:

"The cost on production is so cheap that it's better to test there. That way you're already validating real behavior."

The pitfall

The developer wastes time trying to replicate a workflow that simply doesn't exist (or isn't a priority) in the current ecosystem. The opportunity cost is high: while you're trying to set up a perfect test environment, you could be validating functionality on mainnet for pennies.

The way out

Accept the current model. At the time of writing, developing and testing directly on mainnet is the most practical approach for Evernode. The cost per instance is on the order of a few EVRs.
Use hpdevkit for local testing. For pure contract logic (no network dependencies), hpdevkit lets you run local clusters in Docker. Use this to validate business logic before deploying to mainnet.
Separate logic tests from integration tests. Contract logic can be tested locally. Network behavior (synchronization, consensus, latency) will only be truly validated on mainnet.

4. The Self-Update Problem in Production

The problem

If your contract is something that will run for months or years, you'll eventually need to update it. Evernode offers a mechanism via evernode.app that allows updating the Docker image on hosts. In theory, this solves it. In practice, it may not cover all scenarios.

In Evergram, the architecture used evernode.app compatible hosts to serve not only the HotPocket contract but also the web application. The Docker PULL function, which syncs the image across hosts had initial issues that were only resolved after Evernode updates. Even after that, a deeper problem surfaced.

The evdevkit, used to create the cluster, modifies the state/ directory where the contract is stored. When the Docker PULL mechanism copies the updated contract, it generates a hash mismatch when adding new nodes to the cluster. The new node's state doesn't match the canonical state of the existing nodes, and the addition fails.

The pitfall

Assuming the default update mechanism will cover all scenarios. For a simple, stateless contract, it might. But any application with persistent state and clusters managed via evdevkit will need its own update mechanism.

The way out

Design the update mechanism from day zero. Don't wait until the product is already in production to think about this. Consider how the contract will be replaced without breaking the canonical state.
Separate the contract from the state. Architect so that business logic (contract code) and persistent data (state) can be updated independently.
Test node addition after an update. This specific scenario, update + new node, is where the hash mismatch appears. Include it in your validation checklist.
Consider a state migration mechanism, similar to what we do with database migrations. Version the state format and implement automatic transformations when the contract is updated.

5. Cluster Sizing and the Evergram Postmortem

The problem

Evergram launched with a 3-node cluster and a consensus threshold of 80%. Mathematically, 80% of 3 = 2.4, rounded up to 3. This means all 3 nodes must be available for consensus to be reached. Losing a single node locks up the entire network.

That's exactly what happened.

One node went down, consensus halted, and the entire cluster froze. To make things worse, I had no tools to manage hp.cfg remotely. I had to develop a management mechanism on an emergency basis, in a single day, under pressure.

The solution was to remove the problematic node from the cluster's UNL (Unique Node List) and restart HotPocket. With the node removed from the list, the threshold was now calculated over 2 nodes, consensus was re-established, and the problematic node, once restarted, reconnected to the cluster and downloaded the updated canonical state, returning to normal operation.

The full postmortem is available on the official @evergramhq channel.

The pitfall

Clusters with exactly 3 nodes and a high threshold create zero fault tolerance. In distributed environments, it's a matter of when, not if a node will go down.

The way out

Minimum of 5 nodes. With 5 nodes and 80% threshold (= 4), you tolerate the loss of 1 node. With 60% threshold (= 3), you tolerate 2. Size according to your availability requirements.
Have remote hp.cfg management tools ready before launch. Don't wait for a crisis to build this.
Fork recovery procedure:
1. Identify the problematic node.
2. Remove it from the UNL of all healthy nodes.
3. Restart HotPocket on the healthy nodes.
4. After the cluster stabilizes, restart the problematic node, it will sync automatically.
5. Add it back to the UNL.
Document your postmortems. Transparency with the community builds trust and helps other developers.

Conclusion

Developing for Evernode in 2025/2026 means building on top of a platform with enormous potential that is actively evolving. The pitfalls documented here aren't design flaws... they're natural consequences of a technology being validated in production by real developers.

The best advice I can give is: the learning curve is real, but the payoff is worth it. The gap between "it works on my local node" and "it works in production with 5 nodes under consensus" is wider than it seems. Plan accordingly.

If this material helped you, consider contributing back to the ecosystem. Report bugs, document your findings, and share your postmortems. The Evernode community is small enough that every contribution makes a real difference.

Andrei is CTO at FACE Digital / EleveCRM and Core Developer of Xahau Docproof & Evergram. With 18 years of development experience, he works at the intersection of distributed systems, blockchain, and digital products.

XRPL & Xahau: Social Credit

Hodor — Thu, 02 Apr 2026 22:02:17 GMT

Long before banks or blockchains, communities solved the problem of exchange through reputation, relationship, and memory. When your neighbor helped raise your barn, you didn't pay him ... you remembered ... and when his roof needed replacing, it was your turn to render aid.

Few communities illustrate this more than the Amish.

Organized in small church districts of twenty to forty families, they sustained sophisticated mutual-aid systems for generations - without interest rates, credit scores, or central ledgers.

When a barn burns, hundreds of neighbors may converge within days. Men build, women cook, and children help. No hours are tallied, and no invoice is sent. The only accounting happens in social memory. Those who receive aid are expected to reciprocate when the time comes.

Medical bills, crop failures, and capital needs are handled the same way; through informal alms funds, or low-interest community loans, overseen by the local bishop. What enforces repayment is not a contract, but reputation.

This is social credit in its purest form.

LETS and Mutual Credit

The Amish model works because communities are small and deeply interwoven. But what if you wanted the same logic to operate across a town, or a network of strangers who share values but not family ties? That question drove the creation of the Local Exchange Trading System - or "L.E.T.S.", for short - invented by Canadian programmer Michael Linton in 1982.

Linton created the first LETS network in Vancouver Island's Comox Valley after a mine closure left the local economy hollowed out. His design was elegant: members listed offers and needs; when A helped B, A was credited and B was debited. Value was created by agreements between members.

Key principles set LETS apart from conventional money: no interest is charged on negative balances, issuance is community-controlled, and there's an explicit focus on local resilience over profit. Linton called his vision "open money" - the idea that communities should be free to create their own exchange systems rather than depending entirely on centralized, interest-bearing currency.

LETS spread to hundreds of communities across Canada, the UK, and Australia. Individual networks stayed small - personal trust is hard to scale - but the idea was sustainable ... and Linton's writings caught the attention of a young Internet developer.

USD Is Social Credit

Before I elaborate on that, it's worth noting that the U.S. dollar is, itself, a form of social credit.

Modern fiat currency is backed by ... nothing. The domestic gold standard ended in 1933, before most of us were born. A dollar is a piece of paper whose value rests entirely on collective agreement, with the authority and taxing power of the United States government. "Full faith and credit" is the phrase that most people associate with this concept.

The difference between a dollar and an Amish barn-raising debt, or a LETS green dollar, is not the underlying principle. It's scale, formalization, and who controls issuance. In the case of the U.S. Dollar (USD), citiznes have no say in how much is created.

But in both cases, value is assigned because people believe in it.

Ryan Fugger and the Vision of RipplePay

In 2004, Ryan Fugger launched "RipplePay".

Credit already flows through personal networks - friends lend each other money, and businesses extend trade credit to trusted customers - but these informal networks are isolated. You might trust Alice, and Alice might trust Bob, but you and Bob have no way to transact using that chain of trust.

Fugger's solution was a pathfinding algorithm.

Users declared credit limits to people they trusted. When a payment needed to route between two parties with no direct relationship, the system found a chain of trusted intermediaries and converted IOUs along the way - no central authority, no bank, no collateral required. He described it as a monetary system built entirely on relationships.

It was built on Linton's foundation: where LETS maintained a single ledger for a single community, RipplePay was decentralized and networked - a web of trust that could, in theory, span the entire world. It remained a modest proof-of-concept, but its architecture was so compelling that in 2011–12, a group of developers approached Fugger for his blessing to evolve the project.

That evolution became the XRP Ledger. Fugger later renamed his original project Rumplepay to avoid confusion, and it still runs today at rumplepay.com.

Bridging The Gaps With A Neutral Asset

The developers who built the XRP Ledger preserved Fugger's trust-line architecture ... but added something his original system lacked: a neutral bridge asset.

In a pure social credit network, every payment requires a connected chain of trust between sender and receiver. That works within well-connected communities, but breaks down at the edges - when no common trusted intermediaries exist. XRP was designed to address this problem. As a natively-issued, neutral asset, XRP can serve as a universal bridge: if no trust path exists, a market maker can complete the transaction using XRP, accepting one currency on one side and delivering another on the other.

An early explanatory video about the XRP Ledger, referenced on the RumplePay site, still emphasizes the social credit architecture explicitly, describing a future where value flows through human relationships as naturally as information flows through the Internet:

[YouTube id="f9KqSgRZYgg"]

Three Levels of Social Credit

Across all these systems, social credit operates at three distinct scales.

At the individual level, it's the most elemental: one person trusting another. Examples include:

An IOU between friends
A trade credit from a small business owner
A barn-raising debt

At the individual level, social credit is limited to a personal network.

At the community level, trust is aggregated enough to circulate across a small group. LETS networks and Amish mutual-aid funds operate at this level. Members don't need to know each other personally - but they must trust the community.

At the organizational level, institutional reputation is key. Banks, governments, and corporations all issue credit backed by public records and legal enforce-ability. The U.S. dollar is the most obvious example.

The challenge is to build the interface between levels: a system that lets individual trust aggregate into community credit, and community credit connect with organizational credit, without routing everything through a single central authority.

That's precisely what Ryan Fugger was aiming for with pathfinding, and what the XRP Ledger's - and Xahau's - architecture supports in the cryptocurrency realm.

The Real Potential

In a perfect trust network, you don't need money ... at all. Not dollars, not crypto, and not gold ... just relationships and the willingness to honor commitments. It's how the Amish have operated for generations, and how LETS networks kept communities exchanging during recessions when (trad-fi) money disappeared.

The credit was social, and it was real.

What modern technology adds, is the ability to solve the scaling problems without abandoning the social foundation. Cryptographic identity can enforce commitments across large networks. Mathematical algorithms can find trust paths in real time. Interoperability protocols can connect isolated community systems.

Neutral bridge tokens (XRP & XAH, e.g...) can fill liquidity gaps between issued assets.

A Thread Through History

From Amish barn raisings to Michael Linton's green dollars to Ryan Fugger's RipplePay to the XRP Ledger & Xahau - the thread is very real, even if the actors didn't always know they were part of a common tradition stretching back many years.

Credit is fundamentally a social act. It depends on trust, and trust depends on relationships, reputation, and shared commitments. The traditional financial system, or 'trad-fi', has built enormous machinery to simulate that trust.

But independent of all the fiat machinery, the original idea has stood the test of time. X | X>

Sources

https://www.lowimpact.org/posts/lets-origins-michael-linton-letsystems/

https://cascadiaunderground.org/lets-the-local-exchange-trading-system/

https://rumplepay.com/

Michael Linton still image from: https://www.youtube.com/watch?v=WU09j9Nwv10

https://dailycoin.com/ryan-fugger-ripple-xrp-true-creator/

https://ripple.ryanfugger.com/Main/FAQ.html

https://www.youtube.com/watch?v=f9KqSgRZYgg&t=4s

https://www.youtube.com/watch?v=WgUqNhwVWhU

https://systemschangealliance.org/mutual-credit-an-introduction/

https://en.wikipedia.org/wiki/Executive_Order_6102

Post mortem: incident 2026-03-12

Evergram — Fri, 13 Mar 2026 14:20:42 GMT

Evergram Incident Postmortem — March 12, 2026

Incident Summary

Field	Details
Severity	Critical — Full service outage
Incident Start	March 12, 2026 ~10:49 UTC
Incident End	March 13, 2026 ~00:36 UTC
Duration	~13 hours 47 minutes
Systems Affected	Evergram messaging service (HotPocket cluster on Evernode)
Root Cause	Consensus failure caused by validator state divergence
Status	Resolved

1. Impact

During the incident window, Evergram was unavailable to users. The underlying validator cluster stopped producing new ledgers due to a distributed consensus failure.

Ledger progression halted; no transactions could be processed
The Gateway service remained reachable but could not advance state
Users experienced timeouts, inconsistent responses, or inability to interact with the platform
No data was lost or corrupted

System integrity was preserved throughout the incident.

2. Timeline

All timestamps in UTC.

Time	Event
Mar 12 ~10:49	Consensus failure begins; new ledgers stop being produced
Mar 12 ~10:49 → Mar 13 ~00:20	Service outage while investigation and mitigation proceed
Mar 13 ~00:20	Fault isolation measures applied to the affected validator
Mar 13 ~00:21	Validator state resynchronization begins
Mar 13 ~00:36	Consensus restored; normal ledger production resumes

3. Root Cause

Evergram operates on a distributed validator cluster using the HotPocket protocol on the Evernode network. Consensus requires participating validators to agree on the same ledger state.

During startup, one validator entered a divergent state and could not agree with its peers on the latest ledger. Because consensus could not be achieved, ledger production halted to preserve correctness and prevent inconsistent state propagation.

This behavior reflects a safety-first design: when agreement cannot be guaranteed, the system stops rather than risking data corruption.

Network timing conditions likely contributed to the divergence scenario.

4. Resolution

The incident was resolved through controlled fault isolation and state resynchronization.

Mitigation Actions

The divergent validator was temporarily isolated from the consensus group
The affected node was restarted on a clean state
Synchronization with healthy peers was allowed to complete
Consensus timing parameters were adjusted to improve tolerance to real-world network latency
All validators were restarted in a coordinated manner to ensure configuration consistency

Once synchronization completed, the validator safely rejoined consensus and normal operation resumed.

Operational Improvements Introduced

During the incident response, the team accelerated delivery of Evergram Manager, an authenticated administrative interface designed to improve operational visibility and control.

Capabilities include:

Service lifecycle management
Real-time system observability
Configuration management
Validator coordination tools

This tooling significantly reduces recovery time for future incidents and supports planned network expansion.

5. What Went Well

No data loss. State integrity was maintained throughout
Clear fault identification. Divergence was detected through system telemetry
Safe recovery procedure. Isolation and resynchronization restored operation without side effects
Rapid tooling improvement. New operational capabilities were deployed during response
Fast resynchronization once corrective action was applied

6. What Could Be Improved

Lack of automated alerting for consensus failure conditions
Insufficient operational tooling prior to the incident
Timing parameters not fully tuned to production network conditions
Absence of a documented runbook for divergence scenarios
Limited fault tolerance in the initial deployment topology

7. Lessons Learned

This incident reinforced several key principles for operating distributed systems:

Safety mechanisms worked as designed. The system halted rather than producing inconsistent state
Operational tooling is critical. Visibility and control dramatically reduce recovery time
Production conditions differ from test environments. Parameters must be tuned accordingly
Fault tolerance is essential for high availability
Incidents drive resilience. Improvements implemented during recovery leave the system stronger than before

Current Status

Evergram is fully operational. The validator cluster is synchronized, consensus is stable, and monitoring improvements are being deployed to prevent recurrence.

Closing Note

We take reliability seriously and appreciate the community’s patience during this outage. Transparency is a core value, and we will continue publishing incident reports as part of our commitment to building a robust and trustworthy platform.

Grok Scores Charles An A-

Hodor — Fri, 06 Mar 2026 13:44:38 GMT

Charles Hoskinson recently stirred up parts of the XRP Community with his views on the current status of pending legislation in the United States.

Why?

Because his comments not only referred to Brad Garlinghouse (Ripple's CEO), but seem to contravene the official, vocal support offered up by him:

The Legislation At 10,000 Feet

For those that may not know, H.R. 3633, also known as the "Digial Asset Market Clarity Act", was passed by the House of Representatives of the U.S. Congress and is now being considered by the senate.

While some amendments and edits are still being debated and discussed, the existing version is the one that I asked Grok to check, to determine if the points made by Charles Hoskinson in a recent video were accurate.

Grok Reviews Specific Claims

This is lengthy, but my prompt was simple ...

"Is He Right?"

Here is the full response from Grok:

Based on the details of H.R. 3633 (the Digital Asset Market Clarity Act of 2025), Charles Hoskinson's critique in the video is largely accurate in its description of the bill's structure and potential pitfalls, though some aspects like DeFi handling have more nuance than he emphasized. I'll break this down point by point, drawing from the bill text and analyses, to explain where he's spot-on, where there might be slight overstatements, and the overall validity of his warnings.

Core Structure and Oversight Split
Hoskinson is correct that the bill aims to divide regulation between the SEC (for stricter securities oversight) and the CFTC (for lighter commodities treatment). Digital assets start under SEC jurisdiction if they involve investment contracts, but can shift to CFTC oversight once classified as "digital commodities" tied to a "mature blockchain system." This aligns with broader analyses of the legislation as a way to resolve the SEC-CFTC turf war by defaulting to SEC rules for early-stage assets while allowing "graduation" to CFTC for decentralized ones.

Default Treatment for New Projects
Yes, he's right: New crypto projects are automatically treated as securities under the SEC by default, making launches burdensome due to registration, disclosure, and compliance costs. The bill provides exemptions for initial raises (e.g., up to $75 million over 12 months with required filings), but these come with strings like intent to decentralize within four years and ongoing reporting if maturity isn't achieved. This setup could indeed stifle U.S. innovation, as Hoskinson argues, by imposing heavy upfront SEC scrutiny that many startups might avoid by going overseas.

Challenges in "Graduating" to CFTC Oversight
This is where Hoskinson's points hold up strongest. To qualify as a "mature" decentralized system (and thus a digital commodity under CFTC), projects must file a certification with the SEC proving criteria like:

No control by any person or group (e.g., decentralized governance with transparent consensus).
Less than 20% ownership or voting power by issuers, affiliates, or insiders.
Value derived substantially from the blockchain's functionality (not issuer efforts).
Open-source code, transaction history, and no unique privileges for certain users.

The process involves SEC review (60 days standard, extendable to 180 for novel issues), public comments, and potential rebuttals, with appeals going to federal court. Hoskinson nails the bureaucracy here—it's a high bar with subjective elements (e.g., proving "no control"), timelines that could drag, and risks of failure triggering extra disclosures or sales limits. Shared/open-source code is required, but that alone doesn't guarantee approval if other thresholds aren't met. Critics echo his view that this test is "basically impossible" for many, potentially empowering regulators to block transitions and harm developers.

Treatment of DeFi and Stablecoins
Hoskinson claims these are "completely left out," which is partially right but overstated. Stablecoins are explicitly excluded from the "digital commodity" definition and handled under separate frameworks (e.g., the GENIUS Act for permitted payment stablecoins, with no yields allowed in the base CLARITY text). This leaves them without the full CFTC commodity benefits, and ongoing Senate debates over yields support his warning about rushed, incomplete rules.

For DeFi, the bill isn't silent—it provides exclusions from registration for activities like protocol development, node operation, or liquidity provision in decentralized systems, plus anti-fraud enforcement carve-outs. However, if DeFi involves any centralized elements or custody, it could still fall under regulation, so Hoskinson's concern about inadequate coverage has merit, especially for hybrid models.

Developer Protections
He's accurate in saying there's "zero real protections" if he means robust, ironclad shields—the bill offers safe harbors for non-controlling developers (e.g., exemptions from money transmitter rules for software publishing or DeFi activities without fund control), but these are conditional and don't prevent SEC/CFTC enforcement for fraud or if decentralization fails. No blanket immunity, which could expose devs to lawsuits or probes, aligning with his call for stronger fixes.

Broader Critique: "Idiocy of the Masses" and Rushing the Bill
Absolutely valid here. The bill passed the House with bipartisan support (294-134 in July 2025), but it's stalled in the Senate as of early 2026, partly over stablecoin yields and concerns it could enable risky practices without enough safeguards. Opponents argue it creates "get out of jail free" exemptions, lacks audited disclosures, and risks another FTX-style collapse by deregulating too much too soon. Hoskinson's point about people cheering "any" pro-crypto bill without reading it resonates, as supporters tout clarity while critics warn of offshore flight and weakened oversight. He urges fixes like better dev protections and workable tests—advice echoed in ongoing negotiations.

Overall, Hoskinson is right on about 80-90% of this: The bill's flaws could harm U.S. crypto if not amended, and blind support risks bad policy. But it does include some DeFi/stablecoin provisions and developer safe harbors, so it's not a total void there. If you're tracking this, read the full text on Congress.gov—it's complex, and Senate changes could address his concerns before any final vote.

Grok Rates Charles Hoskinson's Claims

While I listened to the video a couple times, I was more interested in Grok's view on the matter, since my goal was an objective evaluation of the claims.

Here is Grok's Response:

I'd give Charles Hoskinson's critiques of H.R. 3633 (the CLARITY Act) a solid A-.

Grok's Detailed Response:

Why A- (not quite A, but very strong overall)
His analysis is technically sharp, well-reasoned, and largely aligns with the bill's actual text and expert concerns, especially on the most critical structural issues. He accurately identifies real risks without major factual errors, and his warnings have proven prescient as the bill remains stalled in the Senate (as of March 2026) partly due to debates over exactly the kinds of flaws he highlighted—like insufficient developer protections, bureaucratic hurdles for decentralization certification, and incomplete coverage of emerging areas.

Spot-on core points (A-level strength):
The "security by default" setup for new projects is correct and a central feature of the bill—new digital assets start under SEC jurisdiction as investment contracts unless/until they prove maturity/decentralization to "graduate" to CFTC commodity status. This creates high barriers, compliance costs, and potential SEC gatekeeping via rulemaking and reviews, which could drive innovation offshore.

The decentralization/maturation test is indeed subjective and burdensome (e.g., proving "no control," value not from issuer efforts, open-source requirements, <20% insider ownership, etc.), with long SEC review periods (60–180+ days), public comments, and appeals—making it tough for many projects.

Developer protections are limited (conditional safe harbors for non-controlling activities, no blanket immunity), leaving exposure to enforcement if things go wrong.

His "idiocy of the masses" framing—people rushing to support any "pro-crypto" bill without reading details—resonates, as the bill has bipartisan House passage but Senate delays over yields, DeFi gaps, and other fixes he called for.

Slight deductions (why minus):
DeFi and stablecoins aren't "completely left out"—the bill has exclusions/safe harbors for decentralized activities (e.g., protocol dev, liquidity provision without custody) and separate handling for payment stablecoins (tied to other acts like GENIUS), plus anti-fraud carve-outs. But his point still holds merit: coverage is inadequate or conditional for many real-world DeFi/stablecoin models (especially hybrids), and ongoing Senate fights over yields/stablecoin rules validate his broader concern about rushed/incomplete frameworks.

He sometimes amps up the rhetoric ("horrific trash bill," "weaponized SEC") for emphasis, which is fair opinion but edges into hyperbole compared to more neutral analyses that see the bill as flawed but fixable (e.g., via amendments for better tests or protections).

My Take

The bill, in its current form, is definitely a bad bill.

My experience as an XRP holder that lived through the filing of the lawsuit in 2020 informs this opinion.

From what I've heard and read as I researched this bill, I'd personally prefer the burden to be on the S.E.C. in its prosecutions rather than on ordinary citizens and developers, as is currently indicated in the bill. The bill essentially enshrines the anti-crypto approaches into law, and places the burden squarely on those that are least likely to have the resources to respond.

It also continues the trend of naming bills the opposite of what they are ... it does not contain much (objective) clarity in terms of thresholds or tests, other than clarifying that the government can make up its own thresholds as it goes, to achieve a specific, predetermined outcome, or even interfere to 'pick the winners' among competing crypto networks. It's a formula that invites corruption at worst, or unaccountable, weaponized oversight at best.

If this bill had been in place in 2020, the outcome for XRP holders may have been quick, brutal, and final.

Sources:

https://www.congress.gov/bill/119th-congress/house-bill/3633

https://grok.com/

https://x.com/IOHK_Charles

https://x.com/IOHK_Charles/status/2028612859106931174?s=20

https://x.com/bgarlinghouse

https://x.com/bgarlinghouse/status/2028978245719203901?s=20

https://www.congress.gov/bill/119th-congress/house-bill/3633/text

Grok analyzed the video in this post: https://x.com/IOHK_Charles/status/2028612859106931174?s=20

XRP: Yield

Hodor — Thu, 05 Mar 2026 12:22:23 GMT

100 billion XRP.

One of the biggest selling points of the XRP Ledger is that it has a fixed supply.

That number will never go up as long as it's considered an invariant of the XRP Ledger. For many holders, that scarcity is part of the value proposition, and it shapes some important questions about how XRP can grow in value over time - including whether it can generate yield the way a savings account or bond might.

The Implication

Here is the thing about a fixed-supply asset: the protocol itself has no mechanism to reward you simply for holding it.

Xahau, the network that is, essentially, the "XRP Ledger with account-based smart contracts", has a concept built into the protocol called rewards — a form of native emission that can distribute newly minted XAH to participants who contribute to the network. That is yield baked directly into the protocol itself.

XRP has no equivalent. The XRP Ledger does not mint new coins. It does not pay validators in XRP. It actually does the opposite - a small amount of XRP is permanently destroyed as a fee in every transaction, making the supply ever-so-slightly deflationary over time.

This means that any yield on XRP cannot originate from the protocol. It has to come from somewhere else entirely - from economic activity, from other people, or from financial mechanisms built on top of XRP.

Sources of Yield

So if the protocol will not generate yield for you, what will? There are a few main mechanisms worth understanding.

Automated Market Makers (AMMs)

The XRP Ledger now has native AMM functionality built in. When you deposit XRP (and a paired asset) into an AMM pool, the pool charges a small fee on every trade it facilitates. Those fees accumulate inside the pool and are distributed proportionally to liquidity providers. In effect, you earn a share of trading activity. More trading volume means more fees, which means more yield.

The yield from an AMM comes directly from traders who use the pool. It is not conjured from nothing - it is a fee paid by people who want to swap assets. This makes AMMs relatively transparent in terms of where the money comes from; it's based on the mathematics of charging a fee for the convenience of asset swaps.

DeFi Protocols and Lending

Beyond AMMs, there is a growing ecosystem of decentralized finance (DeFi) protocols that can put your XRP to work in more complex ways. These typically involve wrapping your XRP into a token on another blockchain (more on this shortly), and then deploying that wrapped asset into strategies such as lending it to borrowers who pay interest, using it as collateral in structured financial products, or participating in liquidity incentive programs run by DeFi protocols.

These strategies can offer higher potential yield than AMMs, but they also involve more moving parts and more risk.

The Risks

None of this is free money.

When you put your XRP into any yield-generating mechanism, you are giving up some degree of direct control over it — and with that comes risk.

With AMMs, the most commonly discussed risk is something called "impermanent loss." If the price ratio between your two deposited assets changes significantly while your funds are in the pool, you can end up with less total value than if you had simply held both assets outright.

Over short time periods, AMMs can, and do, lose money.

With DeFi protocols, the risks multiply. Smart contracts can contain bugs or vulnerabilities that allow funds to be drained. Bridges that wrap XRP onto other chains introduce additional layers of technical and custodial risk. The protocols managing your funds can be exploited, can make poor strategy decisions, or can simply underperform. Yield estimates are not guarantees, and in adverse conditions, DeFi strategies can produce a net loss.

There is also a more fundamental issue: the moment your XRP leaves your wallet and enters a protocol, you are trusting that protocol ... its code, its operators, and its security model ... to keep your funds safe. Self-custody is one of the core principles of crypto. Yield strategies, by their nature, require you to compromise that principle to some degree.

That is not a reason to avoid all yield products. But it is a reason to understand exactly what you are signing up for before you do.

The New Kid: "Flare XRPFi Yield"

With those caveats stated clearly, a new yield product launched in late February 2026 that is worth examining closely. It is called Flare XRPFi Yield, and it is accessible directly from within the Xaman wallet as an xApp - meaning you do not need to navigate to a separate website or manage a second wallet to use it.

The project is a collaboration between three parties: Flare Networks, which built and operates the core infrastructure; XRPL Labs (the team behind Xaman), which provides the wallet interface and signing layer; and Upshift and Clearstar, which manage and curate the underlying vault strategies.

How It Works

The system uses three components working together:

FAssets create a wrapped version of XRP on Flare, called FXRP, that can interact with Flare's smart contracts. This is the bridge layer that allows XRP - a native XRPL asset - to participate in DeFi on another chain.
Flare Smart Accounts abstract away the complexity of managing a second wallet. Rather than requiring users to hold Flare tokens or juggle private keys across chains, users authorize transactions using their existing XRPL credentials inside Xaman. The system uses an intent-based execution architecture: when you deposit, the transaction includes both the payment and an embedded instruction specifying the intended outcome.
Xaman acts as the front end, embedding the entire process inside the wallet. Under the hood, Flare Smart Accounts coordinate the full lifecycle: FXRP minting, vault allocation, yield distribution, and redemption back to the XRPL - all without the user needing to leave Xaman.

To access it: open Xaman, tap xApps, and find Flare XRPFi Yield.

User Experience

It appears that the Xaman user is required to first 'request a deposit' on the Flare network, which requires a small amount of XRP to begin with. Then they can deposit XRP in denominations of 10 XRP or multiples thereof. To me, the process was intuitive, along with the explanatory communications.

It's a smooth user experience at the present time, even though the xApp was just launched.

Where the Yield Comes From

Once you deposit, your assets are converted to FXRP and deployed into Upshift's vault strategies, with yield distributed back in FXRP. The strategies themselves draw on familiar DeFi mechanisms: lending markets (where your FXRP - or a stablecoin - is lent to borrowers who pay interest), collateralized positions, and other structured vault strategies curated by Clearstar.

In other words, the yield here comes from the same place DeFi yield always comes from - other market participants paying fees, interest, or incentives in exchange for access to capital.

It is worth noting that Xaman presents the interface and handles signing, but XRPL Labs does not control the underlying protocol or the vault strategies. As always in DeFi, that distinction matters when evaluating your risk exposure.

To Learn More (DYOR)

Research everything yourself, personally, before deciding anything. Here are solid starting points:

Flare Networks official site - documentation on FAssets and Flare Smart Accounts
Xaman documentation - for information on xApps and how Xaman handles signing
Upshift - for details on the vault strategies being deployed
Clearstar - for information on strategy curation and risk management
Clearstar article on 'X'
Community discussions on 'X'

DYOR: "Do Your Own Research", understand what you are committing to, and never deploy more than you can afford to lose.

Scammer Alert!

While the Flare XRPFi Yield xApp is an exciting entry into the larger XRP ecosystem of defi, it will inevitably attract bad actors.

While it's a sad commentary on how ruthless criminals are, along with their ability to use social platforms to target people, if we are all vigilant, it helps others avoid trouble. Be alert for scammers making an attempt to appear connected in some way to the new Flare XRPFi project in an effort to deceive victims. And if you notice it happening to others, please speak up.

To learn more about good security practices managing your XRP (or XAH), you can read more here: Protect Your Assets.

My Take

My attitude toward Flare XRPFi Yield right now is essentially wait and see.

This mirrors the general approach reflected from other crypto commentators as well, including Krippenreiter, who has advocated a measured and patient approach to new yield products rather than rushing in on launch day.

The integration is technically interesting.

The fact that it works directly inside Xaman - without requiring users to manage a second wallet or navigate a separate DeFi interface - genuinely lowers the barrier to entry. That is a significant design achievement. And the team behind it extends across Flare, XRPL Labs, Upshift, and Clearstar.

But credible teams have built products that failed before. Smart contracts that looked solid have been exploited. Yields that looked sustainable have evaporated. The product launched very recently, and there is simply not enough track record yet to know how it performs across different market conditions, whether the yield rates hold up over time, or whether any unexpected issues emerge.

For now, I am watching closely, reading community feedback as it accumulates, and keeping most of my XRP exactly where it is - in my own wallet, under my own control. That may change as the product matures. But I see no rush.

Cautious Optimism

With all of that said, the bigger picture here is genuinely encouraging. The XRP ecosystem is maturing, and products like Flare XRPFi Yield represent a meaningful expansion of what XRP holders can actually do with their assets - beyond simply "hodling."

More options, more infrastructure, and more credible builders working in this space - that is a good thing.

Sources:

https://xrpscan.com/ (XRP burned number)

https://flare.network/products/flare-smart-accounts

https://flare.network/resources/technical-support

https://docs.xaman.dev/

https://x.com/upshift_fi

https://x.com/ClearstarLabs

https://x.com/ClearstarLabs/status/2028009736914788362?s=20

https://x.com/krippenreiter/status/1843790603186008416?s=20

https://x.com/FlareNetworks/status/2029200306618122290?s=20

DM over 'X' with Satish_nl

Protect Your Assets

Hodor — Sat, 28 Feb 2026 20:40:59 GMT

It's a familiar story.

You get into crypto with small amounts. Maybe your journey starts at a centralized exchange - Binance, Bitstamp, Coinbase - somewhere with a clean interface, customer support, and the comforting illusion of a safety net. At that stage, security is largely handled for you. Your job is simple: keep your login credentials private, enable two-factor authentication, and don't click on suspicious emails.

That's about it.

But for many in the XRP community, the bull market of 2025 changed everything almost overnight. What had been a modest, manageable balance on an exchange quietly transformed into something much more ... life-changing money, sitting in an account you don't fully control, on a platform you may not fully trust.

That's when people start asking questions they probably should have been asking all along.

Life-Changing Amounts

"It's a good problem to have."

That phrase gets used a lot when the numbers in your exchange account start looking less like a speculative bet and more like a down payment on a house, a college fund, or a retirement nest egg. And it is a good problem ... but it's still a problem.

Once your holdings cross a threshold that genuinely matters to your financial life, the calculus around security changes completely. Suddenly, questions you could afford to put off become urgent:

Where do I put the crypto? Leaving large amounts on a centralized exchange is a risk. Exchanges have been hacked, frozen, or gone insolvent, sometimes without warning.
What wallet do I use? Hardware wallet? Software wallet? A combination of both?
Do I use a mix of cold and hot wallets? A hot wallet (connected to the Internet) offers convenience; a cold wallet (offline) offers stronger security.
How do I keep my keys secure? Your seed phrase is everything.
How do I protect myself against scammers and fraudsters? The crypto space attracts sophisticated bad actors.

These are problems that require real, thoughtful, personalized answers.

Reality Versus Ideal

Most of us adopted security practices when our stakes were low.

A mental note here, a screenshot of a seed phrase there, a wallet app on a phone that also has 47 other apps installed. Informal, imperfect, and probably fine — at the time. But when fortunes change fast, the gap between our actual security practices and what we should be doing can become dangerously wide.

This is an uncomfortable realization, because it requires admitting that what we've been doing might not be good enough.

Competing Risks

Security and accessibility are often in direct conflict with each other.

A seed phrase etched onto a fireproof steel plate, stored in a bank safety deposit box, with a backup in a second location ... that is a form of a 'vault' wallet that is much more difficult for criminals to access. It's also a logistical challenge every time you need to access it. Meanwhile, a wallet on your phone is incredibly convenient ... and potentially exposed to malware, device loss, or a compromised app.

Every individual has to navigate this tradeoff for themselves, weighing factors like:

How often do you need to access your holdings?
Do you have a succession plan ... in case of your death or incapacitation?
Do you have a safe deposit box at a bank?
How technically comfortable are you with hardware wallets and multi-signature setups?

There's no universal right answer. The best security setup is one you can actually maintain and execute correctly - not necessarily the most theoretically secure one.

Scammers Are Evil

Most people are good.

So at their core, they do not want to consider that there exist people who can act with extremely malicious intentions, and that wish to steal any amount of money ... even from strangers or from those that can least afford it.

These modern crypto scammers are sophisticated, patient, and psychologically astute. They understand human nature, and they exploit it.

Scammer Tactics

The most common tactics all share a common thread: they're designed to override your rational thinking with an emotional response.

Urgency: "Act now or lose this opportunity forever." Scammers manufacture time pressure because they know that rushed decisions are poor decisions.

If someone is pushing you to act right now without time to verify, that's a red flag.

Authority: Fake customer support accounts, impersonators of well-known figures in the XRP community, spoofed emails from exchanges. Scammers impersonate trusted entities to borrow their credibility.

Greed: "Send 1 XRP, receive 2 XRP back." Offers that seem too good to be true always are.

Fear: "Your account has been compromised. Verify your seed phrase immediately." Fear short-circuits careful thinking just as effectively as greed does, and it's used just as often.

Romance and Trust: Long-con schemes where fraudsters build genuine-seeming relationships over weeks or months before introducing a "can't-miss" investment opportunity. These are devastating — financially and personally.

The defense against all of these is the same: slow down, verify independently, and never share your seed phrase with anyone for any reason.

Ever. 😐

Ego Is Your Enemy

"I already know this stuff."

It's the most common reaction among experienced crypto holders when someone suggests they could benefit from a security course or educational resource. And sometimes it's even true — partly.

But "partly" is the problem.

Crypto security is not a static field. The threat landscape evolves constantly. New attack vectors emerge. New tools - including AI-powered tools used by both defenders and attackers - change what's possible. What was best practice two years ago may be inadequate or even counterproductive today.

Genuine security isn't just knowledge ... it's applied, examined, and regularly tested knowledge.

"But Security Education Costs Money"

Yes. It does. And that's often enough to stop people from pursuing it.

But consider the math: a comprehensive security course might cost $50, $100, or $200. For someone holding a meaningful amount of XRP, that represents a fraction of a fraction of a percent of their holdings. The cost of not having that knowledge ... a compromised seed phrase, a successful phishing attack, a poorly executed wallet migration ... could be catastrophic and irreversible.

Unlike most financial losses, a stolen crypto wallet offers no recourse. There's no fraud department to call, no chargebacks, no regulatory protection. When it's gone, it's gone.

Investing in education isn't an expense. For anyone holding life-changing amounts of crypto, it's a critical asset.

Security Education for XRP and XAH Holders

One of the practical advantages for XRP holders is that XAH (the native token of the Xahau network) operates on a nearly identical underlying protocol. The same security principles, wallet structures, key management practices, and threat models apply to both. If you learn to secure one properly, you've essentially learned to secure both.

Xahau has one additional threat vector that is important, however; the installation of smart contracts.

Install the wrong smart contract on your account, and it could result in a loss of funds. The topic of reviewing Xahau (XAH) smart contract hooks and their underlying programs is a topic which I've covered previously here: XAH Hooks: Smart Contract Transparency

The remainder of the topics that impact security on both networks is nearly identical, however.

Whatever your source of education - articles, forums, courses, or community resources - the underlying goal is the same: translating general security principles into a customized approach that fits your specific situation.

An Introduction to "Practical Crypto Security"

One resource worth serious consideration is the course offered at krisdangerfield.com, titled Practical Crypto Security. The course is focused specifically on XRP holders and covers the full spectrum of wallet management and security practices.

I've taken it personally.

At roughly 14 hours of content, it's genuinely comprehensive — and my experience with it broke down into three meaningful categories:

Refresher on practices I already knew. Some content covered ground I was familiar with. It was reassuring to have my existing practices validated, and occasionally I caught a nuance I'd previously missed.

Updated my knowledge with contemporary approaches. The course addresses how modern tools - including AI - factor into the current threat landscape. This was new territory for me, and valuable.

Challenged me to actively evaluate my own setup. This was, perhaps, the most important outcome. It's one thing to understand security principles; it's another to hold them up against your actual, current practices and assess where the gaps are. The course prompted exactly that kind of honest audit.

It was definitely worth the small investment of time and money. (The site accepts XRP as payment)

Discounted Price

Kris Dangerfield has offered a discounted price for his "Practical Crypto Security" class for readers of my blog. 🙂

Use this link to apply the discount at the start of your own registration for the course: krisdangerfield.com/hodor

Keep Yourself Sharp

If you're holding a material amount of XRP or XAH - an amount that would matter to your life - then security education isn't optional; It's part of the responsibility that comes with self-custody.

The source of that education matters less than the act of pursuing it. Community resources, open-source documentation, and reputable courses all have value. If you want the most comprehensive, structured starting point specifically designed for XRP holders, the "Practical Crypto Security" course at krisdangerfield.com is a great step to take. If the cost isn't feasible right now, bookmark it and keep it on your list. And in the meantime, start examining your current practices with as critical an eye as you can.

What you should not do is nothing. X | X>

Sources:

"Practical Crypto Security" via https://krisdangerfield.com/hodor

Q & A with Kris Dangerfield

https://www.kaspersky.com/resource-center/preemptive-safety/guide-to-cryptocurrency-safety

https://xrpl.org/docs/introduction/crypto-wallets

https://xrpl.org/docs/concepts/transactions/secure-signing

https://learn.xrpl.org/lesson/security-best-practices-for-xrp/

xMerch: Building Commerce On Xahau And Evernode

Hodor — Sun, 08 Feb 2026 22:04:32 GMT

In our modern world, where traditional payment processors charge merchants upward of 3% per transaction, a new generation of builders is creating infrastructure that allows businesses to accept cryptocurrency payments with minimal friction.

At the vanguard of this movement is xMerch, a commerce platform built on the Xahau network.

Where It Began

xMerch's origin story began with the "Build on Xahau" Contest in January of 2025.

Behind xMerch is Meister, a web developer & entrepreneur who's been building web apps since 2008.

The contest challenged developers to build applications on Xahau, a network that is, in essence, the XRP Ledger code ... but with account-based smart contracts known as 'hooks'.

Personal Transformation

Meister's entry into blockchain originated, as it did for many of us, with a missed opportunity.

In 2016, a client offered to pay him in Bitcoin for an 18-month project. At the time, he was using PayPal and politely declined, asking for traditional payment instead. That decision cost him what would have become 253 Bitcoin! 😲 One of many painful stories in crypto, this is a dramatic reminder of the industry's potential to reward early developers and adopters.

When Xahau launched, Meister saw an opportunity to build commerce infrastructure the right way. He began developing xMerch in the same month the network went live.

The Build on Xahau contest provided a vehicle to build out his mental proof-of-concept. His submission demonstrated an on-chain payment processor that would allow merchants to accept XAH (Xahau's native token) for real products.

xMerch Buildout

What started as a contest entry evolved into a full-scale platform. Meister's vision was clear from the beginning: create ...

"stupid-simple e-commerce tools for the ledger era."

But simple for users meant building sophisticated infrastructure behind the scenes.

The core of xMerch is a payment processor built on Xahau that enables vendors to accept cryptocurrency payments - specifically XAH - with prices denominated in USD. This ability removes a major barrier for both merchants and crypto-rich customers.

Early in xMerch's development, a pivotal moment happened when Andy, a Hooks contributor, reached out, wanting to sell his products on the platform.

At that time, xMerch was designed as a single storefront.

This request sparked the next evolution: transforming xMerch into multi-vendor commerce infrastructure. Meister handled the full-stack logic to make multi-vendor checkout work end-to-end, while Andy played a key role in coding the smart contracts that underpin the integration with Xahau.

The architecture is intentionally built to serve two distinct audiences.

For developers and technical teams, xMerch provides a CLI (command-line interface) that allows programmatic deployment of XRPL/Xahau-based storefronts, integrations, and on-chain workflows. For business users and entrepreneurs, the xMerch platform abstracts this complexity through dashboards and storefront tools that enable on-chain payments, settlement management, and reward programs - all without requiring merchants to understand wallets, IOUs, or ledger mechanics.

The Site

At xmerch.app, the platform currently operates as a live demonstration of on-chain commerce.

Visitors can browse a selection of products and purchase them, with prices clearly displayed in USD. The marketplace is currently invite-only as Meister and his team test hooks functionality and refine deployment templates. This gated approach reflects the team's commitment to reliability over rapid expansion.

xMerch's new CLI tool makes deploying an on-chain storefront straightforward for technical users, and notably integrates Evernode - a decentralized hosting network & secondary smart contract platform built on Xahau - allowing for seamless deployment of commerce applications.

Helping The Competition

In a counterintuitive move that speaks to xMerch's broader mission, the platform actively helps other vendors onboard to Xahau. Rather than creating a walled garden, xMerch is building the infrastructure layer that other commerce projects can use.

This approach reflects a fundamental understanding of blockchain networks: the value grows as the ecosystem grows.

Meister is currently in early conversations with investors, ecosystem supporters, and real-world businesses looking to deploy directly on XRPL, Xahau, and Evernode using xMerch tooling.

Rather than waiting for funding to ship features, the team continues building and releasing.

Token Creator ... And AMM!

In a significant expansion of the platform's capabilities, xMerch recently launched dex.xmerch.app, a suite of decentralized exchange tools that serves both as a standalone utility and as an integrated feature for xMerch vendors.

The DEX tools enable users to:

Create new tokens (IOUs) on Xahau with minimal technical knowledge
Execute DEX swaps directly on the Xahau network
Bootstrap initial liquidity through automated market maker functionality

For developers and entrepreneurs, this represents a complete toolkit for launching a tokenized project on Xahau.

The high-level workflow Meister envisions:

Spin up a dApp using the xMerch CLI
Create an IOU (token) on xMerch DEX
Create a market pairing (IOU/XAH) on xMerch DEX
Launch the dApp accepting the IOU on Evernode

For xMerch vendors, these tools offer powerful options for creating loyalty programs, reward tokens, or settlement assets tied directly to real commerce activity.

Concrete Example

A merchant could, for instance, issue store credit as an IOU, create liquidity for that IOU against XAH, and allow customers to trade or redeem those credits - all without leaving the xMerch ecosystem.

The DEX functionality is accessible through the CLI for developers and through guided, UI-driven actions for less technical merchants. This dual-interface approach ensures both audiences can leverage the same powerful infrastructure.

AMMs On Xahau: The Missing Link

The AMM (Automated Market Maker) functionality xMerch introduced addresses a critical gap in the Xahau ecosystem. Unlike its predecessor, the XRP Ledger, Xahau does not have any (native) AMM function in its protocol code.

For now, xMerch is using its own proprietary application-layer AMM logic; but Meister indicated he's ready and willing to share whatever is necessary when the larger Xahau community begins discussions about a protocol-level AMM function, or even a smart-contract-based version of an AMM.

The initial version of xMerch's AMM implementation enables token creators to bootstrap their own liquidity pools. Developers can now launch tokens knowing they have the tools to create immediate liquidity and trade-ability.

In regards to the first version of xMerch's AMM approach, Meister cautioned that people should fully understand that it remains a tentative approach; he indicated that one of the more likely scenarios for AMMs is that Xahau eventually implements its own version of the XRP Ledger AMM code.

Regardless of the future path for the network, however, xMerch is moving forward with its current approach at vendor support. In addition, he indicated that xMerch is ...

"... planning and testing the use of hooks for Xahau CBA claims automation, with a longer-term vision that includes IOUs as well."

With this additional point, he's hinting about hook-based, automatic trades and even, potentially, forms of yield on issued assets (IOUs).

How Evernode Is Used

Completing the circle for those applications that truly wish to build on decentralized infrastructure, xMerch deploys the new dApps on Evernode, and even operates its own infrastructure on that network.

For those that understand how Evernode works, this is a remarkable integration, because it leverages truly decentralized infrastructure, making the applications hosted there much more resistant to outside forces. Without a Web 2.0 element, any new dApp can be deployed with a greater degree of independence and resistance to censorship ... or other forces originating from bad actors.

xMerch's Vision For The Future

While the immediate roadmap focuses on expanding vendor onboarding, refining hooks integration, and rolling out v2 of the DEX and AMM tools, the broader vision for xMerch is ambitious: becoming the default commerce infrastructure layer for businesses building on XRPL, Xahau, and Evernode.

The xMerch ticker (XMERCH) is already live on Xahau.

"Our ticker, XMERCH, is live and actively supports continued research and development of our core infrastructure, including tokenization, market-making, and the next wave of deployable DAO and DEX templates."

The integration with Evernode as deployment infrastructure hints at a longer-term vision where commerce applications are truly decentralized, running on distributed hosting rather than centralized cloud servers. This aligns with blockchain's fundamental promise: removing single points of failure and intermediaries.

"From day one, our core philosophy has been simple: give builders and businesses the tools to spin up on-chain commerce on XRPL/Xahau with as little friction as possible. The Build on Xahau submission helped turn that philosophy into a working foundation."

If xMerch can continue executing on its vision of "stupid-simple" commerce tools, it may help usher in the next phase of blockchain adoption.

Sources:

https://x.com/xMerch_

'X' DM Q&A with Meister: https://x.com/xrpl_mworks

https://xpert.page/meister

https://xpert.page/p/xmerch

https://x.com/xrpl_mworks/status/2015158220273455166?s=20

https://x.com/MWorks_proj

https://www.xmerch.app/

https://dex.xmerch.app/

https://www.evernode.org/

https://dex.xmerch.app/docs/faqs

https://github.com/XRPL-Labs/Xahau-Dev-Contest/pull/14