xpert.page - Latest Articles

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

Xpert Swap: xApp Inside Xaman

xpert.page — Sat, 31 Jan 2026 14:58:45 GMT

The XRP Ledger ecosystem is growing fast and so is xpert.page.
To support upcoming features on xpert.page (especially those involving RLUSD), we built something we've wanted for a long time:

🔄 Xpert Swap

A fast, clean, transparent and user-friendly swap xApp designed to give you the best possible on-ledger exchange outcome.

Are you an Issuer?

Scroll down to see how "Xpert Swap" can help ease the user flow for TrustLine setup and Swapping.

🎁 Integration with Xahau Voucher Hook

Its still in the "idea" phase. If implemented: The XAH reward will be from the community to random users of our Swap xApp. So it'll be something XRPL ↔ xPOP ↔ Xahau

Important:
XAH rewards(if and when implemented) are not meant to encourage trading/swapping. They simply thank you for using our xApp when you already have a real need to swap. These rewards/vouchers come from the community.

For the community, by the community.

💱 Best Exchange Rate on the Ledger

While swapping, users should focus on three things:

Send Max: This is the amount of source currency you are exchanging.
Deliver Minimum Amount:
- This is the guaranteed minimum you will receive if the swap succeeds.
- If the ledger can't meet this minimum, the transaction fails (no loss).
amount: This is interesting, and you should ignore it! This is the upper limit or the max you are willing to receive. On the "Xpert Swap" xApp you'll get this rate directly from the ledger. But while executing your swap, if additional liquidity becomes available (which gives you better rates), then our xApp uses it to your advantage and makes sure to take it into account and give you the best outcome, while the "Deliver minimum amount" still protects the downside.
- This is not what you'll receive as a result of swap.
- It is simply the upper limit of how much destination currency the swap could bring.
- If set too low, you might lose the opportunity to receive some extra tokens.

🔧 Issuers: Directly Link Users to Your Token

If you're an issuer, you can send users directly to a pre-configured swap for your token.

Example (RLUSD):
https://xaman.app/detect/xapp:xpert.swap?issuer=rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De&currency=524C555344000000000000000000000000000000

General Code:
https://xaman.app/detect/xapp:xpert.swap?issuer=${issuer_address}&currency=${currency_code}

How to use this:

Replace the issuer address with yours.
For 3-letter currencies, use the plain text code.
For longer codes, include the hex-encoded currency code (as shown above for RLUSD).

What the user sees:

If they already have your TrustLine, they'll immediately see the swap interface, with your token in the destination currency field.
If not, they'll be prompted to set up the TrustLine first.

🤝 Support Us

Set our Swap xApp as your default swap provider on Xaman.

Open XamanApp -> Click on Swap button -> Settings (top right corner) -> Choose xpert.page
2. We would appreciate if you can signup to xpert.page

Your support helps us ship more xApps, more RLUSD utilities, more issuer tools, and more community-driven rewards.

Together, we can grow this ecosystem.

Evergram

Hodor — Fri, 16 Jan 2026 12:14:10 GMT

They're part of our life now.

Chat applications have become a ubiquitous feature on every Android and iPhone device; if it's not the native functionality of the device, then the app is a popular choice in the device 'store'.

Sending a text to family or friends in your close circle has eclipsed ordinary conversation as a de facto mode of communication, and it is now more uncommon to receive a telephone call!

Privacy

While the native text capabilities of the iPhone are encrypted, as is Android (now default), this encryption is only as good as the lock on the device.

To offer an increased layer of security, messaging applications popped up to offer more protection, along with additional capabilities, including making VOIP phone calls. These apps offer and proclaim their commitment to privacy, and offer an enhanced level of protection beyond just the access to the device.

Governments in the Western world have resisted these new applications, because they tend to obstruct their near-total surveillance of the public at an individual level. While they may say that they value citizens' privacy, in practice, they have been almost universally resistant to the use of encryption without an intentional 'back door'.

However, the public has pushed back on these governmental initiatives, and In Europe, the latest request for client-side scanning of messages before encryption, has failed.

Web 2.0 Versus Web 3.0

While these apps may offer enhanced protection from prying eyes, no matter if they're criminals or the government, all 'web 2.0' platforms are vulnerable to social and legal pressure.

For example, if an application refuses to censor users, they may see their app dropped from the 'store' as a standard install choice.

Usually being dropped from the 'store' - whether Android or iPhone - means doom for most small applications; if a user must go to the trouble of a one-off manual install, most will balk at this requirement, even if they support the application author. The largest messaging apps - by user base - depend heavily on this ease of installation.

However, 'Web 3.0' developers assume that they might encounter trouble with these larger forces from the start. So, in essence, their entire mission is to create an application which is impervious - or highly resistant - to outside forces.

And they use blockchain technology and autonomous code to do it.

Evergram

Enter Evergram.

Developed by Andrei Rosseti, it is considered a full-fledged 'Web 3.0' messaging application.

It's infrastructure?

Not traditional servers housed at a Silicon Valley behemoth. Instead, he chose to pay for infrastructure in Evers (EVR), housing his new app on decentralized servers.

Andrei was quick to point out that 'Web 3.0' does not mean 'trustless' .... a mistake that many sometimes make when comparing it to traditional Internet technology. He noted:

"(The) device is a part of trust. (The) wallet is part of trust. (The) blockchain is part of trust. (The) websocket server acting as a gateway is part of trust. Hotpocket is part of trust."

His down-to-Earth understanding of Web 3.0 comes from developing other blockchain applications and code. In the case of Evergram, he fully acknowledges these trust points, even while still aiming for an invulnerable application.

Xahau Hooks

Xahau is, grossly oversimplified, the XRP Ledger code base; streamlined, to allow for account-specific programs called 'hooks'.

Each program on the Xahau network is triggered by a transaction of some kind, or by the passage of time. Hooks can be in various programming languages, but the most common on Xahau are those constructed in 'C', which allow for the most efficient (and therefore cheap) processing.

How Evergram Uses Hooks

These C hooks allow a wide range of programmability, and Andrei uses them for tracking payments for the Evergram 'Pro' membership, and for registering a new account (wallet) as a unique user.

How Evergram Protects Privacy

When I specifically asked Andrei 'how does Evergram protect privacy?', he immediately went low-level, and methodically described the steps his app takes while processing messages:

" Privacy is enforced by design, not by policy:

No plaintext ever leaves the client

No centralized message storage

Keys never leave the user’s control

Per-device encryption, with automatic key rotation when a new device joins

Device cleanup: inactive devices are automatically invalidated after a defined period

User identity is based on cryptographic addresses, not emails or phone numbers

Evergram does not rely on trust — it relies on cryptography."

It's a compelling description of Evergram's privacy-protecting architectural details.

Evergram's Use Of Encryption

Andrei described the specific elements of Evergram where encryption is used:

"Yes — end-to-end encryption by default. Each chat has a unique symmetric key (AES-grade entropy). Message content is encrypted client-side, before leaving the device. Symmetric chat keys are:

Encrypted per participant

Encrypted per device

Delivered using public-key cryptography

Neither Evergram nor the underlying infrastructure can decrypt messages."

How To Use Evergram

The app can be launched from two locations; either through the Xaman wallet as an xApp, or on its stand-alone website. It's really simple; just log in using Xaman, and then voila, the client is started:

Other participant(s) in their chat must also be successfully authenticated.

Another Project Leveraging Encryption

After constructing Xahau DocProof and Origo, two apps that utilize blockchain immutability to store proofs of signatures for external documents, another successful project by Andrei, so soon, was a surprise to me.

Noting how quickly Evergram was created on the heels of those two impressive additions to the Xahau ecosystem, Andrei told me that, although it seems sudden, he's actually been working on this idea for months, and credits conversations with Wietse Wind for propelling him toward finishing the first version of Evergram.

Go-Live Timing

Although a lot of anticipation is building for Evergram, Andrei prefers to keep the roll-out informal for now, and will begin in phases; most likely starting in February with the earliest first-adopter testers and users.

If you wish to be one of these early adopters or testers, he recommends that you follow the official 'X' account to keep up-to-date on the latest information: Evergram on 'X'

Exceeding Expectations

Xahau fans would have been overjoyed with a 'messaging app' built using Xahau.

But Andrei delivered something even more impressive; a messaging app that is an authentic 'Web 3.0', censorship-resistant app that can enable encrypted text communications between parties.

And he used two networks!

Both Evernode and Xahau were integrated, and both of those networks' tokens are used at different points; either by Andrei to procure infrastructure on Evernode (EVR), or to accept payment for the pro Evergram membership (XAH). His new project serves as an impressive addition to the messaging app market, and also, more importantly, as an example for how distributed-ledger technology can offer privacy and censorship resistance for ordinary people.

Welcome to Web 3.0.

Sources

https://www.eff.org/deeplinks/2025/12/after-years-controversy-eus-chat-control-nears-its-final-hurdle-what-know?referrer=grok.com

https://datareportal.com/

https://datareportal.com/global-digital-overview

https://docs.evernode.org/en/latest/platform/hotpocket/index.html

DM with Andrei Rosseti via X and Evergram

README.md file for Evergram client

Xahau: Perfect Fit For Loyalty

Hodor — Fri, 09 Jan 2026 15:31:33 GMT

💫 Loyalty points have become a quiet, but powerful, layer of modern commerce.

Customer Loyalty

From airline miles and hotel rewards to coffee stamps and retail discounts, these systems are designed to encourage repeat engagement while collecting valuable data about customer behavior.

Personal note: Without even trying, I'm currently signed up with at least five or six of these ... two home improvement chains, two hotel chains, one grocery store, and one coffee chain! 🛒

Despite their ubiquity, most loyalty programs remain fragmented, opaque, and inflexible. Points are often locked into a single vendor’s ecosystem, difficult to transfer, and governed by back-end logic that customers can't see or verify.

As digital commerce matures, these shortcomings reveal the need for something different.

How Loyalty Points Work

From a corporate perspective, loyalty programs balance several competing requirements.

They need to be:

Reliable and secure
Capable of handling large transaction volumes at low cost
Flexible enough to adapt to changing marketing strategies

Businesses also want fine-grained control: rules around issuance, expiration, redemption, fraud prevention, and tiered rewards must all be enforceable automatically. At the same time, companies increasingly want interoperability — the ability to partner with other brands or platforms — without losing control of their program or exposing themselves to excessive technical risk.

Where Traditional Systems Fall Short

Traditional loyalty infrastructure usually relies on centralized databases and extensive back-end code.

This makes it costly to maintain, and difficult to audit, both internally and externally. Customers must trust that points are issued fairly, balances are accurate, and rules are applied consistently. For developers, extending or integrating these systems often means writing custom code, negotiating APIs, and maintaining long-term infrastructure. These limitations have prompted growing interest in blockchain-based alternatives that can provide transparency, programmability, and portability.

The First 'Crypto' Experiments

If you're in crypto, then you know that a long list of experiments have been conducted using smart contracts to change traditional financial systems ... including loyalty programs.

Some of these projects, such as the Starbucks - Polygon one, involve using NFTs as a reward for customer loyalty. The ideas that worked in these first programs can be re-used by other networks, including Xahau.

Overall, however, some of the pitfalls identified in the early programs include:

Poor User Experience
High Transaction Fees
Rules Still Enforced Off-chain
Limited Interoperability
High Operational Complexity For Merchants
Control Issues: Open Transfers Violate Regulations

If a new 'crypto' system does not offer a better customer experience, then it will eventually fade away as businesses and customers focus on better traditional solutions.

Xahau Hooks

Xahau is a smart-contract–enabled network built around the concept of hooks — lightweight, on-ledger programs that can be attached directly to accounts in a 'one-to-many' relationship with one wallet.

Unlike traditional smart contracts, hooks execute automatically during transaction processing itself (a.k.a. "inline"). This design allows developers to embed logic directly into the flow of payments and asset transfers, enforcing rules at the protocol level rather than bolting them on afterward.

Why Hooks Matter

Hooks are intentionally constrained, deterministic, and efficient. They are designed to be safe to run on every transaction without introducing unpredictability or excessive resource usage. For developers, this means business logic that is easier to comprehend, cheaper to execute, and more resistant to external pressures.

In the context of loyalty points, these characteristics are especially important, because reward systems often involve high-frequency, low-value transactions that must remain fast and inexpensive.

Hooks & Loyalty Points

At their core, hooks can automate the issuance and management of loyalty points in a transparent and tamper-resistant way. A hook can mint points automatically when a qualifying transaction occurs, enforce earning limits, or apply tier-based multipliers based on customer status.

The rules of the program become part of the network’s execution itself, rather than hidden behind a corporate "black box" server.

Loyalty Rules

Hooks make it possible to encode complex rules directly into loyalty programs.

Expiration dates, burn mechanics, clawbacks for refunds, or anti-abuse protections can all be enforced automatically. For example, a hook could prevent points from being transferred outside an approved set of partner accounts, or apply different redemption rates depending on time, location, or customer behavior. This allows companies to retain control over their programs while still benefiting from blockchain transparency.

What Hooks Can Do For Loyalty

One of the most compelling opportunities lies in cross-brand loyalty ecosystems. With Hooks, multiple businesses can agree on shared rules for earning and redeeming points without relying on a single central operator.

Points issued by one brand could be recognized by another under clearly defined conditions, all enforced on-ledger. Imagine getting the same type of points while on a vacation, no matter if you earned them flying or staying at a hotel!

This opens the door to coalition loyalty programs that are easier to audit, faster to settle, and more resilient than traditional models.

Other Related Ideas

Beyond classic loyalty points, the same hook-based patterns can support coupons, prepaid credits, access tokens, and reputation systems.

Developers can experiment with dynamic rewards that respond to on-chain activity, seasonal promotions that are enforced automatically, or customer engagement incentives for both the digital and physical world.

Because hooks exist at the transaction layer, these ideas can be implemented with minimal "layer 2" code.

Early Adopter: Xspence

Xspence is the company that @Handy_4ndy founded, specifically to innovate in the integration of blockchain and Web 2.0/Web 3.0 technology.

In reference to his projects that utilize distributed ledger technology, he noted:

"Xahau's programmability allows us to create all types of use cases; in all honestly I'm struggling to find something we can't accomplish here."

Pioneering new Xahau hooks, Xaman integrations, various IoT experiments, retail services, and gaming, he has also been a first mover at using Xahau to integrate with crypto rewards.

"Now On Xahau"

Loyalty programs sit at the intersection of technology, trust, and customer engagement.

Xahau’s hook architecture offers a particularly strong foundation for rethinking how these systems are built and operated. By moving major parts of the logic on-chain, hooks provide transparency, independence, and flexibility that traditional 'Web 2.0' loyalty systems - and most other ledger networks - cannot match.

For developers and businesses looking to modernize loyalty points without sacrificing control or efficiency, Xahau represents a natural and powerful fit.

Sources:

https://www.delta.com/us/en/skymiles/how-to-earn-miles/airline-partners

https://xspence.co.uk/xrmine

https://xspence.co.uk/

https://x.com/zerpenator/status/2001338074631147877?s=20

https://developers.stellar.org/docs/tokens

https://www.deloitte.com/us/en/Industries/financial-services/articles/making-blockchain-real-customer-loyalty-rewards-programs.html

https://www.forbes.com/sites/garydrenik/2025/06/24/loyalty-programs-are-broken---blockchain-is-the-solution/

https://nftplazas.com/starbucks-loyalty-program/

Xahau: By The Numbers

Hodor — Sun, 28 Dec 2025 14:35:50 GMT

As Xahau approaches the close of the second (calendar) year of operations, the network metrics paint a picture of how the ecosystem has been used by its early adopters and champions.

From transaction volume and hook execution to decentralized exchange activity and account growth, the data, through approximately December 20, 2025, offers a grounded, quantitative snapshot of behavior.

What follows is a summarized walkthrough of Xahau’s year — told primarily through numbers.

For those that wish to read this content in its original form from @Silkjaer, refer here: Original Post on X.

High Level View

Over the last year, Xahau closed approximately 8 million ledgers and processed 615 million total transactions, with 608 million of those successfully validated. One of the most notable metrics is hook usage: 251 million hooks were executed, meaning that over 40% of all successful transactions triggered ("invoked") a hook.

This highlights that hooks are not a niche feature on Xahau, but a core part of how the network is used.

Transaction Breakdown

Looking more closely at transaction types, payments dominate the network with roughly 275 million transactions. Beyond simple transfers, Xahau shows heavy usage of programmable and token-related operations, with 52–62 million transactions each across categories such as:

URITokenMint
URITokenBuy
URITokenBurn
CreateSellOffer
Invoke
AccountSet

In contrast, governance participation via rewards remains comparatively limited: only 53,119 ClaimReward transactions were recorded across roughly 196,000 accounts. Over the year, 23.9 million XAH was minted, while 2.8 million XAH was burned, providing a view into net supply changes.

XAH Transfers

In terms of native token value, 238 million XAH changed hands across 268 million payment transactions, indicating that most transfers were relatively small in size rather than large, infrequent movements.

Escrow usage exists but remains modest by comparison, with 140 escrow releases accounting for 12.9 million XAH. While escrow functionality is present and used, the dominant pattern on Xahau is still direct, immediate settlement.

Account Creation

Network growth is reflected in account creation, with approximately 89,900 new accounts created over the year. A snapshot a few days later confirms this approximate number:

This steady pace aligns with Xahau’s focus on infrastructure, programmability, and utility-driven adoption rather than speculation alone.

Xahau’s Decentralized Exchange (DEX)

Xahau's parent chain, the XRP Ledger, boasts a DEX that has grown up from its roots in 2012 to a high-volume marketplace in 2025.

In contrast, Xahau is at the beginning stages of its native DEX journey. DEX activity on Xahau shows a clear concentration around a few core trading pairs:

The most active pair by far is XAH/EVR, followed by XAH/MAG, XAH/XRP, XAH/CLV, and XAH/USD. This pairing distribution reinforces the close relationship between Xahau and Evernode-related assets, while also showing early but meaningful cross-ecosystem trading interest.

Popular Hooks

Hook execution statistics exemplify the Evernode project’s central role in on-chain activity.

The most executed hooks were:

EVR Registry Hook (102.4M executions)
EVR Heartbeat Hook (53.2M)
EVR Reputation Hook (51.7M)

Together, these account for the vast majority of hook executions. Additional hooks include EVR Redirect (14.5M) and two versions of the EVR RW Forwarder, with 1.6M and 164K executions respectively.

The Xahau Governance Reward Hook saw just 52K executions, again highlighting that governance interactions remain a small slice of overall activity.

Other 'retail' hooks have been developed as well, and as the network moves forward with an increasing number of accounts, it may show that these smart contracts will rise in popularity.

Ringing In The New Year

Xahau’s second calendar year shows a network that is utilized and highly programmable.

Transaction volumes are substantial, hook execution is pervasive, and Evernode-related activity clearly anchors much of the ecosystem. While governance participation and escrow usage remain relatively low, the dominance of hooks and token-related transactions suggests that Xahau is being used, in addition to a payment rail, as a platform for automated, on-ledger logic.

As the network matures, these numbers establish a clear baseline for measuring where growth — and behavioral shifts — emerge next.

Sources:

https://x.com/Silkjaer/status/2002380587835810204?s=20

https://xahauexplorer.com/en/activations

How to Add & Remove XRPL Liquidity with Anodos Wallet

Niles — Tue, 23 Dec 2025 16:04:24 GMT

This guide shows how to add and remove liquidity from XRP Ledger AMM pools using Anodos Wallet.

Liquidity providers deposit assets into a pool so others can trade against it. In return, providers earn a share of trading fees and receive LP tokens that represent their portion of the pool.

Your position can increase or decrease in value depending on trading activity and price movement. This guide focuses on how to use the AMM, not investment strategy.

For more details, see the official XRPL AMM documentation.

Instructions:

Step 1: Log on + Connect Wallet

a. Open the Anodos app on desktop or mobile
b. Sign in to connect your wallet
c. Open the liquidity tab

Step 2: Choose a Pool + Know the Risks

a. Select a liquidity pool (Example: XRP/EVR)
b. Set trustline (if needed)
c. Review risks of impermanent loss and slippage

Step 3: Add Liquidity

Single Side Deposit:
a. Turn on single side deposit
b. Enter an amount
c. Click “Add Liquidity” + sign transaction
d. Receive LP tokens

The single sided deposit will automatically swap ½ of the deposited asset for the other, adding an equal USD value of each asset to the pool.

Two Side Deposit:
a. Turn off the single sided button
b. Enter an amount
c. Click “Add Liquidity” + sign the transaction
d. Receive LP tokens

Step 4: Remove Liquidity

a. Select “Remove Liquidity”
b. Choose a single or two sided withdrawal
c. Enter an amount
d. Sign the transaction

Your LP tokens are redeemed for a proportional share of the pools assets, including fees earned.

What to Know

LP tokens represent your ownership share of the pool
Fees accrue automatically inside the pool
Value changes with market activity and price movement
Withdrawing realizes gains or losses

Helpful Links:

Anodos Finance (start here): https://dex.anodos.finance/liquidity
Anodos Wallet docs: https://docs.anodos.finance/products/anodos-wallet
XRPL AMMs overview (Anodos): https://docs.anodos.finance/education/what-is-an-automated-market-maker
XRPL AMM protocol docs: https://xrpl.org/docs/concepts/tokens/decentralized-exchange/automated-market-makers