Xahau network Review
Xahau network
xahau.network
If your website is on the scam list and you think that you are not a scammer, contact us. After you provide us with all the proof that you are in Crypto World with good intentions, we will delist you. Usually, you get in this category because you are hiding your team, you have a bad reputation(you are tricking, deceiving, scamming people), and you haven't got a written project whitepaper or is a shitty one....
Their Official site text:
The Smart Contract Sidechain for the XRPL Ecosystem
Disclaimer: This crypto-asset white paper has not been approved by any competent authority in
any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the
content of this crypto-asset white paper.
Version 1 - Published 28 August 2023
1. Summary
1.1 The Xahau Ledger (Xahau) is the smart contract sidechain for the XRPL
ecosystem. It is a fork of the XRP Ledger’s (XRPL’s) open-source rippled
codebase that embodies all the useful and innovative features of the XRPL,
including its environmental sustainability, but tweaks and upgrades the
codebase to support smart contracts.
1.2 Xahau’s core features are:
(a) XRPL Core: Xahau retains the key features that have made the XRPL one
of the most enduring and popular networks, including the XRP Ledger
Consensus Protocol (Previously: Ripple Protocol Consensus Algorithm), the
DEX, and the logic of protecting the ledger against spam and bloat by
charging and burning fees in the native token, but it substitutes the recent
XLS-20 NFTs for the cleaner, simpler URITokens.
(b) Hooks for Smart Contracts: The big new feature of Xahau is Hooks, the
smart contract implementation for rippled. Hooks are small pieces of
code installed on an account that impose rules on the transactions the
account sends or receives before those transactions can be finalized.
(c) Native Token & Better Tokenomics: Xahau will be secured by its native
token, Xahau XRP (currency code: XRP+), and powered by better
tokenomics designed to reward validators and support smart contracts.
(d) Burn2Mint Liquidity: As an XRPL sidechain, Xahau will be linked to the XRPL
via a one-way Burn2Mint liquidity portal that allows users to clone their
XRPL account address on Xahau and burn XRP on mainnet in return for a
matching number of Xahau XRP.
(e) Genesis Hook Governance Game: Xahau’s Genesis account is powered
by a Hook that regulates, amongst other things, the emission of new
Xahau XRP and this Hook is governed by a two-tiered governance game
with up to 20 independently owned validators as participants.
1.3 In concert, these features create a new network within the XRPL ecosystem that
implements the Hooks amendment to deliver fast, cheap, secure smart
contracts for the XRPL ecosystem supported by a properly incentivised
community of validators and developers.
1.4 The development of the Xahau Ledger has been driven by the Xahau Launch
Alliance, five experienced and committed entities within the XRPL community
that have carried the cost and risk of establishing the new network without an
ICO.
1.5 Xahau will launch fully functional and decentralised with over 10 independently
owned validators run by a representative mixture of the XRPL ecosystem,
including developers, exchanges, and long-term community members.
2. Xahau – Built from the XRPL’s DNA
2.1 Xahaud - the software that runs Xahau - is a fork of rippled, the open-source
codebase of the XRPL. It retains the key features that have made the XRPL one
of the most popular and enduring networks since it was launched in 2012.
XRP Ledger Consensus Protocol
2.2 Xahau uses the XRP Ledger Consensus Protocol (Previously: Ripple Protocol
Consensus Algorithm) – sometimes called Proof of Association (PoA). It is
designed to overcome the limitations of traditional consensus mechanisms like
Proof of Work (PoW) or Proof of Stake (PoS), particularly the high energy
consumption associated with PoW.
2.3 The XRP Ledger Consensus Protocol (Previously: Ripple Protocol Consensus
Algorithm)Protocol works as follows:
(a) Validator Proposal: Each validator proposes a new set of transactions,
called a "candidate set," which they believe should be included in the
next ledger. This candidate set includes both new transactions and any
transactions that were not previously included in a validated ledger.
(b) Agreement Phase: Validators communicate with each other to exchange
and evaluate candidate sets. They independently verify the validity and
order of transactions proposed by other validators. Through a series of
iterative rounds, validators attempt to converge on a single candidate set
that the majority agrees upon.
(c) Finalization: Once a supermajority of validators (at least 80%) agrees on a
specific candidate set, that set is considered "finalized." Finalized
candidate sets become the basis for the next ledger.
Page | 2
(d) Ledger Closing: The ledger is closed, and a new ledger is created based
on the transactions in the finalized candidate set. This process occurs
roughly every 3-5 seconds in the XRPL, allowing for fast transaction
settlement times.
2.4 Under the XRP Ledger Consensus Protocol (Previously: Ripple Protocol
Consensus Algorithm), each validator specifies a UNL (Unique Node List) being
a list of other validators it trusts. The canonical ledger is found through the
overlap between the UNLs of all the validators.
2.5 To facilitate social consensus on the appropriate UNL, several entities, including
the XRPL Foundation, publish recommended Validator Lists (or VLs) of the
validators they deem suitably trustworthy. Following a generally accepted dUNL
helps ensure you stay on the main ledger and do not unintentionally end up
following an irrelevant fork. Xahau will follow a similar, social-consensus
approach to defining a dUNL, with organisations like the XRPL Foundation
publishing its recommended VL.
2.6 The XRP Ledger Consensus Protocol (Previously: Ripple Protocol Consensus
Algorithm) Protocol provides several advantages, including high scalability, low
energy consumption, and resistance to censorship and network forks. By utilizing
a set of trusted validators and this unique consensus algorithm, Xahau achieves
fast and secure transaction processing while maintaining decentralization and
reliability.
The DEX
2.7 Xahau retains a version of the XRPL’s limit order book decentralized exchange
(DEX) that allows users to trade and exchange assets directly on the ledger. The
DEX leverages Xahau's decentralized and trustless architecture to enable
peer-to-peer asset trading without the need for intermediaries.
2.8 In summary, the decentralized exchange works as follows:
(a) Order Creation: Users can create buy or sell orders on the DEX by
specifying the asset they want to trade, the desired quantity, and the
price they are willing to accept or pay.
(b) Order Matching: The DEX’s order book maintains a record of all open buy
and sell orders. When a new order is placed, the DEX automatically
matches it against existing orders based on price and quantity.
(c) Cross-Currency Trading: The DEX supports cross-currency trading,
enabling users to trade between different assets. To facilitate this, the DEX
uses the ledger’s native currency as a bridge currency, allowing users to
convert one asset to the native currency and then to another asset.
Page | 3
(d) Pathfinding Function: The pathfinding function is a key component of the
DEX. It helps users find the most efficient trading path when converting
one asset to another. For example, if a user wants to trade Asset A for
Asset D, but there is no direct market available, the pathfinding function
will search for the best sequence of trades (e.g., A to B, B to C, and C to
D) to achieve the desired conversion with minimal slippage and fees.
(e) Automatic Order Execution: Once a trade is matched, the DEX
automatically executes the transaction. The ledger's consensus
mechanism ensures that the transaction is validated and added to the
ledger, providing a high level of security and immutability.
(f) Trustless and Decentralized: The DEX operates in a trustless and
decentralized manner. It does not rely on a centralized exchange or
require users to deposit their funds into a third-party wallet. Instead, users
maintain control over their assets throughout the trading process,
reducing counterparty risk.
(g) Low Fees and Fast Settlement: Trading on the DEX incurs minimal fees
compared to traditional centralized exchanges. Xahau's consensus
protocol allows for fast settlement times, enabling near-instantaneous
transaction processing.
2.9 With these features, the DEX provides users with a convenient and secure
platform for peer-to-peer token trading. By leveraging the trustless and
decentralized nature of Xahau, the DEX offers efficient cross-token trading and
seamless order matching while maintaining user control and privacy.
Burned Transaction Fees
2.10 To protect itself against spam and bloat, the XRPL charges transaction fees and
account reserves in its native currency and burns all transaction fees, rather
than redistribute them to validators. Xahau follows this “fees charged and
burned” model to likewise protect itself.
2.11 While this is a proven mechanism for protecting the ledger, it has implications for
Xahau’s Tokenomics, as discussed later. The fees burned by Xahau’s smart
contracts, while still small, will be much higher and more variable than standard
transaction fees on the XRPL.
URIToken NFTs instead of XLS-20 NFTs
2.12 Unlike the XLS-20 NFT standard
1 recently introduced to the XRPL, which relies on
compressing NFTs into on-ledger “pages”, Xahau will use URIToken objects.
1 https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-20
Page | 4
2.13 URITokens (short for Uniform Resource Identifier Token) are an innovative way to
represent and manage NFTs, their metadata and ownership information within
Xahau. Each token is a first-class ledger object with a unique address that does
not change when the current owner does.
2.14 URIToken NFTs have many benefits over the XLS-20 NFT standard, including:
(a) Lightweight and Efficient: URITokens are first-class on-ledger objects that
can be created, destroyed, transferred, bought and sold, and which
interoperate easily with Hooks. Trading is limited to a single sell offer per
token, that can be accepted either by the specified destination account
or, if no destination is specified, then the general public. There is no
brokered mode.
(b) Interoperability and Immutability: URITokens come with a built-in
extensible metadata JSON standard and an optional Digest field (a hash
making the content of the NFT immutable). This provides flexibility for
developers and creators to choose their preferred storage solutions, such
as IPFS or traditional web servers. It also promotes interoperability with
existing NFT standards and platforms, facilitating the integration with the
broader NFT ecosystem.
(c) Improved User Experience: URITokens can be easily located by their
keylet (on ledger address) that does not depend on the current owner of
the token. The NFT metadata and ownership information can be easily
accessed and updated through standard web protocols. Users can
simply click on the URI associated with an NFT to view its details, including
images, descriptions, and provenance. This approach simplifies the user
experience and reduces the complexity of interacting with NFTs on
Xahau.
2.15 Thus, URITokens provide a lightweight, flexible, and cost-efficient solution for NFTs
on Xahau.
3. Hooks – Smart Contracts for the XRPL Ecosystem
3.1 Hooks is a smart contract solution developed specifically for the XRPL
ecosystem. Hooks are small, efficient pieces of code defined on a Xahau
account that execute logic on transactions sent to or received by the account
before those transactions are finalised in the ledger. Hooks are thus a way for
developers to create and deploy smart contracts on Xahau, opening a wide
range of possibilities for decentralized applications (dApps) and automated
transactions.
3.2 Xahau implements the Hooks amendment as a sidechain so the XRPL
ecosystem can benefit from Hooks now rather than later. It also allows the XRPL
community to better evaluate whether and how to implement Hooks on the
XRPL mainnet in the future.
Page | 5
Benefits of Hooks
3.3 Some key benefits of Hooks over other smart contract solutions include:
(a) Simplicity and Efficiency: Hooks are lightweight and efficient compared
to conventional smart contract solutions. The underlying architecture of
Xahau, which focuses on transaction settlement and fast consensus,
ensures quick execution of smart contracts without compromising
performance.
(b) Native Integration: Hooks are a layer-one smart contract solution and thus
live natively inside the ledger, allowing developers to create contracts
that interact directly with on-ledger objects, balances and transactions.
In contrast to layer-two smart contract solutions, this tight integration
simplifies the development process and ensures seamless interoperability
with Xahau's ecosystem.
(c) Low Fees and Scalability: Hooks leverage Xahau's low transaction fees
and high scalability. Like most chains, Xahau can handle a high volume
of transactions per second, making it suitable for applications that require
fast and cost-effective smart contract execution.
(d) Security and Reliability: Hooks inherit the robust security and reliability of
the XRPL. The XRP Ledger Consensus Protocol (Previously: Ripple Protocol
Consensus Algorithm), which powers Xahau, ensures a decentralized
network with consensus among trusted validators. This strong security
foundation provides confidence for developers and users alike.
(e) Ecosystem Compatibility: Hooks are designed to be compatible with
existing XRPL tools and services, making it easier for developers to
integrate smart contracts into their applications. This compatibility
enables seamless interaction with other features of the XRPL, such as
decentralized exchanges and payment channels.
(f) Account Decentralisation: Using Hooks it is possible for a Xahau account
to be fully autonomous and to emit and receive transactions according
to the logic of its Hook, instead of relying on external private key holders
to manually authorise transactions.
Sample Use-Cases
3.4 By introducing smart contract capabilities to the XRPL ecosystem, Hooks offer a
powerful and efficient solution for developers seeking to build decentralized
applications and automate transactions. Examples of the kinds of functions
Hooks can achieve include:
(a) Whitelists: A Hook enabled account can protect accounts against fraud
or sanctioned transactions by being coded to only accept or send
transactions to whitelisted accounts.
Page | 6
(b) Blacklists: A hook enabled account can be coded to refuse to receive or
send transactions to any prohibited (blacklisted) account.
(c) Sophisticated Escrow: A Hook enabled account can hold any asset
received from nominated account and only forward or return those
assets if told to do so by a valid transaction that meets predetermined
criteria.
(d) Automated Registry: A Hook enabled account can act as an automated
registry and mint and redeem URI NFTs as evidence of registration or
registration rights.
(e) Self-Sovereign Treasury: Issued currencies can mimic decentralised,
counterparty-free assets by being deposited into a self-owned Account
with a Hook that emits the currency according to a disclosed and
predetermined emission schedule.
3.5 The combination of simplicity, low fees, scalability, security, and ecosystem
compatibility means Xahau offers early access to an attractive smart contract
solution for the XRPL ecosystem. Xahau’s experience with Hooks will help the
community determine whether and how to implement Hooks on the XRPL in the
future.
4. Xahau XRP – Native Token & Tokenomics
4.1 Xahau is secured by its native token, Xahau XRP. Its salient details are as follows:
Native Token: Xahau XRP
Ticker: XRP+
Smallest Unit: 1 drop or 0.000001 XRP+
Function: Xahau XRP is the currency of the network. It is a utility token to
purchase network services. Like the XRPL, transactions on Xahau incur a
fee or reserve that is charged in Xahau XRP to protect the Ledger against
spam and bloat.
Initial Liquidity: 600 million distributed to launch participants.
Max Supply: Uncapped.
Emission Mechanisms: The supply of Xahau XRP is determined via the
amendments enabled in Xahau’s consensus protocol:
â—Ź Burned XRP: XRP on the XRPL mainnet can be burned and minted
into Xahau XRP, using the Import amendment detailed in section 5
below.
Page | 7
â—Ź Monthly Balance Adjustment: To put back into circulation some of
the XRP+ burned from transaction fees, each active user can
claim an increase in their account balance of ~0.34% of their
average monthly balance (equal to 4% pa. compounding). This
emission is controlled by the Protocol Governance Game which
uses a combination of the Hooks, BalanceRewards and the
XahauGenesis amendments.
â—Ź Monthly Seat Rewards: To put back into circulation some of the
XRP+ burned from the transaction fees, and to incentivise active
and appropriate governance, an amount matching the total
claimed Monthly Balance Adjustments is also rewarded to
Governance Game validators.
Burned XRP
4.2 The principal source of Xahau XRP is from XRP burnt on the XRPL and ported to
Xahau via the Burn2Mint Liquidity Portal (discussed below in Section 5).
4.3 The Xahau protocol, through the Import amendment, will allow an amount of
Xahau XRP equal to the current circulating supply of XRP (approximately 52
billion) to be minted in this way. This Burn2Mint liquidity portal is what makes
Xahau a sidechain of the XRPL and ensures the native token on Xahau is a
meaningful representation of XRP.
Initial Distribution
4.4 The Launch parties have invested significant time and resources to launch
Xahau, thus it would be unreasonable to also require them to use Burn2Mint. An
initial distribution is provided at the protocol level by the XahauGenesis
amendment.
4.5 The protocol will pay a modest 600 million Xahau XRP as follows:
(a) 12 million to each of the eight Governance Game validator Seats on
launch.
(b) 16 million additional to GateHub for DEX stablecoin liquidity
bootstrapping.
(c) 160 additional million to XRPL Labs (Xaman) for Intellectual Property -
Xaman has carried the main technical and financial burden of
developing Hooks and xahaud. This additional distribution is for that effort.
(d) 328 million to the XRPL Foundation, to help ensure the health of the XRPL
Protocol ecosystem moving forward.
Page | 8
Monthly Balance Adjustment
4.6 One challenge Xahau must manage is the additional expense of smart
contracts compared to normal XRPL transactions.
4.7 On the XRPL, transaction fees cost as little as one drop or 0.000001 XRP. Against
a total supply of 100 billion XRP, this is a trivial-but-sufficient cost. Hooks
transactions, on the other hand, can cost orders of magnitude more to set and
to trigger. Further, while every XRPL transaction is standardised, Hooks can vary
enormously in their complexity and cost. To properly protect itself against spam
and bloat from its Hooks, the Ledger must charge appropriately (and
dynamically) for the size and logic complexity of every Hook transaction.
4.8 The consequence is that, as a smart contract chain that burns fees, Xahau XRP
could easily be burned to near-zero, and certainly much more rapidly than
equivalent XRP would be burned on the XRPL, potentially leading to perverse
incentives to horde Xahau rather than use it to deploy and run Hooks.
4.9 To guard against these risks, Xahau needs a protocol-level mechanism that puts
burned tokens back into circulation, but one that does not simply incentivise
high fees. This is the purpose of the monthly balance adjustment.
4.10 The Monthly Balance Adjustment works as follows:
(a) Each month, each Xahau account can choose to claim (against the
protocol) an adjustment based on their average Xahau XRP balance
(computed since the last adjustment). The adjusted amount is the
equivalent of 4% p.a. compounded (roughly 0.34% per month).
(b) Users can claim their balance adjustment by sending a RewardClaim
transaction to the Genesis account at any time provided 30 days has
passed since the last claim. Doing so demonstrates they are an active
user.
(c) Upon receipt of the claim transaction, the protocol, via the
BalanceRewards and XahauGenesis amendments, increases the user’s
account balance by the balance adjustment.
(d) Unclaimed balance adjustments are foregone as a penalty for inactivity.
(e) 4% is the initial rate at launch, but it can be changed via the Governance
Game if it proves too small or too large in the future.
4.11 This mechanism allows active users to claim a monthly adjustment that puts
further Xahau XRP into circulating supply, mitigating the risk of the token being
burned down to zero through smart contract execution fees.
Page | 9
Monthly Governance Validator Rewards
4.12 The Xahau Genesis Account is enabled with a Hook that controls, among other
things, the emission of Xahau XRP. This Hook needs a governance arrangement
so that it can be monitored, amended, and/or replaced in the face of
changing network and real-world conditions.
4.13 It is well known that XRPL mainnet validators do not receive any kind of reward
for the services they provide for underpinning the mainnet Ledger. However,
infrastructure costs money to run, and real-world experience shows that this lack
of incentive leads to a lack of actively managed validators.
4.14 The Xahau Genesis Hook needs to know, or be told, which accounts it must trust
when deciding whether to update itself. So, those accounts must be known in
advance, rather than emerging from the overlapping UNLs.
4.15 The technical solution to this problem is an incentivised Genesis Hook
Governance Game that rewards certain Validators for overseeing the Hook. It
works as follows:
(a) There are 20 “Seats” on the Genesis Hook Governance Game.
(b) Each Seat is controlled either by a single Xahau Account (Level 1) or a
self-managing committee of 3-20 Accounts (Level 2).
(c) For each occupied Seat, the protocol mints and distributes 1/20
th of the
total Monthly Balance Adjustments claimed that month.
(d) If a Seat is held by a committee of Accounts, the rewards for that Seat
are split in a manner of that committee’s choosing.
(e) If no users claim a Balance Adjustment that month no rewards are paid to
any validators.
(f) Each Flag Ledger (256 ledgers) an on-ledger record called a UNLReport is
generated. This report contains a list of validators’ public keys that 80% of
other validators believe participated adequately in consensus since the
previous Flag Ledger. The Genesis Hook will only distribute validator
rewards to Seats that correspond to the public keys of validators on the
UNLReport.
4.16 Thus, the Genesis Hook Governance Game includes a reward mechanism
designed to ensure that trusted accounts are rewarded for running trustworthy
validators, that those rewards are linked to user activity, and that those rewards
put new Xahau XRP into distribution, mitigating the risk of a token liquidity
crunch from high smart contract execution fees.
Page | 10
5. Burn2Mint Liquidity Solution
5.1 While the XRPL ecosystem currently operates on a single chain, the ecosystem
will soon expand to encompass multiple parallel chains, like the Ripple/Peersyst
EVM sidechain and Xahau. These sidechains will offer enhanced scalability,
flexibility, and interoperability, fostering a more diverse and dynamic ecosystem
for XRP and related digital assets.
5.2 As a sidechain, Xahau Ledger must be capable of inter-chain value exchange
with the XRPL. Xahau will enable that value exchange with the XRPL via a
Burn2Mint liquidity portal that allows users to clone their XRP account address
on Xahau and burn XRP on XRPL mainnet in return for a matching number of
Xahau XRP in their cloned account on Xahau. This section explains the
Burn2Mint function and why it was adopted ahead of other mechanisms.
Existing Mechanisms and Their Flaws
5.3 There are several existing mechanisms for cross-chain value transfer, but each
has specific drawbacks as follows:
(a) Centralised Exchanges: Centralised exchanges (CEXs) offer opaque
liquidity on more than one chain. Most users will use a CEX to obtain their
first coins on a new chain, and these are an important but centralised
part of the ecosystem. Reliance on CEXs is a centralising factor in an
ecosystem.
(b) Layer 2 Bridges: Layer 2 bridges are semi-decentralised custodial lending
or wrapping services. Locking up collateral on one chain allows the user
to borrow against it on the second chain. Returning funds on the second
chain unlocks the collateral on the first chain. These services are
honeypots that attract exploits. Further, they have a lack of legal clarity in
many jurisdictions, including clarity on the legal role of the operators on
the bridge and the status of the locked coins.
(c) Atomic Swaps: If two chains support hash time lock contracts, then an
atomic swap could be used to transfer value between the chains. In this
protocol two users wanting to perform opposite trades are match-made.
The protocol ensures that either both trades occur, or both do not. Atomic
swaps have three drawbacks. First, if the counterparty does not perform
their trade the first party must wait for the time-lock expiry. Secondly, a
critical mass of users on both chains must exist so that users wishing to
swap can always find a counterparty wishing to make the opposite trade.
Finally, if the directionality of the trading is generally in one direction it
may not be possible to find counterparties.
5.4 While none of the above mechanisms are precluded by Burn2Mint – that is, all
are a possible feature of Xahau in the future – Burn2Mint is a native cross-chain
value transfer mechanism that is immediately available and avoids all the
identified drawbacks.
Page | 11
Burn2Mint Mechanism - Burning XRP on the XRPL
5.5 Xahau’s Burn2Mint allows a user with an account on the XRPL mainnet to clone
that Account on Xahau (same r-address and same private key/s) and then
burn XRP on the XRPL mainnet via an arbitrarily high transaction fee and mint a
matching number of Xahau XRP into their cloned Account on Xahau.
5.6 This mechanism involves the following steps:
(a) Burn Fees on XRPL: The first step involves burning a certain amount of XRP
on the XRPL by executing an AccountSet transaction with an arbitrarily
high fee. Once the transaction is validated, the high fee now represents
burnt (i.e. the irreversible destruction of) XRP. This XRP is removed from
circulation on the XRPL and can never be recovered based on current
ledger rules.
(b) Generating an XPOP (Proof of Burn): Using a special client that listens to
XRPL for Burn2Mint transactions and the validation messages for the
ledgers they appear in, an XPOP (see: XLS41) is generated for the
transaction. The XPOP is a non-interactive offline cryptographic proof that
the transaction was applied on the XRPL. Any party with an XPOP verifier
can verify that the burn happened.
(c) Minting on Xahau: The XPOP of the burn transaction is submitted to Xahau
using an Import transaction. The Import transaction must be performed on
Xahau by the clone Account (same r-address and same private key/s) of
the XRP Account that initiated the burn transaction. The XPOP is
converted into a hex blob and supplied as a field in the Import
transaction. If all conditions are met Xahau now mints the required
number of Xahau XRP to the Xahau Account.
(d) B2M Ratio Schedule: The amount of Xahau XRP minted in response to
each XRP burned is determined by the B2M Ratio Schedule. The B2M
Ratio Schedule starts at parity - 1 XRP burned mints 1 Xahau XRP - for the
first 2 million ledgers from launch. It then reduces smoothly with every
ledger closed - each XRP burned mints progressively less Xahau XRP - for
the next 28 million ledgers, until the Burn2Mint function self-terminates
after the 30 millionth ledger from launch.
Xahau’s B2M Ratio Schedule
Xahau Ledgers Closed Since
Genesis Amendment Activated
B2M Ratio
XRP Burned : Xahau XRP Minted
First 2 million ledgers 1:1
Next 28 million ledgers 1 XRP burned mints 1/28 millionth
less Xahau XRP per ledger closed
After the 30 millionth ledger from
launch
Burn2Mint disabled - no further
minting possible
Page | 12
(e) Cloning Account on Xahau Ledger: The Import transaction is special
because it can be submitted using an Account that does not yet exist on
Xahau. If the clone Account does not yet exist on Xahau, it will be
created as part of the minting process, and the network will credit the
Account with 2 Xahau XRP, which covers the account reserve (1 Xahau
XRP) and 5 ledger objects, for free, to get started. If the Account is
created but Xahau is uncertain about its keying (because a RegularKey
or SignerList was used) then the account will be created in a blackholed
state. If the Account already exists on Xahau then the ImportSequence
number on the AccountRoot is verified against the Sequence in the burn
transaction (which is embedded inside the XPOP) to prevent replay
attacks. Upon successful Burn2Mint the ImportSequence is updated to
reflect the most recently submitted XPOP for this account.
(f) Key Synchronization: The keying information for an account on the XRPL
may also be imported to Xahau at any time, at the user’s discretion. This is
done by using a SetRegularKey or SignerListSet transaction on the XRPL
mainnet and then generating an XPOP from it. If the user does not wish to
change their keys on mainnet then they must repeat their existing
RegularKey or SignerList within the relevant transaction (thus executing
the transaction but not making any changes to the account keying). The
XPOP can then be used with the Import transaction on Xahau to transfer
the mainnet keying to the same account on Xahau. This is useful for
multisign accounts, vanity addresses and for accounts with a
compromised master key.
5.7 Together, these steps allow a user, if they ever so choose, to clone their existing
XRPL account on Xahau and to mint Xahau XRP into that clone account by
burning XRP on mainnet via transaction fees. The process both guarantees the
XRP has been burned and that both accounts are controlled by the same
person.
5.8 Anybody wishing to convert Xahau XRP back into mainnet XRP can do so by
trading it through a centralised exchange in lieu of other technical solutions
(bridges, atomic swaps or a reverse path Burn2Mint, if the Import amendment
goes live on the XRPL mainnet) being implemented.
Benefits of Burn2Mint
5.9 Burn2Mint function has several important benefits:
(a) Decentralised: No one can block access to the Burn2Mint mechanism,
and no authorization is needed to use it. For some users, in some cases,
Burn2Mint may be the only legal option to obtain liquidity on Xahau.
Page | 13
(b) Self-sovereign Liquidity: Both sides of the Burn2Mint mechanism can (and
should) run on the user’s own infrastructure. The user burns XRP on their
own infrastructure, generates and submits the XPOP to their own
infrastructure, and thereby also mints the Xahau XRP on their own
infrastructure. Aside from being decentralised and censorship proof, this
means that everyone, but particularly exchanges and businesses, can
freely decide when and how much XRP to move to Xahau. They provide
their own liquidity to themselves, on demand, on their own infrastructure.
(c) Non-Custodial: Burnt XRP ceases to exist on the chain on which it was
burnt. Because it no longer exists, the burnt XRP cannot become
someone else’s property, it cannot be held in trust, nor in a “Door”
account, nor in some sort of custodial or escrow arrangement. Therefore,
Burn2Mint is truly non-custodial and there is no counterparty or
intermediary.
(d) Exploit-Resistant: Burn2Mint XPOPs rely on the same trust mechanics that
secure the XRPL, in particular validators keys and validator list keys. As a
result, the Burn2Mint mechanism is at least as secure as the network itself
against witness (i.e. validator) hijacking and tampering.
(e) Key Free: In a traditional two-way bridge, a “Door” account containing
users’ locked funds is maintained by some set of signing keys or witness
keys. This means there are keys somewhere that could be used to gain
unauthorized access to the “Door” account and exploit the bridge by
distributing users’ locked funds to an unauthorized third party. By contrast
the Burn2Mint solution does not use a “Door” account, and thus there are
no keys and no locked funds to hack.
Impact on XRPL
5.10 Burn2Mint effectively gives every XRP holder the option to port their XRP to
Xahau. That option will be valuable and useful to the extent Xahau’s smart
contract features mean the market prices Xahau XRP higher than XRP on
mainnet. The progressive “halvening” of the B2M ratio and eventual disabling of
the B2M mechanism prevents any risk that all XRP might be burned in this way.
5.11 Enterprise users may be better served using centralised exchanges to purchase
the Xahau XRP they need. If the market values Xahau XRP the same as XRP on
mainnet this would imply sufficient liquidity of each token exists to meet user
demand.
Page | 14
Burn2Mint Summary
5.12 Burn2Mint is a novel cross chain value transfer mechanism for XRPL protocol
and PoA-backed chains. The mechanism involves a value transfer primitive that
is self-sovereign, secure, and avoids many of the legal and technical pitfalls
associated with traditional value transfer methods. Its inclusion in the ecosystem
adds a native, decentralised option to transfer value from the XRPL without a
counterparty and without custody.
6. Xahau Governance Game
6.1 XRP Ledger Consensus Protocol (Previously: Ripple Protocol Consensus
Algorithm) chains rely on a robust overlap in validator UNLs to define the
canonical ledger. If a validator does not trust enough of the same machines
that everyone else trusts, they risk unknowingly listening to an irrelevant fork of
the ledger. Determining the best UNL is a matter of social (off-chain) consensus.
6.2 To assist that social consensus, various entities publish dUNLs – lists of validators
everyone should follow. Xahau will follow the same approach, with the XRPL
Foundation and others expected to publish such lists. So, like the XRPL, Xahau
will be a public permissionless chain for which anyone can run a validator. And
like the XRPL, any update of the protocol will be dependent on more than 80%
of UNL validators supporting the changes, in the same manner as the XRPL.
6.3 While the dUNL helps define the validators responsible for the canonical Ledger,
Xahau has a second governance challenge, not present in the XRPL mainnet:
the governance of its Genesis Hook. The XRPL mainnet minted all of its XRP on
creation. Xahau cannot follow this approach. Its native token needs to be
minted in response to the happening of predefined events (i.e. Burn2Mint,
Account Adjustments, Validator Rewards.) It uses a Hook on its Genesis Account
to achieve this.
6.4 This means Xahau needs a governance mechanism for its Genesis Hook in case
the Hook needs to be adjusted or replaced. This is known as the Governance
Game:
(a) Purpose: The Governance Game exists to ensure that the UNL validators
remain active and allows those active members to maintain the Hook on
the Genesis account that controls the distribution of Xahau XRP.
(b) Seats: There are 20 Seats at a table. A Seat is a Xahau Account whose
vote counts in the Governance Game.
(c) L1 Table: The Governance Game requires at least the top-level table. This
is called the Level 1 table (L1 Table). This table by definition exists only on
the Genesis account according to the Governance Game Hook installed
there. A seat at the L1 table may be filled by an Account or may be
empty. These seats are called L1s.
Page | 15
(d) L2 Table: An L1 seat may itself be filled by an Account which has another,
different, Governance Hook installed on it. The seats at this table are
called L2s, and the table is an L2 Table. The structure is a self-managing
committee of 3-20 Accounts that collectively control the L1 seat and its
voting rights. Thus up to 400 Accounts may be involved in the two layer
Governance game, depending on the mix of L1 and L2 Seats.
(e) Filling Seats: L1 Seats are filled or vacated by 80% vote of all existing filled
L1 Seats. For L2 Seats, the committee of Accounts that collectively holds
that L1 Seat invites or disinvites new members (up to a maximum or 20
and down a minimum of 3) by majority vote, or according to whatever
other logic or rules they deem fit. No other Seats have any control over
the members of an L2 Table.
(f) Voting: Each L1 Seat has 1 vote in the Governance Game. For L2 Seats,
the single vote of its L2 table is determined by whatever logic that L2
table decides. The default is more than 50% vote of the L2 Seat members
at that L2 table.
(g) Hook Changes: All changes to the Hook are voted on via the
Governance Game. A Hook change is only successful if supported by the
defined % vote of all Seats. The regular vote is 80%, but for the increase of
the rate of balance adjustment it is 100%.
(h) Rewards: To incentivise L1 Seats to run reliable validators, L1 Seats earn
monthly Rewards provided they actively participate in consensus.
(i) Foundation of dUNL: The validators run by those participating in the
Genesis Hook Governance Game should form the foundation of any
dUNL, as any Seat that performs unreliably risks being voted out by the
other Seats.
6.5 The different types of Seats allow for a greater diversity of participating
Accounts without undermining security. Level 1 Seats are suitable to Accounts
controlled by significant entities the community can trust, while Layer 2 Seats
allow a broader pool of participants, but since their collective participation
counts as 1 vote, their numbers do not overwhelm the trust placed in Level 1
Seats.
6.6 Thus, the Governance Game allows up to 400 Accounts to participate and
rewards those Accounts for doing so provided they also participate in
consensus by running a reliable validator.
7. The Xahau Launch Alliance
7.1 Xahau has been developed by an alliance of 5 independent entities with a
track record of building on and supporting the XRPL ecosystem. Those entities
are as follows:
Page | 16
(a) XRPL Labs (Xaman), the software developer behind the XUMM wallet,
Hooks, and Xahaud that has carried most of the expertise and cost of
developing Xahau.
(b) GateHub Limited, a multinational technology company, crypto
exchange, and crypto service provider, including Stablecoins issued on
the XRPL.
(c) Titanium OU, an IT consulting and infrastructure firm specialising in
providing secure hosting and a major provider of the infrastructure for the
XRPL (as Alloy Networks).
(d) Evernode Labs Ltd, the developer of the Evernode smart contract project
and responsible for deploying it to Xahau.
(e) Digital Governing OU, an incorporated entity associated with a globally
active firm for accounting, audit, and legal services.
8. Launch Fully Functional & Decentralised
8.1 Xahau will launch fully functional and decentralised without raising funds.
No Centralised Control
8.2 Xahau will launch with 8 of its 20 Governance Game Seats filled:
(a) 5 will be Layer 1 Seats, each filled by a member of the Xahau Launch
Alliance.
(b) 3 will be Layer 2 Tables, one of which will be filled by a committee of
Exchanges and the other a diverse committee of XRP community
projects, developers, and long-term supporters.
(c) 1 will be FYEO, a company offering code audit and review services on
blockchain development, including software such as Hooks.
No Funds Being Raised
8.3 There is no ICO, and no funds are being raised from the launch.
8.4 The Xahau Alliance members have each independently funded their own
development efforts. There’s no communal funding, nor any pooling of money
or resources for the further development of Xahau. Nor is there any roadmap, or
“Xahau Foundation”, or other centralised treasury. Any further development is
wholly at the discretion of independent actors within the ecosystem.
Page | 17
No Promises
8.5 The Governance Game members are independent entities. There is no
agreement, arrangement, or understanding between them about how to cast
their vote, deploy their resources, or use their assets, including any Xahau XRP. It
is only the logic of the Game – be a trustworthy Validator in the eyes of the
other members or be voted out of the Game – that drives Validator behaviour.
This is an inherent feature of the XRP Ledger Consensus Protocol (Previously:
Ripple Protocol Consensus Algorithm) (PoA) mechanism Xahau uses.
No Further Features Needed
8.6 While software, by its nature, needs to be maintained, there are no essential
functionalities missing from Xahaud or in need of further development for the
software to be useful as a smart contract sidechain of the XRPL.
Page | 18