Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Maya Protocol Quick Guide
Users are not required to use CACAO in order to swap/trade Assets (e.g. BTC, ETH, RUNE, DASH, KUJI or ARB). Users can simply connect to any Frontend that supports MAYAChain, and trade away.
However, should users desire to perform other types of transactions, CACAO fees may apply.
Head to one of the interfaces supporting Maya Protocol and connect your wallet.
Transfer any of the MAYAChain supported Assets (e.g. BTC, ETH, RUNE, DASH, XRD, KUJI or ARB) to your newly created wallet.
Head to the swap page, select the tokens and quantity, and perform the swap.
There are four key roles in the system:
Liquidity providers who add liquidity to pools and earn fees and rewards
Swappers who use the liquidity to swap assets ad-hoc, paying fees
Arbitrageurs who monitor pools and rebalance continually, paying fees but with the intent to earn a profit.
Node Operators who provide a bond and are paid to secure the system
MAYAChain's value proposition for Swappers.
On MAYAChain, users can swap their digital assets for other digital assets. The network aims to give users access to:
A large variety of assets through cross-chain compatibility and simple asset listing
Superior user experience through open finance protocols and permissionless access
1-transaction access to fast chains (Dash), smart chains (Ethereum, Kujira), and censorship-resistant chains (Bitcoin).
Users can swap any assets which are on connected chains and which have been added to the network. Users can swap from any connected asset to any other connected asset. They can also swap from any connected asset to CACAO.
Learn more about how chains and assets get added to the network in the Governance section.
To add an asset to MAYAChain, users simply deposit a new asset to put it in the queue for listing. Swaps can only be made on pools when they have been added to the network and have moved out of the bootstrap phase.
MAYAChain manages the swaps in accordance with the rules of the state machine - which is completely autonomous. Every swap that it observes is finalised, ordered and processed. Invalid swaps are refunded, valid swaps ordered in a transparent way that is resistant to front-running. Validators can not influence the order of trades, and are punished if they fail to observe a valid swap.
Swaps are completed as fast as they can be confirmed, which is around 5-10 seconds.
Swaps on MAYAChain are made possible by liquidity pools. These are pools of assets deposited by Liquidity providers, where each pool consists of 1 connected asset, for example Bitcoin, and MAYAChain's own asset, CACAO. They're called Continuous Liquidity Pools because CACAO, being in each pool, links all pools together in a single, continuous liquidity network.
When a user swaps 2 connected assets on MAYAChain, they swap between two pools:
Swap to CACAO in the first pool,
Move that CACAO into the second pool,
Swap to the desired asset in the second pool with the CACAO from (2)
The MAYAChain state machine handles this swap in one go, so the user never handles CACAO.
See this example for further detail and the page below for broader detail on Continuous Liquidity Pools.
The output of a swap can be worked out using the formula
where
x is input asset amount
X is input asset balance
y is output asset amount
Y is output asset balance
The BTC.CACAO pool has 100 BTC and 2.5 million CACAO. A user swaps 1 BTC into the pool. Calculate how much CACAO is output:
This user swaps 1 BTC for 24,507.40 CACAO.
The cost of a swap is made up of two parts:
Outbound Fee
Price Slippage
All swaps are charged a network fee. The network fee is dynamic – it's calculated by averaging a set of recent gas prices. Learn more about Network Fees.
Note that users who force their swaps through quickly cause large slips and pay larger fees to liquidity providers.
Introduction
Maya Protocol is the ecosystem that encompasses both MAYAChain and AZTECChain. These two entities, when combined, are capable of demonstrating the power & advantages of both centralized and decentralized exchanges without inheriting the associated drawbacks.
MAYAChain is an Automated Market Maker, similar to Uniswap, but utilizes cross-chain liquidity. Conventionally, cross-chain swaps have been achievable through wrapping assets and bridging, which pose a serious security risk. According to Chainalysis, $2 billion were lost to bridge hacks in 2022 alone, representing 69% of all DeFi hacks.
MAYAChain is a friendly fork of THORChain. Similarly, it does not rely on pegging or wrapping assets, instead managing funds directly in on-chain vaults and safeguarding them through economic security. This is achieved using the Tendermint consensus engine, Cosmos-SDK state machine, and GG20 Threshold Signature Scheme (TSS).
Interact with MAYAChain using one of the frontend integrations.
AZTECChain is a Smart Contract chain. It exemplifies the potential of Maya Protocol, combining MAYAChain cross-chain liquidity with Smart Contracts and economic capabilities. Smart Contracts provide flexibility for crypto economies, allowing for the creation & use of Algorithmic stablecoins, derivatives like Synths, CEX style order book trading, and many more capabilities. AZTECChain is a fork of the Cosmos Hub (Gaia), allowing for the immediate utilization of the Cosmos mature infrastructure and Smart Contract development ecosystem. Algorithmic stablecoins will be delayed upon launch in order to complete economic design and run bounties. Neither the Maya nor the Aztec Chains will subsidize yield in order to inflate demand for their respective stablecoins or derivatives.
Maya Protocol ecosystem utilizes 3 distinct tokens within its framework:
The CACAO & $MAYA tokens are already in circulation, while AZTEC is still under development.
CACAO (Live) is the primary token of the ecosystem, which is utilized to pay for all transaction fees on both the Maya and Aztec Chains. CACAO is also the settlement token, used in pools in MAYAChain.
MAYA (Live) is a revenue share token. 10% of all swap & transaction fees on MAYAChain is distributed to $MAYA holders in the form of daily CACAO rewards.
AZTEC (under development), like MAYA, is a revenue share token. 10% of all transaction fees on Aztec Chain is distributed to AZTEC holders.
All CACAO has been allocated fairly in the liquidity auction. The team has not been allocated any CACAO, and any CACAO acquired by the team was acquired in the same manner as the community. Rather, the team has opted to have allocations of MAYA and AZTEC. This ensures that the team is in alignment with the vision of building and delivering, as they will not be able to gain any benefit unless Maya Protocol is profitable.
MAYAChain shares numerous innovations with THORChain that were derived from the fundamental principles of being decentralized, resistant to capture, and as sustainable as possible.
Capped Proof of Bond validator selection helps to maintain the decentralization of the network and a high Nakamoto Coefficient.
Periodic Validator Churning process serves to prevent validator stagnation, verify the spendability of funds, and enhance the overall performance of the network with minimal governance requirements.
A churn in MAYACHAIN happens once every 5 days, if no issues present themselves.
Asynchronous Network Upgrades allow validators to transition to a new protocol version at their own pace, while the network remains in consensus without disruption.
Chain-agnostic Bifrost Protocol can manage UTXO, EVM, BFT and Cryptonote chain connections with minimal differences in its core logic.
Incentive Pendulum system provides rewards to Validators and Liquidity Providers in order to maintain a Network Security ratio that ensures the security of funds at all times.
Continuous Liquidity Pools enable single-sided liquidity provision and employ liquidity-sensitive fees to thwart price attacks.
Swap Queue has been implemented which orders swaps based on the price impact in each block, thereby preventing sandwich attacks and most other forms of Miner Extractable Value (MEV).
Liquidity Synths have been developed to facilitate rapid, low-cost exchanges between L1 pool. Synths are a hybrid collateralized-pegged asset design that contribute to the liquidity of the market.
MAYANodes secure MAYAChain. They are intended to initially number 100, but can scale up to 250+. The design of MAYAChain is such that anyone with the necessary funds can join the network anonymously and securely, without requiring permission. Furthermore, MAYAChain takes this a step further by having a high churn rate, which ensures that the network is censorship-resistant, evades capture and resists centralization.
Each MAYANode is composed of multiple independent servers in a cluster, which run full-nodes for each linked chain.
Enhance the Security of the network through Functional (Solvency Checker, Node Pause, TxOut Throttler), Procedural (Stagenet testing, PR reviews) and Economic (LP units in the bond, or value of the LP units in the bond) Security measures.
Increase the Liquidity of the network, via Total Value Locked (TVL), or better UX around providing liquidity.
Boost the Volume of the network, via Swap UX (Synths, Order Books), or wallet Integrations (Quotes Endpoint, Dev UX, Business Development).
Balancing pools to exploit price deltas between markets.
Prices on MAYAChain are maintained by profit-seeking Arbitrageurs. Arbitrageurs find assets that are mispriced between markets. They buy assets on markets with low prices and sell them on markets with high prices. This earns them a profit.
Arbitrageurs compare the exchange rates on MAYAChain with the rates on external markets. If they find the price is lower on MAYAChain they can buy there and sell on an external market. If they find the price is lower on external markets they can buy there and sell on MAYAChain. This process is repeated at high-frequency. Over time, price information propagates and MAYAChain settles with external markets.
This is how MAYAChain avoids the need for oracles and how prices are set.
A swap takes place in the ETH/CACAO pool. This leaves the pool unbalanced. The ratio on MAYAChain is 20:1 ETH:CACAO, but is 16:1 on external markets. This means that CACAO is undervalued on MAYAChain.
Arbitrageurs can now buy cheap CACAO on MAYAChain and sell it for a profit on external markets. To do so, they swap ETH into the pool and get CACAO out. They sell this CACAO on external markets and make a profit.
The economics of the swap formula mean that Arbitrageurs should aim to restore balance to the pool in a single trade. Rebalancing should be done incrementally. If larger rebalancing trades are attempted, arbitrage may not be profitable.
Specifically, each rebalancing trade should be 40–50% the imbalance size. So if the imbalance starts at $100 in value, the first rebalancing trade should be between $40–50. This will leave the imbalance at $50–60. The next rebalance should be $25–30. This process repeats until a satisfactory balance is restored.
This hierarchical cascade of rebalancing trades will create arbitrage opportunities for Arbitrageurs big and small.
Trading profits are impacted by liquidity on MAYAChain and on external markets. As an example, if the price of the asset in a MAYAChain pool is $1.20, but the same asset on an external market is $1.00, then someone can buy off that external market and sell into the MAYAChain pool for profit.
If both markets are infinitely deep, then the following will occur:
Buy on External Market for $1.00, no price slip.
Sell on MAYAChain for $1.20, no price slip.
Total Profit: 20%
The trader can then continue to arbitrage for a profit of 20% continuously.
If both markets have finite liquidity, but one is much deeper than the other, then the one of the markets will slip in price after the trade. However, the Arbitrageur will experience a price that is roughly the average of the price before and after the trade:
Buy on External Market for $1.00, no price slip.
Sell on MAYAChain for $1.20, realised price of $1.10, price slip to $1.00.
Total Profit: 10%
After the trade, there is no more price differential, but the Arbitrageur made 10% in profit. The Arbitrageur has made the pool price equal to the secondary market. They have transferred price information from one market to another.
If both markets have low liquidity, then the Arbitrageur is attempting to make trades that slip each market towards each other:
Buy on External Market for $1.00, realised price of $1.05, price slip to $1.10.
Sell on MAYAChain for $1.20, realised price of $1.15, price slip to $1.10.
Total Profit: >10%
The market now has no more price differential. The Arbitrageur has made each market equal to each other.
MAYAChain does not offer explicit incentives to Arbitrageurs – it does not reward or punish them. Trading profits are determined by the capacity of Arbitrageurs to seek out and capitalize on price differentials between MAYAChain and external markets.
The majority of arbitrage opportunities will be exercised by software bots. These are under development by 3rd party entities and will be released in due time. They will be open-source and available for anybody to run.
List of all Wallets and UIs integrations with Maya Protocol.
Maya Protocol is a backend infrastructure. Therefore, you will need a user interface to interact with and use Maya Protocol. Different user interfaces are available. Here’s the complete list.
Type: Decentralized Exchange
Accessibility: Web App and Mobile
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya and THORChain-supported L1
Supported wallets Webapp: Ledger, XDEFI, Metamask, Keystore
Go to Thorwallet DEX
Type: Decentralized Exchange
Accessibility: Web App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1, Polkadot
Supported wallets: Ctrl Wallet, Keystore
Go to El Dorito Swap
Type: Decentralized Exchange
Accessibility: Web App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1
Supported wallets: Keystore, MetaMask, Ctrl Wallet, Keplr, Leap
Go to Cacao Swap
Type: Decentralized Exchange and Wallet
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Streaming Swaps
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1, and THORChain
Supported wallets: Keystore, Ledger
Go to Asgardex
Type: Decentralized Exchange
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Streaming Swaps
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1
Supported wallets: Ctrl Wallet, Metamask, KeepKey, Ledger, Brave Wallet, Trustwallet, and Trezor.
Go to ThorSwap
Type: Decentralized Exchange
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1
Supported wallets: Ctrl Wallet, Metamask, Trust Wallet, Phantom Wallet, Trezor Wallet, Ledger, OKX Wallet, Wallet Connect, Keplr Wallet, Brave Wallet, Radix Wallet, KeepKey.
Go to InstaSWap
Type: Decentralized Exchange
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1
Supported wallets: Radix Wallet
Go to Astrolescent
Type: Decentralized Exchange
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Blockchain support: All Maya-supported L1
Supported wallets: Ctrl Wallet, Metamask.
Type: Decentralized Exchange
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Blockchain support: All Maya-supported L1
Supported wallets: Ctrl Wallet, Metamask.
Go to LeoDEX
Type: Portfolio tracker and analytics tool
Accessibility: Desktop App Features:
Portfolio Tracking for Maya Assets: Users can seamlessly monitor their $CACAO holdings and other assets across chains supported by Maya Protocol.
Cross-Chain Insights: Pulsar provides detailed analytics for swaps and liquidity pools within Maya Protocol, offering valuable insights for both traders and liquidity providers.
Real-Time Data: Access up-to-date stats and performance metrics from Maya Protocol to stay ahead of the market.
Enhanced User Experience: By integrating with Maya Protocol, Pulsar makes it easier for users to track and manage their cross-chain activities in one place.
Go to Pulsar Finance
Type: Decentralized Exchange
Accessibility: Desktop App
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps powered by Maya
Manage your liquidity and saver's position on Maya
Blockchain support: All Maya-supported L1
Supported wallets: Ctrl Wallet, Metamask, Keplr, Phantom, Walletconnect, Leap Wallet, Argeentx, Braavos, Trustwallet, and Rabby.
Go to Defispot
Ctrl Wallet is a multi-ecosystem self-custody wallet with support for 30+ native blockchains, and all EVM and Cosmos chains, including Bitcoin, Ethereum, Solana, THORChain, Maya Protocol, TRON, and more.
Type: Multichain non-custodial wallet
Available on: Web extension
Features:
Send and receive CACAO and MAYA
Blockchain support: Bitcoin, Solana, all EVM, all Cosmos, THORChain, MAYA, TRON, DOGE, Litecoin, NEAR, Binance Smart Chain
Hardware wallet integration: Ledger, Trezor.
Go to Ctrl Wallet
CaviarNine is a platform that provide web3 users with advanced and user-friendly DeFi trading products built on the Radix platform. Type: Multichain non-custodial wallet
Available on: WebAPP
Blockchain support: Radix Tokens.
Go to Caviar Nine
Moca is a cryptocurrency wallet for easily managing your balances and tokens across all platforms – no prior experience required.
Type: Multichain non-custodial wallet
Available on: WebAPP
Features:
Send and receive CACAO and MAYA
Blockchain support: BTC, ETH, LTC, DASH, MATIC, ADA, AVAX, SOL, ATOM, DOGE, BNB.
Go to Moca
Vultisig is the first institutional-grade, privacy-focused, multi-chain wallet on the market, built on THORChain’s vault technology. Designed for both individuals and organizations, it offers unparalleled security, privacy, and functionality for managing digital assets seamlessly across multiple blockchains.
Available on:
Web
iOS
Android
Features:
Send and receive CACAO and MAYA
Blockchain support:
Arbitrum, Avalanche, BSC, Base, Bitcoin, Bitcoin-Cash, Blast, Cosmos, CronosChain, Dash, Dogecoin, dydx, Ethereum, Kujira, Litecoin, Maya Protocol, Optimisim, Polkadot, Polygon, Solana, Sui, THORChain, Ton, Zksync
Go to Vultisig
A retro-inspired, no-frills crypto wallet designed for enthusiasts who value simplicity and control. With its Windows 3.11 aesthetic and focus on direct phrase-based authentication, it keeps things intuitive while offering powerful tools for managing cross-chain wallets, swapping assets, and enhancing security.
Type: Multichain non-custodial wallet
Available on: Web extension
Features:
Send and receive CACAO and MAYA
Go to WinBit32
Edge is a powerful and easy to use cryptocurrency wallet that allows users to easily control their own private keys with the familiarity and ease of mobile banking.
Type: Multichain non-custodial wallet
Available on: Web extension
Features:
Send and receive CACAO and MAYA
Blockchain support: Bitcoin, Ethereum, Litecoin, EOS, Stellar, XRP, Dash, Monero.
Go to Edge
KeepKey is a hardware wallet for securely storing digital assets.
Type: Hardware Wallet
Features:
Send and receive CACAO and MAYA
Cross-chain native swaps: Yes (In firmware, no dApps yet)
Manage liquidity and saver's position: Yes (in firmware, no dApps yet)
Blockchain support: All Maya L1's, THORChain’s L1, and several EVMs and Cosmos chains.
Go to https://keepkey.com/
Explore all user interfaces, wallets, and tools, that will enrich your decentralized Maya experience to the fullest!
Maya Protocol is permissionless. Everyone can integrate Maya into their dapp, wallet, or protocol. We support all interfaces integrating Maya. Contact our marketing team on Discord to discuss co-marketing opportunities.
Disclaimer: Maya Protocol will not support swapping interfaces and wallets containing ‘Maya’ in their name. We’ve learned from other protocols that this could have negative side effects. Hence, if an interface chooses to have ‘Maya’ in its name, Maya Protocol will not engage in co-marketing and will not mention the interface on its website, docs, or Discord.
Discover a complete toolkit to tailor your Maya experience
MayaScan is a cutting-edge blockchain explorer designed for speed, simplicity, user-friendliness, stunning UI, and efficiency. It offers a streamlined and intuitive experience for users seeking to explore blockchain data from the Maya Protocol.
Features: Maya Protocol monitors for transactions, addresses, LP, analytics and networks stats, MRC-20 & M-NFT indexer powered by GLD.
Accessibility: Web and mobile responsive.
Go to Maya Scan
Maya Swap is a seamless trading platform for MAYA and CACAO tokens with a tailored order book. By holding MAYA tokens, users automatically earn daily CACAO rewards, enriching their portfolios. It was built by the MayaScan team.
Features: Buy and sell $MAYA tokens in the order book. Track prices and volume in real time.
Go to Maya Swap
Connect, Trade, Earn, Thrive. Mayans brings the worlds of social media and decentralized finance together through the Maya Protocol. Trade your MRC-20 tokens and M-NFTs. Built by the MayaScan team.
Features: Secure and private messaging, MRC-20 trading and staking, signals keeping you informed of the latest trends, playing DeFi games, and more.
Go to Mayans.app
The Maya Info Bot tracks significant transactions and crucial changes to the Maya Protocol network. Subscribers are promptly notified via Telegram, Discord, and X channels.
Features:
Tracked event types
1) Large transfers of native assets
2) Significant swap and liquidity addition/withdrawal transactions
3) Liquidity pool statistics
4) Cacao price fluctuations
5) Mimir parameter adjustments
Accessibility: Any mobile or desktop device with Telegram/Discord/X app installed or web browser.
Keep track of price, large txs, Mimir, and other alerts here!
Node Operators
MAYANodes service the MAYAChain network, of which there is intended to be initially 120. Each MAYANode is comprised of several independent servers. All MAYANodes communicate and operate in cooperation to create a cross-chain swapping network.
Node Operators earn 80% of the system income when it is stable. You can read more here:
Follow these setup up instructions
Node Operators should stay anonymous and never socially signal that they are running a node.
There are a variety of tools available in the ecosystem for Node Operators, such as the Telegram Alerts bot:
The most important aspect is that Nodes must pay for their Bond, since this is a core assumption to the security of the network. If a node pays $1m for their bond, then they will never try to steal assets unless if they can access more than $1m of funds. If they can, then they will make a profit.
If delegation was permitted, a Node Operator that paid $100k in CACAO, can possibly receive $900k in delegated funds to qualify and meet the $1m bond requirement. They will now contemplate stealing assets the moment they get access to more than $100k in capital, which is likely.
Nodes must pay for their bond to ensure the economic assumptions of the network are upheld.
MAYAChain makes private delegation possible, because it does not erode towards the issues discussed above.
Private Delegation requires Node Operators to know and whitelist in their bonders, and there can only be up to 6 per node. This assumes the bonders are in trust circles with their operators and have their own recourse to ensure operators act in accordance to their obligations. From the point of view of MAYAChain, a solo node is no different to a delegated node. The network will operate identically.
In addition, there is no discretion as to fee commissions per operator. This means bonders will prioritise on engaging with operators based purely on their trust circles, not fees.
The limit of 6 bonders per node ensures that Operators can't try to access economies of scale. They are limited to large CACAO holders only.
$CACAO, $MAYA, and $AZTEC
Maya Protocol ecosystem utilizes 3 distinct tokens within its framework:
$CACAO is our flagship token, and we will have 100M of them. They will all be minted at once, and 90% of the total supply will be distributed in the Liquidity Auction. The remaining 10% will be allocated to the Impermanent Loss Protection treasury.
Aside from being required to run a node, they can be paired against other assets inside our liquidity pools to earn a percentage of the transaction fees generated by swaps.
$CACAO is the asset which powers the Maya Protocol ecosystem (MAYAChain & AZTECChain) and provides the economic incentives required to secure the network. CACAO has three key roles which are described below.
Liquidity (as a settlement asset)
Security (as a sybil-resistant mechanism, and a means for driving economic behaviour)
Incentives (paying out rewards, charging fees, subsidising gas)
Transmitting Purchasing Power
Since CACAO is pooled 50:50 alongside external assets in its pools, when the value of those assets increase/decrease, the CACAO pooled will also increase/decrease by being arbed out or in. The CACAO unit value may not change, but the quantity of CACAO in the pool does. This means the system is always aware of the value of the assets it is trying to secure - it's simply the quantity of CACAO in all its pools.
Once it is aware of the value of the assets it is securing, it can use incentives to ensure security of those assets.
A rule of thumb is for every $1m in multi-chain assets pooled in liquidity pools, $1m of CACAO is required to be pooled along side. Due to a mechanism called the Incentive Pendulum, $2m in CACAO will be driven to be bonded. Thus, $1m in main-chain assets will cause the total value of CACAO to be $3m in an equilibrium. Thus liquidity pools have a positive effect on the monetary base of CACAO.
Providing Liquidity Incentives
Since CACAO is the pooled asset, incentives can be paid directly into each pool. This extra capital is owned by the liquidity providers, and over time, slowly "purchases" the paired asset via arbitrage. Thus CACAO liquidity incentives can drive real yield to LPs.
Solving O(n^2) Problem
Without a native settlement currency, each asset would need to be pooled with every other asset, which would eventually result in hundreds of new pools to be created for just one new asset, diluting liquidity. Having CACAO as the base pair allows any asset to be guaranteed to swap between any other asset.
No. of Assets
(eg. BTC, ETH)
No. of Pools
(Arbitrary Pairs)
No. of Pools
(CACAO Pairs)
n
pools = (n*(n-1))/2
pools = n
12
66
12
24
276
24
100
4950
100
Sybil-resistance
Sybil-resistance refers to the ability to prevent someone masquerading as many identities in order to overcome a network. Bitcoin uses Proof-of-Work (one-cpu-one-vote) to prevent a network take-over. Ethereum 2.0 will use Proof-of-Stake (32-eth-one-vote) to prevent a network take-over.
MAYAChain is a Proof of Bond network instead. MAYANodes commit a bond in order to be churned in. However, this bond isn't just used to identify a node (give them a voting slot), it is used to underwrite the assets in the pools. If the node attempts to steal assets, then their bond is deducted to the amount of the assets they stole (1.5x), and the pools are made whole. Additionally, if nodes misbehave their bond is slashed, ensuring reliable service.
Underwriting Assets
The Incentive Pendulum ensures that Nodes are incentivised to continually buy and bond enough Cacao each time to maximise their gains - which is a maximum when there is 67% of CACAO bonded and 33% pooled in pools. If the pools are holding $100m in capital, then the value of CACAO in the aggregate bond is $200m. Thus all assets can be underwritten.
The bond is extremely liquid - any CACAO holder can immediately enter or exit their position since CACAO is the settlement asset in all pools. Thus, when a node churns in, the cost basis of their bond is known to them and not an arbitrary figure. This means a node bonding $1m in CACAO will never contemplate making a decision to steal <$1m in capital from the network, else they will lose overall.
Fees
CACAO is the native currency of MAYAChain and is consumed as transaction fees on the network. All swaps are charged both a fixed network fee, as well as a dynamic slip-based fee. This prevents various attack paths such as denial-of-service attacks, as well as sandwich attacks on a pool. Learn more about fees here:
Subsidising Gas
The network continually consumes gas as it makes outgoing transactions (as well as internal transactions). Gas on networks such as Bitcoin and Ethereum becomes complicated fast, so MAYAChain doesn't make much of an effort to track every minutia of gas consumed. Instead, nodes are free to use at-will the base assets BNB.BNB
, ETH.ETH
, BTC.BTC
, etc in order to pay for gas. These assets are used directly from the vaults. MAYAChain then observes outgoing transactions, reports on the gas used, and then pays back the liquidity providers in those pools to the value of twice the amount of gas used (in CACAO).
Paying out Emissions
After fees are charged and gas is subsidised, then MAYAChain computes the block reward, divides it based on the Incentive Pendulum algorithm, and then pays out to Bonders and Liquidity providers.
This drives Nodes to bond the optimal amount, and pays Liquidity providers for their contribution of liquidity.
Learn about the Incentive Pendulum here:
In addition to the roles mentioned above, CACAO’s price has two factors; 1 a deterministic value based on the liquidity within the network and 2; a speculative premium.
The 1:1 pool ratio that persists in Maya means that CACAO will always be worth at least 1x the Asset TVL in Maya Protocol. Thus, if $1,000,000 worth of non-Cacao tokens are staked in Maya Protocol, the market cap of CACAO will be at least $1,000,000 as well. And like any token, stock, or asset in the world of finance, speculation around future value encourages additional upward price pressure.
The 1:1 ratio is just the minimum or the deterministic value of CACAO.
$MAYA tokens can be used to participate in our protocol's total revenues, and there are exactly 1 million of them. They serve as our initial stages' funding mechanism and, by design, keep incentives for our developer team to continue their hard work in the short-term and long term.
$MAYA captures 10% of all the protocol revenue. Those who hold $MAYA tokens will be distributed $CACAO every 24 hours to the wallet that holds the $MAYA token. For every $9 earned by LPs/nodes, $MAYA holders, including founders/devs, earn 1$, incentivizing long-term growth and value accrual.
1 Million Token in total.
Founders have 15.6% that can't be sold.
Maya Protocol Operations Wallet - used to pay the team, marketing, and other expenses- can be found in this link.
How will $MAYA Airdrop work?
7% to Rune Owners. 7% to Early Nodes. 7% to Tier 1 Liquidity Providers. 1% to Maya Mask NFT Holders (80% built into the Maya Mask, 20% airdropped as tokens)
78% Dev Fund.
Will there be a liquidity pool to trade $MAYA?
There will be no liquidity pool for $MAYA, and it will not be tradable on Maya Protocol. It is meant to represent the protocol revenue and is not easily tradable. Another DEX/CEX could list $MAYA for trading if they desire.
$AZTEC tokens are very similar in design to $MAYA tokens as they are also revenue share tokens, that capture 10% of all the AZTECChain revenue. $AZTEC will be launched with the AZTECChain by the end of year.
Mimir v2 shifts control to node operators, letting them adjust permissions and halt chains when needed. It boosts decentralization and empowers the community to propose and vote on upgrades, ensuring Maya evolves with transparency.
Enables users to access Smart Contracts and build advanced DeFi tools like derivatives and algorithmic stablecoins within the Maya ecosystem.
Zcash $ZEC is depositable into Maya for Swaps & Liquidity actions.
Maya integrates Taproot+, bringing enhanced privacy and scalability to Bitcoin transactions. This unlocks exciting new DeFi use cases for BTC, making it more versatile and efficient in the Maya ecosystem.
Kaspa $KAS is depositable into Maya for Swaps & Liquidity actions.
Enabling swaps between THORChain & MAYAChain assets.
Cardano $ADA is depositable into Maya for Swaps & Liquidity actions.
Will be announced accordingly.
Unlocking CACAO: A Step-by-Step Guide to Seamless Token Acquisition
The CACAO token is not listed on any Centralized Exchange.
You can buy CACAO by swapping BTC, ETH, USDT, USDC, wstETH, RUNE, DASH, KUJI, or USK to CACAO on one of the following interfaces:
Step by Step:
Create your wallet on your chosen interface.
Load your wallet with your chosen asset (BTC, ETH, USDT, USDC, wstETH, RUNE, DASH, KUJI, USK or AETH).
Select Swap.
Enter the amount you wish to swap and the asset you want to get; in this case, the asset you want to get is CACAO.
You are ready!
Resources:
We have developed guides that explain step by step how to use each user interface:
Find our guides in the following sections.
How to set up a new MAYAChain keystore wallet using ElDorado
Here is the video guide to create a Keystore wallet on El Dorito. If you prefer a written guide, please continue scrolling.
2- On the top right corner press the "Connect" button to connect your wallet.
3- A pop-up will appear. Choose "Create new keystore".
4- Create a password to encrypt your keystore.
Make sure it's a safe password that you can REMEMBER.
5- Once you press create you'll be prompted to save your Keystore file on your computer. Choose a safe location and save.
6- You'll be presented with a 12-words seed phrase. Make sure to write it down or save it somewhere safe.
If you lose your keystore or forget your password, the only way to recover your wallet is using the seed phrase. If you lose that too no one will be able to help you, and your funds may be lost forever.
7- Congratulations! Your wallet has been created and you can now interact with El Dorito and all Maya Protocol's Front Ends using your Keystore.
How to install VultiWallet on your mobile device
Download VultiWallet on your iOS or Android device.
Clicking on the "Get Started" button, and agree to the Terms of Service and Privacy Policy, after which the wallet setup starts on the following screen:
Click create new wallet. After clicking on Create Wallet, you will be asked to write down your unique seed. You can view your seed phrase by clicking on “Backup Wallet”.
Click Backup Wallet. You will see the following screen with your seed phrase.
Copy the seed to your clipboard and keep it on your phone, or (highly recommended) write it down and keep it off-line.
Create a PIN.
Confirm your PIN.
You have the option to unlock the wallet using biometrics. Simply click on “Enable Biometrics” to activate this feature, or choose “Skip” if you prefer not to enable it.
How to set up a new MAYAChain keystore wallet using THORWallet
2. Accept the Terms of Service and Privacy Policy.
3. Select "Create Keystore."
4. Create and confirm a password for the keystore file. Make sure to save this password. You'll need it to open the keystore file. Make sure to save the 12-words seed phrase; you can use it to recover your wallet if you lose your keystore.
5. Click "Download" and save the keystore file somewhere safe on your local drive.
6. On Connect screen select "Keystore" option to connect using your newly created keystore file.
7. Select the new keystore file saved on your drive, input your password and click "Unlock."
8. Select "My Assets" from the left sidebar.
9. Search for MAYA token in "Search assets" at the top.
10. Select MAYA.
11. Change the tab from "Send" to "Receive" - there, you will be able to copy your new Maya wallet address. It should begin with "maya..."
Save your new Maya wallet address, and keystore (if you created one), and password in a safe place. You’ll need your Maya address for the next steps.
In the example, the Maya wallet created with the keystore file was:
maya1668cguves6x7sfm08pkm2u78exwaq63t9kqwse
Create a new XDEFI wallet, or use an existing one. Make sure to “Prioritize XDEFI” in the settings.
Import Ledger accts into XDEFI via Settings > Wallet management > Connect to the hardware wallet. This opens a new screen.
Plug the Ledger into the computer’s USB port, enter the PIN code to unlock, and select the chain app on the Ledger device you want to open (ex., Bitcoin app).
If you get this type of error you can find a debug checklist for importing Ledger into XDEFI at the end of this guide.
In the browser, select the addresses from that chain to import.
Once complete, go back to XDEFI and repeat the process to add hardware wallets to XDEFI from other Ledger chains.
Make sure to quit the Ledger device app first, then open the chain app on Ledger you’re adding next.
When you open THORChain app on your Ledger, the first screen says “Pending Ledger Review” - double-click past this, so the Thorchain app is open and ready.
Swap Assets Using Custom Memos.
SWAP:ASSET:DESTADDR
Connect/Create wallet.
Transfer from the ASSET you want to swap from (eg. ETH).
In the memo field substitute the format for the actual values. Example:
SWAP:MAYA.CACAO:maya1x5979k5wqgq58f4864glr7w2rtgyuqqm6l2zhy
or you can abbreviate it to:
=:MAYA.CACAO:maya1x5979k5wqgq58f4864glr7w2rtgyuqqm6l2zhy
In the amount field, type the amount you wish to swap
Press send.
How to create a MAYAChain address through MAYANode cli
Follow up on CACAO behavior on or .
Here you'll find step-by-step guides on how to , using custom memos, and & Liquidity.
1- Visit El Dorito and press the "Enter El Dorado" button.
For further assistance, please visit ElDorito's channel and/ or Maya Protocol's channel.
Finally, you can scroll through some information slides about functionalities or just click on “Get Started”, which will bring you to the “home page” of the app.
1. Go to and click "Connect."
Still from your LEDGER device and for the Ethereum network, you may need to open 'Settings' and enable the 'Blind signing' option. Please read closely the .
This guide should only be used by Advanced Users. It is highly recommended to use to transact. A mistake in any step CAN cause loss of funds.
For a full list of memo formats and abbreviations check this .
Make sure you have an amount left in your (from) wallet to cover the transaction fees. Check the following for , , RUNE fees (0.02 $RUNE), , KUJI fees (around 0.003 $KUJI, but confirm through a Kujira Wallet).
Check your transaction/Maya Address on .
go 1.20+.
Clone the .
Install .
Install $ git clone https://gitlab.com/mayachain/mayanode
Learn how MAYAChain Works
MAYAChain charges a fixed Outbound Fee and a dynamic Liquidity Fee.
Conceptually, fees are both value-capture, access-control and resource-subsidisation mechanisms.
The fees need to capture value from those accessing the resource, and pay it to those providing the resource, and in this case the resource is liquidity. However liquidity is relative to the size of the transaction that demands it over the depth of the market that will service it. A small transaction in a deep pool has less demand for liquidity than a large transaction in a small pool.
The other reason for fees is access-control; a way to throttle demand for a fixed resource and let natural market forces take over. If there is too much demand for a resource, fees must rise commensurately. The resource in this case is liquidity, not market depth, thus fees must be proportional to liquidity.
Resource Subsidisation
Every swap on MAYAChain consumes resources (Disk, CPU, Network and Memory resources from validators). These costs are fixed in nature. In addition, every outgoing transaction demands resources on connected chains, such as paying the Bitcoin mining fee or Ethereum gas cost. As such, MAYAChain charges a single flat fee on every transaction that pays for internal and external resources.
In addition to the above, fees also create the following benefits:
Avoid dust attacks
Store up income after the initial Emission Schedule reduces
Give the user a stable fee, rather than a dynamic one which changes with the external network's fees
MAYAChain maintains an awareness of the trailing gas price for each connected chain, saving both gas price as well as gas cost (inferring transaction weight). Nodes are instructed to pay for outgoing transactions using a gas price that is a multiple of the stored value.
The gas is consumed from each chain's base asset pool - the BTC pool pays for Bitcoin fees, the ETH pool for Ethereum fees etc.
The network then observes an outgoing transaction and records how much it cost in gas in the external asset. The final gas cost is then subsidised back into each pool by paying CACAO from the reserve.
The user is charged an amount that is three times the stored gas cost for each chain. The Node can then pay a gas price that is 1 times the gas price, and the pool is subsidised a value that is twice what was observed. This means the pool earns a margin of 1x, and the Reserve earns a margin of 1x.
Example:
Bitcoin
$1
$3
$1
$2
$1
Ethereum
$10
$30
$10
$20
$10
Cosmos GAIA
$0.03
$0.09
$0.03
$0.06
$0.03
The Network Fee is collected in CACAO and sent to the Protocol Reserve. If the transaction involves an asset which is not CACAO the user pays the Network Fee in the external asset. Then the equivalent is taken from that pool's CACAO supply and added to the Protocol Reserve.
If the transaction is in CACAO then the amount is directly taken in CACAO.
The CLP algorithm includes a slip-based fee which is liquidity-sensitive. Since demand for liquidity is defined as the size of the transaction over the depth of the market that will service it, then a fee which is proportional to liquidity solves key problems.
Firstly it has better value-capture when demand for liquidity is high, no matter the size of the transaction or the depth of the market. This means that over time, pool depths will settle to an equilibrium that is relative to the sizes of transactions that are passed over it. This solves the bootstrapping problem, because low-depth pools may turn out to be more profitable than high-depth pools to liquidity providers.
Secondly it has better access-control, since the more a trader (or attacker) demands liquidity, the more they have to pay for it. This makes sandwich attacks prohibitively expensive allowing pools to become reliable price feeds.
Additionally a slip-based fee is stateless and non-opinionated. The final fee paid is always commensurate to the demand of resources (both internal and external) no matter what it is.
This fee is retained on the output side of the pool, ensuring it counters the trade direction.
In an Asset-Asset swap, the fee is applied twice since two pools are involved, however the user only sees it as a single fee and a single slip value.
The third fee to discuss is the Network Fee. This is what users pay to make transactions on MAYAChain ledger itself. Currently, this is fixed and available on the /constants
endpoint, but it is intended to be dynamic and set to be a fixed $ qty of assets. Additionally, MAYAChain has custom gas logic where users pay fees in the asset they send, because all assets on MAYAChain have protocol pricing, either being CACAO, or synths, where synths are derived from the pools themselves.
Add Liquidity Through Custom Memos.
This guide should only be used by Advanced Users. It is highly recommended to use Maya UIs to transact. A mistake in any step CAN cause loss of funds.
For Symmetric Adds: ADD:POOL:PAIREDADDR
For Asymmetric Adds: ADD:POOL
For a full list of memo formats and abbreviations check this page.
Connect/Create your wallet.
Make sure your wallets are funded with ASSET & CACAO and they have to be of equal values.
Transfer an amount of ASSET, by substituting the format with actual values. Example:
ADD:BTC.BTC:yourMAYAaddress
Example: ADD:BTC.BTC:maya1nxjvgxqxe488jyl8wrmhm9ulsfthgp4rh5u5tw
or you can abreviate it to:
+:BTC.BTC:yourMAYAaddress
In the amount field, type the ASSET amount you wish to add (make sure you have enough amount left for fees).
Press send.
Check your transaction/Maya Address on MayaScan.
Transfer an equivalent amount (in value) of CACAO, by substituting the format with actual values. Example:
ADD:BTC.BTC:yourBTCaddress
Example: ADD:BTC.BTC:bc1p7tm6t2m6678cke92cw5r9gddpz4td80p45vu7v0v23604p6vd2us5jdtt2
or you can abreviate it to:
+:BTC.BTC:yourBTCaddress
In the amount field, type the CACAO amount you wish to add (make sure you have enough amount left for fees).
Press send.
Check your transaction/Maya Address on MayaScan.
Assymmetric Adds are made for convenience. Instead of swapping half of the Asset amount to CACAO, then adding liquidity, the chain does the swap part Automatically for you. Bear in mind, this will cause some limitations:
In the future, you will only be able to withdraw liquidity Asymmetrically, and the same side as well. So if you deposit BTC asymmetrically, you can only withdraw BTC asymmetrically.
Slippage. The chain will swap half of the Asset for you, which may cause unfavorable slippage fees, during deposit and withdrawal.
Connect/Create your wallet.
Make sure your wallets are funded.
Transfer an amount of ASSET/CACAO, by substituting the format with actual values. Example:
ADD:BTC.BTC
or you can abreviate it to:
+:BTC.BTC
You cannot use "+:MAYA.CACAO" memo.
In the amount field, type the amount you wish to add (make sure you have enough amount left for fees).
Press send.
Check your transaction/Maya Address on MayaScan.
Connect/Create your wallet.
Transfer an amount of ASSET, by substituting the format with actual values. Example:
ADD:BTC.BTC:yourMAYAaddress
Example: ADD:BTC.BTC:maya1nxjvgxqxe488jyl8wrmhm9ulsfthgp4rh5u5tw
or you can abreviate it to:
+:BTC.BTC:yourMAYAaddress
In the amount field, type the ASSET amount you wish to add (make sure you have enough amount left for fees).
In the address field paste ASSET Inbound Address on MAYAChain.
Make sure to refresh the page and NEVER use an old inbound address, as it they change every churn.
Press send.
Check your transaction/Maya Address on MayaScan.
The following steps need to be done through a Maya UI that supports MsgDeposit.
Transfer an equivalent amount (in value) of CACAO, by substituting the format with actual values. Example:
ADD:BTC.BTC:yourBTCaddress
Example: ADD:BTC.BTC:bc1p7tm6t2m6678cke92cw5r9gddpz4td80p45vu7v0v23604p6vd2us5jdtt2
or you can abreviate it to:
+:BTC.BTC:yourBTCaddress
In the amount field, type the CACAO amount you wish to add (make sure you have enough amount left for fees).
Press send.
Check your transaction/Maya Address on MayaScan.
Asymmetric Adds are made for convenience. Instead of swapping half of the Asset amount to CACAO, then adding liquidity, the chain does the swap part Automatically for you. Bear in mind, this will cause some limitations:
In the future, you will only be able to withdraw liquidity Asymmetrically, and the same side as well. So if you deposit BTC asymmetrically, you can only withdraw BTC asymmetrically.
Slippage. The chain will swap half of the Asset for you, which may cause unfavorable slippage fees, during deposit and withdrawal.
Connect/Create your wallet.
Transfer an amount of ASSET/CACAO, by substituting the format with actual values. Example:
ADD:BTC.BTC
or you can abreviate it to:
+:BTC.BTC
You cannot use "+:MAYA.CACAO" memo.
In the amount field, type the amount you wish to add (make sure you have enough amount left for fees).
In the address field paste ASSET Inbound Address on MAYAChain.
Make sure to refresh the page and NEVER use an old inbound address, as it they change every churn.
Press send.
Check your transaction/Maya Address on MayaScan.
Withdrawing Liquidity Using Custom Memos.
This guide should only be used by Advanced Users. It is highly recommended to use Maya UIs to transact. A mistake in any step CAN cause loss of funds.
For Symmetric Withdrawal: WD:POOL:BASISPOINTS
For Asymmetric Withdrawal: WD:POOL:BASISPOINTS:ASSET
Liquidity Withdrawal Rules:
If you deposited symmetrically, you can withdraw symmetrically, ASSET asymmetrically side, or CACAO asymmetrically.
If you deposited asymmetrically, you can ONLY withdraw the side you deposited (ASSET/CACAO) asymmetrically.
For a full list of memo formats and abbreviations check this page.
Connect/Create your wallet.
If you want to pay withdrawal fees in CACAO, do the transfer/memo from the CACAO side. If you want to pay withdrawal fees in ASSET, do the transfer/memo from the ASSET side. In all cases the memo will be the same. Example:
WD:BTC.BTC:10000
or you can abreviate it to:
-:BTC.BTC:10000
MAYAChain uses basis points for percentages. Example:
10000 = 100%
5000 = 50%
100 = 1%
In the amount field, type the minimum amount of ASSET/CACAO observed by nodes. The values are as follows:
CACAO (1e-10): 0.0000000001
BTC (10,001 sats): 0.00010001
ETH (1e-8): 0.00000001
RUNE (1e-8): 0.00000001
DASH (10,001 duffs): 0.00010001
KUJI (1e-6): 0.000001
Press send.
Check your transaction/Maya Address on MayaScan.
Connect wallet.
Transfer an amount of ASSET, by substituting the format with actual values. Example:
WD:BTC.BTC:10000:BTC.BTC
or you can abbreviate it to:
-:BTC.BTC:10000:BTC.BTC
MAYAChain uses basis points for percentages. Example:
10000 = 100%
5000 = 50%
100 = 1%
In the amount field, type the minimum amount of ASSET observed by nodes. The values are as follows:
BTC (10,001 sats): 0.00010001
ETH (1e-8): 0.00000001
RUNE (1e-8): 0.00000001
DASH (10,001 duffs): 0.00010001
KUJI (1e-6): 0.000001
Press send.
Check your transaction/Maya Address on MayaScan.
Connect wallet.
Transfer an amount of CACAO, by substituting the format with actual values. Example:
WD:BTC.BTC:10000:MAYA.CACAO
or you can abbreviate it to:
-:BTC.BTC:10000:MAYA.CACAO
MAYAChain uses basis points for percentages. Example:
10000 = 100%
5000 = 50%
100 = 1%
In the amount field, type the minimum amount of CACAO observed by nodes. The value is as follows:
CACAO (1e-10): 0.0000000001
Press send.
Check your transaction/Maya Address on MayaScan.
Connect/Create your wallet.
If you want to pay withdrawal fees in CACAO, do the transfer/memo from the CACAO side. If you want to pay withdrawal fees in ASSET, do the transfer/memo from the ASSET side. In all cases the memo will be the same. Example:
WD:BTC.BTC:10000
or you can abreviate it to:
-:BTC.BTC:10000
MAYAChain uses basis points for percentages. Example:
10000 = 100%
5000 = 50%
100 = 1%
In the amount field, type the minimum amount of ASSET/CACAO observed by nodes. The values are as follows:
CACAO (1e-10): 0.0000000001
BTC (10,001 sats): 0.00010001
ETH (1e-8): 0.00000001
RUNE (1e-8): 0.00000001
DASH (10,001 duffs): 0.00010001
KUJI (1e-6): 0.000001
In the address field paste ASSET Inbound Address on MAYAChain.
Make sure to refresh the page and NEVER use an old inbound address, as it they change every churn.
Press send.
Check your transaction/Maya Address on MayaScan.
Connect wallet.
Transfer an amount of ASSET, by substituting the format with actual values. Example:
WD:BTC.BTC:10000:BTC.BTC
or you can abbreviate it to:
-:BTC.BTC:10000:BTC.BTC
MAYAChain uses basis points for percentages. Example:
10000 = 100%
5000 = 50%
100 = 1%
In the amount field, type the minimum amount of ASSET observed by nodes. The values are as follows:
BTC (10,001 sats): 0.00010001
ETH (1e-8): 0.00000001
RUNE (1e-8): 0.00000001
DASH (10,001 duffs): 0.00010001
KUJI (1e-6): 0.000001
In the address field paste ASSET Inbound Address on MAYAChain.
Make sure to refresh the page and NEVER use an old inbound address, as it they change every churn.
Press send.
Check your transaction/Maya Address on MayaScan.
Connect wallet.
Transfer an amount of CACAO, by substituting the format with actual values. Example:
WD:BTC.BTC:10000:MAYA.CACAO
or you can abbreviate it to:
-:BTC.BTC:10000:MAYA.CACAO
MAYAChain uses basis points for percentages. Example:
10000 = 100%
5000 = 50%
100 = 1%
In the amount field, type the minimum amount of CACAO observed by nodes. The value is as follows:
CACAO (1e-10): 0.0000000001
In the address field paste ASSET Inbound Address on MAYAChain.
Make sure to refresh the page and NEVER use an old inbound address, as it they change every churn.
Press send.
Check your transaction/Maya Address on MayaScan.
What is Impermanent Loss Protection (ILP) and how does it work?
Impermanent Loss refers to the temporary loss that liquidity providers (LPs) may experience when providing liquidity to decentralized exchanges (DEXs). It arises due to the constant fluctuations in the prices of crypto assets. MAYAChain aims to address impermanent loss through its Impermanent Loss Protection mechanism.
Impermanent Loss Protection is funded from the Maya Protocol Reserve, which is 10% of CACAO supply (10m CACAO). Refilled constantly and automatically with 10% of the protocol fees (transaction & swap fees).
ILP on Maya starts on the 50th day after depositing liquidity, and coverage is capped at 100%.
If ASSET outperforms CACAO, full coverage is after 150 days (50 days after initial deposit + 100 days in LP).
If CACAO outperforms ASSET, full coverage is after 450 days (50 days after initial deposit + 400 days in LP).
ILP is calculated at the time the user withdraws liquidity.
If the ASSET outperforms CACAO, the ILP is 1% daily. So, if the user withdrew after 150 days, they would get 100% protection. If the user withdrew after 100 days, they would get 50% protection.
If CACAO outperforms the ASSET, the ILP is 0.25% daily. So, if the user withdrew after 450 days, they would get 100% protection. If the user withdrew after 250 days, they would get 50% protection.
If fees cover the Impermanent Loss, the LP isn’t eligible for ILP.
ILP is paid and reset after full withdrawal, not affected by partial withdrawals, and only reset but not paid on top-ups.
ILP is always recorded and calculated symmetrically (ASSET-CACAO). So even if you deposited asymmetrically (single asset), the deposit values are NOT the amounts the user deposited. They are the immediate symmetrical (ASSET-CACAO) value of what the user deposited.
Calculate the amount to cover in CACAO.
Calculate the percentage of coverage.
Step 1: Calculate the amount to cover in CACAO.
Where:
A0 = Initial ASSET amount deposited.
A1 = ASSET amount to be redeemed upon withdrawal.
R0 = Initial CACAO amount deposited.
R1 = CACAO amount to be redeemed upon withdrawal.
P1 = LP ratio of the pool upon withdrawal.
Amount to cover in CACAO = ((A0*P1)+R0) – ((A1*P1)+R1)
Example:
Assuming the ASSET is USDT and the LP initial amounts were (100 USDT + 1,000 CACAO), and (80 USDT + 1100 CACAO) at withdrawal, and the LP ratio of the pool is 1% (0.01).
((100*0.01)+1000) – ((80*0.01)+1100) = 1001 – 1100.8 = -99.8 CACAO
Step 2: Calculate the percentage of coverage.
First we need to determine if CACAO was outperforming (400, after 50, days to full coverage) or underperforming (100, after 50, days to full coverage).
In the above case CACAO has been underperforming. So 100 days to full coverage.
As a rule of thumb, if you deposit 2 assets, and at withdrawal you got more of an asset and less of the other compared to the initial deposit, the asset you got more of, is the asset underperforming. Think of it like this; people were giving away the less desirable asset and taking more of the other.
Now we need to calculate the length of time liquidity has been deposited, to determine percentage of coverage.
Blockchains don’t have clocks, but they have blocks, and we can derive the time from the number of blocks per second. In Maya’s case it’s around 6 seconds per block, or 14,400 a day.
So,
Percentage of coverage = (block no. at withdrawal – block no. at deposit - 50 days of blocks)/ (number of blocks a day * number of days to full coverage)
Example:
Block no. at withdrawal = 2,456,000.
Block no. at deposit = 900,000.
Percentage of coverage = (2,456,000 – 900,000 -(14,400 * 50))/ (14,400 *100) = 0.58 or 58%.
This means that LP will be protected with (99.8 CACA0 * 0.58) = 57.88 CACAO.
MAYAChain's Incentive Pendulum keeps the network in a balanced state.
The capital on MAYAChain can lose its balance over time. Sometimes there will be too much capital in liquidity pools; sometimes there will be too much bonded by nodes. If there is too much capital in liquidity pools, the network is unsafe. If there is too much capital bonded by nodes, the network is inefficient.
If the network becomes unsafe, it increases rewards (block rewards and liquidity fees) for node operators and reduces rewards for liquidity providers. If the network becomes inefficient, it boosts rewards for liquidity providers and reduces rewards for node operators.
MAYAChain can be in 1 of 5 main states—
Unsafe
Under-Bonded
Optimal
Over-Bonded
Inefficient
These different states can be seen in the relationship between bonded Cacao and pooled Cacao. The amount of Cacao which has been bonded by node operators, and the amount which has been added to liquidity pools by liquidity providers.
In the optimal state, bonded LP is roughly 85% of the liquidity, with the remaining being simply pooled LP. Both Bonded and Pooled LP is 50% Cacao and 50% assets. This is the desired state. The system makes no changes to the incentives for node operators or liquidity providers.
The system may become unsafe. In this case, pooled capital is more than 1/4 bonded capital, a 75-25 split.
This is undesirable because it means that it's become profitable for node operators to work together to steal assets.
To fix this, the system increases the amount of rewards going to node operators and lowers the rewards going to liquidity providers. This leads to more node operators getting involved, bonding more LP and increasing bonded capital. This also disincentivises liquidity providers from taking part. They receive less return on their investment, so they pull assets out and reduce the amount of pooled capital. With time, this restores balance and the system moves back towards the optimal state.
In Maya, the system can never become inefficient, since all of the capital is always at work in LP. Still, the network wishes to incentivize fresh liquidity to leverage the protocol and increase the flywheel effect of liquidity.
To do this this, the system increases rewards for liquidity providers and decreases rewards for node operators. This attracts more liquidity providers to the system. Liquidity providers add more capital to receive more rewards, increasing pooled capital.
Bonded capital falls as a percentage of total liquidity. In this way, the system returns to the optimal state.
The under- and over-bonded states are less severe intermediary states. Being under-bonded is not a threat in itself because it is not yet profitable for node operators to steal. Being over-bonded is not a problem in itself because the system is still operating quite well.
The MAYAChain team does not expect the unsafe or inefficient states to come up often. The system will be near the optimal state most of the time, particularly as it gets easier for people to run node.
You can read more about this in our Whitepaper, in the section about Liquidity Nodes.
An overview of MAYAChain's 1-way State Pegs, State Machine and TSS Protocol.
MAYAChain is a leaderless vault manager:
1-way State Pegs allow syncing state from external chains.
A State Machine to coordinate asset exchange logic and delegate outgoing transactions.
Bifröst Chain Client to processs chain-specific transactions.
A TSS protocol to enable distributed threshold key-signing.
Each node has a "Bifröst" service that deals with the nuances of connecting to each chain. Once nodes are synced, they watch vault addresses. If they ever see an inbound transaction, they read it and convert it into a MAYAChain witness transaction.
The witness transaction has the following parameters that are essentially the same for each chain, no matter the type:
MAYAChain processes each observed transaction and waits for consensus. Once a super-majority of nodes agree on a particular transaction, it moves from a pending
state to a finalised state.
Each chain client is quite light-weight, containing only as much logic as is necessary to connect to that particular chain. Most of the logic is in the observer itself.
The state machine processes the finalised transaction and performs logic, such as ordering transactions, computing state changes, and delegating them to a particular outbound vault. Finally, a txOut
item is created and stored in the Key-Value store.
The txOut
looks like the following:
The Transaction Out item details which chain it should be sent on, the destination address, the vault it should be sent from, and the maximum gas that should be spent. It also has fields for the transaction that initiated it (the InHash
) and the transaction that will complete the accounting (the OutHash
).
Once the finalised transaction is created, the Signer loads it from their local copy and serialises it into a correct transaction for the destination chain using the respective chain client. This is then sent to the TSS module which coordinates key-signing. The final signed transaction is then broadcast to the respective chain.
There are two types of vaults in MAYAChain's system - "inbound vaults" and "outbound vaults":
Asgard TSS Vaults - inbound vaults with large committees (27-of-40)
This allows the system to use the security of the large vaults to hold the bulk of assets, but delegate to the small, fast outbound vaults the outgoing assets. Every MAYANode runs an outbound vault.
In order to further increase the node count to beyond 40 nodes, the system shards Asgard vaults into two when it approaches the MaxNodesForAsgard
constant (and merges them if two ever drop below half of this). As such, with 100 nodes, there would be 3 Asgard vaults, with 100 yggdrasil vaults. The system constantly checks which vault has the highest excess security, and instructs users to send funds there.
When the network churns, it creates new public keys and migrates the funds forward. The churning process is split up in 5 different transactions, 1 per asset (identified by migrate
memo). It typically takes a few hours to complete. Users are instructed to only send funds to the newest vault, but the retiring vault is monitored. Once the last of the 5 migrations is complete, the previous vault is discarded and no longer monitored.
The previous vault cannot be monitored forever since it can not be guaranteed that all nodes in that vault are still online, and it becomes an attack vector to keep old vaults "around".
If you send funds to a retired vault (likely by caching the address) your funds will be forever lost and is impossible to be recovered.
The Liquidity Nodes model has been designed to address an issue present in many blockchains. To guarantee network security, Nodes are mandated to purchase and stake/bond a predetermined amount of the network's native asset. This serves as a security precaution, as any misbehaving Nodes will be subject to slashing, resulting in the forfeiture of their stake.
These staked/ bonded funds stay idle, with the rewards being subsidized by inflation. While certain networks attempt to counter the inflation through the implementation of burn mechanisms, MAYAChain has proposed an entirely novel approach.
MAYAChain Nodes bond Liquidity Pairs instead of idle funds, which offers three distinct advantages: security, real yield, and capital efficiency.
Security: the slashing mechanism remains in effect, ensuring that any misbehaving Nodes will have their Liquidity Pairs slashed.
Real Yield: there is no need for inflationary rewards; Nodes can earn fees from swaps and transactions.
Capital Efficiency: the funds used to secure the network are now productive, rather than idle.
The security of MAYAChain is of paramount importance, and our nodes must be held accountable to ensure the integrity of our system. To this end, more than 75% of capital should be bonded by our nodes to guarantee trustworthiness. Ideally, the percentage should be closer to 87% to ensure that any potential Sybil attack yields a loss.
To achieve this, Liquidity Providers need to be incentivized to bond their liquidity to MAYANodes. MAYAChain utilizes economic incentives through the redistribution of yield.
In MAYAChain, fees earned from swaps and transactions are divided into two types of rewards:
Node Exclusive Rewards (NER): Rewards that are only given to Liquidity Bonded to MAYANodes. They are distributed evenly among all Nodes.
Liquidity Pool Rewards (LR): Distributed to all LPs, including Bonded Liquidity, based on their share of liquidity.
In other words, LR is earned by ALL liquidity provided to MAYAChain (bonded or not), and the NER is only provided to those who Bond their Liquidity.
While Liquidity Bonded to MAYANodes earn NER, Node operators set a fee for providing their services.
But what determines the ratios in which these rewards are divided?
As you'd expect, the ratios of Bonded to Unbonded Liquidity will be in constant fluctuation. The incentive Pendulum is the mechanism that algorithmically and periodically rebalances the rewards/fees received by Bonded Liquidity relative to Unbonded Liquidity, according to the network's security needs.
For example, if Bonded Liquidity falls below 75% of total liquidity (unsafe zone) the Incentive Pendulum starts giving 100% of the rewards/fees to the Liquidity Bonded in MAYANodes, and 0% to the Unbonded Liquidity. This incentivizes Unbonded LPs to bond in order to earn Yield.
And, if 100% of Liquidity bonded, users will be incentivized to provide liquidity, as they can earn yield without having to bond to a Node.
In the Liquidity Node model, Nodes don't have to choose between Node rewards or Liquidity Rewards, as they can earn both. They also have less risk to bond, as even if they fail to churn-in and be in a standby state, as they will still be earning Liquidity rewards. It also creates deeper pools while still maintaining the network security.
Liquidity Nodes earning both NER and LR means more yield, more yield attracts more liquidity, more liquidity reduces swap fees, less swap fees bring more trade volume, and more trade volume means more yield. A liquidity flywheel.
The Exact calculations and yield distribution are as follows:
The calibrations of the economics and incentives that manage the system are algorithmic and code-driven. When the total network's liquidity is disproportionate in either direction (excessive Bonded Liquidity versus excessive Unbonded Liquidity), the incentive mechanism responds by adjusting the rewards accordingly. Below is a visual representation.
Whenever a node is slashed, MAYAChain still benefits if their liquidity remains in the pools. It is also possible that the slashing was done in error, so that must be taken into account as well, and only execute the slashing if the Node withdraws its liquidity.
Slashed funds are transferred to the Protocol Owned Liquidity, and if the slashing is forgiven, it is given back. The forgiving of slashing can be done manually or automatically.
It is no longer the case that Capital Efficiency is inversely proportional to Network Security. Both can be achieved.
All of the TVL is invested in pools and is actively traded, thus making MAYAChain significantly more efficient in terms of capital utilization.
An increase in capital efficiency increases the average yield for all the ecosystem participants, which attracts liquidity, making swap fees cheaper, bringing in more volume, and creates a liquidity flywheel.
Nodes with lower bonds yield higher returns per dollar invested than Nodes with higher bonds, discouraging too much Liquidity to be bonded to any single Node, ensuring decentralization and bond homogenization.
As more Nodes compete to churn-in, they contribute to an increase in liquidity. This increased liquidity lowers the Incentive Curve (increasing NER), making it increasingly attractive to become a victorious Node.
As the incentive curve system pulls in any direction, Pool Depth increases.
Node to LP and LP to Node latency is reduced and very easy to do for Operators without incurring slip fees.
Standby Nodes earn yield while they wait to win the Bond War and churn in, making it less risky to compete.
Nodes no longer need 100% exposure to CACAO.
Node misbehavior causes the slashing of a Node’s LP units that are converted into Protocol Owned LP Units that count towards unbonded liquidity. These Protocol Owned LP units will never exit, staying as a buyer of last resort.
Providing liquidity to MAYAChain liquidity pools.
Liquidity providers provide assets to the MAYAChain liquidity pools. They are compensated with swap fees and system rewards. Compensation is affected by a number of factors related to the pool and the state of the network.
Liquidity providers commit capital to pools which have exposure to underlying assets, thus liquidity providers gain exposure to those assets, which have free-floating market prices.
While they are paid block rewards and liquidity fees, these are dynamic and may not be enough to cover "Impermanent Losses", which occur when price changes happen.
Liquidity providers should not consider they are entitled to receive a specific quantity of their assets back when they deposit, rather that they will receive their fair share of the pool's earnings and final asset balances.
Liquidity providers deposit their assets in liquidity pools and earn yield in return. They earn tokens in Cacao and the pool's connected asset. For example, someone who has deposited in the BTC/CACAO pool will receive rewards in BTC and CACAO.
Yield is calculated for liquidity providers every block. Yield is paid out to liquidity providers when they remove assets from the pool.
Rewards are calculated according to whether or not the block contains any swap transactions. If the block contains swap transactions then the amount of fees collected per pool sets the amount of rewards. If the block doesn't contain trades then the amount of assets in the pool determines the rewards.
How a block with fees splits the reward. In this example, 1000 CACAO is being divided as rewards:
Pool Depth (CACAO)
Fees
Share (of Fees)
Rewards
1,000,000
1000
33%
333
2,000,000
0
0%
0
3,000,000
2000
67%
667
6,000,000
3000
100%
1000
How a block with no fees splits the rewards. In this example, 1000 CACAO is being divided:
Pool Depth (CACAO)
Fees
Share (of Depth)
Rewards
1,000,000
0
17%
167
2,000,000
0
33%
333
3,000,000
0
50%
500
6,000,000
0
100%
1000
This ensures that yield is being sent to where demand is being experienced - with fees being the proxy. Since fees are proportional to slip, it means the increase in rewards ensure that pools experiencing a lot of slip are being incentivised and will attract more liquidity.
Ownership % of Pool – Liquidity providers who own more of a pool receive more of that pool's rewards.
Swap Volume – Higher swap volumes lead to higher fees. Higher fees lead to higher rewards for liquidity providers.
Size of Swaps – Swappers who are in a hurry to exchange assets will tend to make larger swaps. Larger swaps lead to greater price slips and therefore higher fees.
Incentive Pendulum – The Incentive Pendulum balances the amount of capital bonded in the network versus pooled. It does this by changing the amount of rewards given to node operators versus liquidity providers. Sometimes rewards will be higher for liquidity providers to encourage them to deposit assets; sometimes the opposite. Learn more.
Change in Asset Prices -- If the price of the assets change, then liquidity providers will receive more of one and less of the other. This may change yield if yield is being priced in a third asset, ie, USD.
Depositing assets on MAYAChain is permissionless and non-custodial.
Liquidity providers can propose new asset pools or add liquidity to existing pools. Anybody can propose a new asset by depositing it. See asset listing/delisting for details. Once a new asset pool is listed, anybody can add liquidity to it. In this sense, MAYAChain is permissionless.
The ability to use and withdraw assets is completely non-custodial. Only the original depositor has the ability to withdraw them. Nodes are bound by rules of the network and cannot take control of user-deposited assets.
Liquidity can be added to existing pools to increase depth and attract swappers. The deeper the liquidity, the lower the fee. However, deep pools generally have higher swap volume which generates more fee revenue.
Liquidity providers are incentivised to deposit symmetrically but should deposit asymmetrically if the pool is already imbalanced.
Symmetrical vs Asymmetrical Deposits
Symmetrical deposits is where users deposit an equal value of 2 assets to a pool. For example, a user deposits $1000 of BTC and $1000 of CACAO to the BTC/CACAO pool.
Asymmetrical deposits is where users deposit unequal values of 2 assets to a pool. For example, a user deposits $2000 of BTC and $0 of CACAO to the BTC/CACAO pool. Under the hood, the member is given an ownership of the pool that takes into account the slip created in the price. The liquidity provider will end up with <$1000 in BTC and <$1000 in CACAO. The deeper the pool, the closer to a total of $2000 the member will own.
Note: there is no difference between swapping into symmetrical shares, then depositing that, or depositing asymmetrically and being arb'd to be symmetrical. You will still experience the same net slip.
To deposit assets/ liquidity on MAYAChain, you need:
A compatible wallet with your assets.
Connect to one of Maya Protocol's User Interfaces (El Dorado or ThorWallet).
Currently you can add liquidity using ThorWallet UI. Or, through El Dorado using Memos.
Add liquidity to any of the active or pending pools. There is no minimum deposit amount, however, your deposit will have to cover the deposit and later a withdrawal fee costs.
The ability to manage and withdraw assets is completely non-custodial and does not require any KYC or permission process. Only the original depositor has the ability to withdraw them (based on the address used to deposit the assets).
Every time you add liquidity, Impermanent Loss Protection time resets.
While Symmetrical additions are recommended, Asymmetrical additions are supported, below are the rules:
If you add symmetrically (%50 Asset - %50 CACAO) first;
You will be able to add liquidity asymmetrically with CACAO later
You will be able to add liquidity asymmetrically with ASSET later but it would create a new LP position
You will be able to add liquidity symmetrically later
If you add asymmetrically (%100 ASSET) first;
You will be able to add liquidity asymmetrically with CACAO later but it would create a new LP position
You will be able to add liquidity asymmetrically with ASSET later
You will be able to add liquidity symmetrically later but it would create a new LP position
If you add asymmetrically (%100 CACAO) first:
You will be able to add liquidity asymmetrically with CACAO later
You will be able to add liquidity asymmetrically with ASSET later but it would create a new LP position
You will not be able to add liquidity symmetrically later
Liquidity providers can withdraw their assets anytime; with the only waiting period being the confirmation time. The network processes the request and the provider receives their % of the pool and earned assets. Fees apply upon withdrawal, are placed into the network reserve.
There are 3 factors affecting returns/ yield:
Transaction volume & pool depth: if the volume of the pool is high in comparison to its depth, then liquidity providers will be presented with higher rewards. Conversely, if the volume of the pool is low in comparison to its depth, then liquidity providers will be presented with lower rewards.
Share of the pool: the higher the individual's share of a pool, the higher the returns they're granted. For instance, if a liquidity provider holds a %1 stake in a pool, they will receive %1 of the rewards for that pool.
Fee size: the fees associated with a given blockchain are determined by the blockchain itself, and the rewards received by liquidity providers are directly proportional to the fees charged. As such, a blockchain with higher fees will result in higher rewards for liquidity providers.
Supplying liquidity into the protocol presents an opportunity for holders of non-yield generating assets (e.g. BTC ) to obtain a return on their investments.
Liquidity providers earn a yield on the assets they deposit. This yield is made up of fees and rewards.
Fees are paid by swappers and traders. Most swaps cause the ratio of assets in the liquidity pool to diverge from the market rate.
The ratio of assets in a liquidity pool is comparable to an exchange rate.
This change to the ratio of assets is called a 'slip'. A proportion of each slip is kept in the pool. This is allocated to liquidity providers and forms part of their staking yield. Learn more about swapping.
Rewards come from MAYAChain's own reward emissions. Reward emissions follow a predetermined schedule of release.
Rewards also come from a large token reserve. This token reserve is continuously filled up from network fees. Part of the token reserve is paid out to liquidity providers over the long-term. This provides continuous income even during times of low exchange volume.
Learn about how factors affecting yield and how yield is calculated.
See here for an interactive example of the staking process.
Passive liquidity providers should seek out pools with deep liquidity to minimise risk and maximise returns.
Active liquidity providers can maximise returns by seeking out pools with shallow liquidity but high demand. This demand will cause greater slips and higher fees for liquidity providers.
Liquidity providers must have assets to deposit and their assets must be native to a supported chain. There is no minimum amount to deposit in existing pools. However new assets must win a competition to be listed – larger value deposits will be listed over smaller value deposits.
Liquidity providers must pay for security of their assets, since security is not free. This "payment" is the requirement for liquidity providers to hold CACAO, which acts as a redeemable insurance policy whilst they are in the pool. Holding CACAO allows liquidity providers to retain an ability to economically leverage nodes to ensure security of assets. When the liquidity provider withdraws, they can sell their CACAO back to the asset they desire. H
The only direct cost to liquidity providers is the network fee, charged for withdrawing assets (pays for the compute resources and gas costs in order to process outbound transactions). An indirect cost to liquidity providers comes in the form of impermanent loss. Impermanent loss is common to Constant Function Market Makers like MAYAChain. It leads to potential loss of liquidity provider purchasing power as a result of price slippage in pools. However, this is minimised by MAYAChain's slip-based fee.
Liquidity providers are not subject to any direct penalties for misconduct.
The yield of a pool on MAYAChain is calculated using a metric called Liquidity Unit Value Index (LUVI) which can be viewed on Midgard.
When a user deposits assets into a liquidity pool, they are given ownership of Liquidity Units which represent a percentage of ownership of the pool. LUVI is a measure of the relative value of each liquidity unit and is independent of price.
Where:
Learn more about Liquidity Units and Synth Units
The yield of a pool uses LUVI value data from the previous 30 days and extrapolates an APR if that performance is repeated over the course of a year. A period
parameter may be used to change the number of days of data that are taken into consideration.
Example: https://midgard.mayachain.info/v2/pools?period=100d calculates the APR of a pool with the previous 100 days of data rather than the default of 30 days.
Factors that affect LUVI:
Swap fees, block rewards, and pool donations increase LUVI and are the primary yield sources
An increase of the synthetic asset liability of a pool decreases LUVI
An increase in ASSET Depth
or CACAO Depth
of a pool increase LUVI
Changes in the ratio of ASSET Depth
and CACAO Depth
in a pool change LUVI
Changes in ASSET Price
or CACAO Price
do not necessarily change LUVI
Constants and Mimir Settings Defined.
Mimir setting can be created and changed without a corresponding Constant.
Values
Key:
No Star or Hash - Constant only, no Mimir override.
Star (*) indicates a Mimir override of a Constant
Hash (#) indicates Mimir with no Constant.
OutboundTransactionFee
: Amount of cacao to withhold on all outbound transactions (1e8 notation)
MaxTxOutOffset
: Max number of blocks a scheduled outbound transaction can be delayed
MinTxOutVolumeThreshold
: Quantity of outbound value (in 1e8 cacao) in a block before its considered "full" and additional value is pushed into the next block
TxOutDelayMax
: Maximum number of blocks a scheduled transaction can be delayed
TxOutDelayRate
: Rate of which scheduled transactions are delayed
HaltTrading
: Pause all trading
Halt<chain>Trading
: Pause trading on a specific chain
MaxSwapsPerBlock
: Artificial limit on the number of swaps that a single block with process
MinSwapsPerBlock
: Process all swaps if the queue is equal to or smaller than this number
MaxSynthPerAssetDepth
: The amount of synths allowed per pool relative to the pool depth
BurnSynths
#: Enable/Disable burning synths
MintSynths
*: Enable/Disable minting synths
VirtualMultSynths
: The amount of increase the pool depths for calculating swap fees of synths
PauseLP
*: Pauses the ability for LPs to add/remove liquidity
PauseLP<chain>
*: Pauses the ability for LPs to add/remove liquidity, per chain
MaximumLiquidityCacao
*: Max cacao capped on the pools known as the ‘soft cap’
LiquidityLockUpBlocks
: The number of blocks LP can withdraw after their liquidity
FullImpLossProtectionBlocks
*: Number of blocks before an LP gets full imp loss protection
ILP-DISABLED-<asset>
*: Enable/Disable imp loss protection per asset
HaltChainGlobal
*: Pause observations on all chains (chain clients)
HaltTrading
: Stops swaps and additions, if done, will result in refunds. Observations still occur.
Halt<chain>Chain
*: Pause a specific blockchain
Halt<chain>Chain
*: Pause a specific blockchain
NodePauseChainGlobal
: Individual node controlled means to pause all chains
NodePauseChainBlocks
: Number of block a node operator can pause/resume the chains for
BlocksPerYear
: Blocks in a year
MaxUTXOsToSpend
*: Max UTXOs to be spent in one block
MinimumNodesForBFT
: Minimum node count to keep the network running. Below this, Ragnarök is performed.
NativeTransactionFee
: Cacao fee on all on chain txs
TNSRegisterFee
: Registration fee for new MAYAName, in cacao
TNSFeeOnSale
: fee for TNS sale in basis points
TNSFeePerBlock
: per block cost for TNS, in cacao
StopSolvencyCheck
#: Enable/Disable Solvency Checker
StopSolvencyCheck<chain>
#: Enable/Disable Solvency Checker, per chain
PermittedSolvencyGap
: The amount of funds permitted to be "insolvent". This gives the network a little bit of "wiggle room" for margin of error
MaximumBondInCacao
: Sets an upper cap on how much a node can bond
MinimumBondInCacao
*: Sets a lower bound on bond for a node to be considered to be churned in
ValidatorMaxRewardRatio
*: the ratio to MinimumBondInCacao at which validators stop receiving rewards proportional to their bond
YggFundLimit
: Funding limit for yggdrasil vaults (percentage)
YggFundRetry
*: Number of blocks to wait before attempting to fund a yggdrasil again
StopFundYggdrasil
#: Enable/Disable yggdrasil funding
ObservationDelayFlexibility
*: Number of blocks of flexibility for a validator to get their slash points taken off for making an observation
PoolDepthForYggFundingMin
*: the minimum pool depth in CACAO required for ygg funding
MinimumNodesForYggdrasil
: No yggdrasil pools if MAYANode have less than 6 active nodes
LackOfObservationPenalty
: Add two slash points for each block where a node does not observe
SigningTransactionPeriod
: How many blocks before a request to sign a tx by yggdrasil pool, is counted as delinquent.
DoubleSignMaxAge
: Number of blocks to limit double signing a block
FailKeygenSlashPoints
: Slash for 720 blocks, which equals 1 hour
FailKeysignSlashPoints
: Slash for 2 blocks
ObserveSlashPoints
: the number of slashpoints for making an observation (redeems later if observation reaches consensus
ObservationDelayFlexibility
: number of blocks of flexibility for a validator to get their slash points taken off for making an observation
JailTimeKeygen
: blocks a node account is jailed for failing to keygen. DO NOT drop below TSS timeout
JailTimeKeysign
: blocks a node account is jailed for failing to keysign. DO NOT drop below TSS timeout
AsgardSize
: Defines the number of members to an Asgard vault
MinSlashPointsForBadValidator
: Min quantity of slash points needed to be considered "bad" and be marked for churn out
BondLockupPeriod
: Lockout period that a node must wait before being allowed to unbond
ChurnInterval
*: Number of blocks between each churn
HaltChurning
: Pause churning
DesiredValidatorSet
: Max number of validators
FundMigrationInterval
*: Number of blocks between attempts to migrate funds between asgard vaults during a migration
NumberOfNewNodesPerChurn
#: Number of targeted additional nodes added to the validator set each churn
BadValidatorRedline
*: Redline multiplier to find a multitude of bad actors
BadValidatorRate
: Rate to mark a validator to be rotated out for bad behavior
OldValidatorRate
: Rate to mark a validator to be rotated out for age
LowBondValidatorRate
: Rate to mark a validator to be rotated out for low bond
EmissionCurve
*: How quickly cacao is emitted from the reserve in block rewards
IncentiveCurve
*: The split between nodes and LPs while the balance is optimal
MaxAvailablePools
: Maximum number of pools allowed on the network. Gas pools (native pools) are excluded from this.
MinCacaoPoolDepth
*: Minimum number of cacao to be considered to become active
PoolCycle
*: Number of blocks the network will churn the pools (add/remove new available pools)
StagedPoolCost
: Number of cacao (1e8 notation) that a stage pool is deducted on each pool cycle.
MAYAChain governance is deliberately minimal. It decides which chains and assets are listed, and when the protocol gets upgraded.
MAYAChain aims to have as little governance baked into the system as possible. This is done so that nodes don't communicate or learn who one another are. This is important for security because it makes sure that nodes don't act together to take control.
MAYAChain governance decides:
which assets are listed/delisted
which chains are listed/delisted
when the protocol gets upgraded
the economic limit – how many nodes can participate
Users signal which assets they want on the network by staking in a new pool. MAYAChain will realise it is a new asset it hasn't been seen before and create a new pool and place it in bootstrap mode. This is a normal asset pool except swapping is disabled on it. Every few days the networks looks at all the bootstrapping pools and lists the one with the highest value.
Assets are delisted when all liquidity providers have taken all their assets out of it, or its pool depth drops too low. The logic is:
When a new bootstrap pool is enabled, its depth is compared with the depth of the smallest active pools.
If it is deeper, the smallest active pool is placed back into bootstrap mode, and the new pool replaces it.
The process is repeated to re-list an asset.
When the community wants to support a new chain
MAYAChain developer community decides whether or not to approve it
If approved, the code gets tested and validated by core developers
If accepted, it gets added to MAYANode software
Nodes upgrade their software as they are cycled off and back onto the network
When 67% of nodes are running the new software, the new chain is connected
To delist, nodes stop watching a chain. When 67% are no longer watching, it gets removed. A process begins and the assets of that chain are returned to their owners.
Developers from the community submit MAYAChain Improvement Proposals (TIPs) to improve the network. The community discusses, tests and validates the software. If they decide that the change is beneficial, it's merged into the MAYANode software.
The protocol is made up of 3 main pieces, run by the nodes:
application logic – runs the blockchain
schema – stores key values of vaults
network software – keeps the TSS protocol key generation and signing
When nodes are churned off the network they can choose to update their software version. Over time more and more nodes will run the latest version. When 67% of nodes are running the new software, the network is automatically updated. This is how application logic, chain connections and schema are updated.
When upgrading the network software, a certain block number in the future is set when the upgrade will happen. When the network reaches that point, the whole chain stops running and a genesis import to a new network occurs and operations continue normally.
Emergency changes are difficult to coordinate because nodes cannot communicate. To handle an emergency, nodes should leave the system. When the number of nodes falls below 4, funds are paid out and the system can be shut-down. This process is called Ragnarök.
There are only so many nodes who can participate on the network. This is because there's a minimum bond amount and a fixed supply of Cacao. If the system is ever found to be always under-bonded or over-bonded, the minimum bond limit can be changed.
Mimir is a feature to allow changes in the constants of the chain, such as MinimumBond, ChurnSpeed and more.
There are two types of mimir
Node Mimir: set by each node. Once 2.3rds have set a mimir, it is enacted. Only active nodes have their votes counted
Admin Mimir: set by admins to over-ride constants during testing. Admin-mimir can't control funds, but it can set parameters. Ultimately admin-mimir will be removed.
Dynamic Inflation is a feature that can be enabled/disabled by nodes voting on it. It is NOT the original state of the chain.
Maya Protocol is a multichain DEX, with CACAO as its native token. The utility of CACAO lies in its ability to facilitate swaps and trades between different assets (BTC, ETH, Dash, etc...). For this to be possible, CACAO needs to be paired with other assets in Liquidity Pools (LP).
Although Liquidity Pools provide yield, they are subject to Impermanent Loss (IL). This is why some users prefer to hold CACAO on its own, rather than in a LP, even though it is more beneficial for the protocol if these funds are present as liquidity.
Dynamic inflation is an autoregulated mechanism designed to favor Liquidity Providers (LPers) over holders/ speculators. If the amount of CACAO held outside LPs exceeds 10% of the non-reserve supply, Dynamic Inflation is activated in order to protect the Liquidity Providers and reduce the value of CACAO held outside LPs.
This is achieved by injecting CACAO directly into pools and Maya Protocol’s system income (which is distributed to LPs, MAYA, and nodes as yield).
Inflation will continue (inflation increases as CACAO held increases) until balance is restored in the system, and the amount of CACAO held outside LPs is 10% or less of the non-reserve supply.
The equation is as follows:
y = CACAO in pools/ CACAO total supply *100
If y < %90, Dynamic inflation kicks in.
Rate of inflation = (1-y) * 40% + 1%
Here’s an example table: -
Dynamic Inflation is a feature that can be enabled/disabled by nodes voting on it. It is NOT the original state of the chain.
Describes the different security elements within MAYAChain
Note, MAYAChain and Binance Beacon Chain have near-instant finality so confirmation counting is not required.
To prevent large amounts of funds from leaving the network in an instant, large outbound transactions are throttled from immediately leaving the network. Each block has an outbound value limit **** (currently 1000 CACAO worth) and each outbound transaction has a maximum time limit that it can be processed. This has three effects:
Each outbound transaction to compete for the next outbound block, else, it will be processed in the following block, effectively throttling the total outbound capacity of the network. This is independent of conf-counting.
Large outbounds to spread across multiple blocks, up to 720 blocks (approx one hour).
Ensures one large outbound request of $1,000,000 is handled the same as one million $1 outbound requests.
This serves as a defensive layer buying time and allowing a vigilant node operator to pause trading or automatically halt checks to engage before the large malicious outbound transaction is irreversibly executed and funds are lost. While the feature negatively impacts the user experience of MAYAChain, but is necessary in ensuring the protection of liquidity provider funds.
The feature is designed to grow as the network grows and is controlled by several Mimir values that can be changed by Node Operators as required. Additionally, the feature is designed to promote bug disclosure instead of directly attacking the network as a bug disclosure is likely more profitable.
MAYAChain has different levels of halt controls within the network which are controlled by Mimir values or by nodes, depending on the type and level.
The halts that can affect an individual **** chain are:
Halt Signing- outbounds que
Halt LP - add/remove stopped, swapping allowed.
Halt Trading - no trading allows
Halt Chain - nodes stop observing that chain
There are also network level halts
Trading halt
The solvency checker of the network’s primary vault was introduced to catch issues early or prevent them before they happened. Detected issues can trigger an automatic trading halt on a specific chain. There are two types of automatic solvency checks:
Reactive: The network continually compares the assets the network believes it has in its primary vault (Asgard Vault) to what assets are actually stored in the network’s chain wallets. For every connected chain, each node compares the stored Asgard vault value to each chain Asgard Wallet amount. If the Asgard Vault value is more than the wallet value by 1%, the node reports insolvency for that chain.
Proactive: This mode is more powerful and is intended to catch insolvencies even before they appear. When a node attempts to sign a txOut, it will do a calculation to check if by executing the txOut the vault becomes insolvent. If so, then it refuses to sign and reports insolvency.
Automatic Trading Halting
If more than 66% of nodes, report an insolvency with a chain (reactive or proactive), trading for all assets on that chain is automatically halted (Halt{Chain}Trading). The halt will also emit a security event to ThorSec.
Why 1% difference allowance?
MAYAChain builds an awareness of balances purely by adding the incoming funds, then subtracting the outgoings. Thus the expected balance is the aggregate of the ins and outs. Divergences can occur when actual on-chain balances start to diverge. For gas assets (assets used to pay gas), small divergences can be intermittent, but normally less than +/- 1%.
Secondary Vault Security
Yggdrasil Vaults, the secondary vaults that hold approx 25% of the network funds, are secured by the Node Operators’ bonds and the threat of their bond being slashed 1.5x of any funds they mishandle (e.g steal or attempt to double spend).
Node Operators have the ability to halt trading within MAYAChain if they detect malicious activity. This is in addition to automatic chain-specific halting functionality. The ability has been made with the potential for abuse in mind.
A single node can pause trading (HaltTrading) for up to an hour (720 blocks). Any additional node that calls for a halt will add 720 blocks to the halt timer. Any node that calls for the resumption of trading removes 720 blocks from the timer. The halt functions can only be called once by each active node per churn cycle (3 days). This gives the network the ability to respond to a malicious threat without giving any node unilateral control.
This blanket protection will automatically pause MAYAChain on a specific chain (Halt{Chain}Trading) and stop Yggdrasill vault funding if an unauthorised transaction is detected. This will emit a security event and be sent to MAYASec. The halt will allow Node Operators, MAYASec, and the development team to investigate and react immediately following an unauthorised transaction and issue a fix and restore service as quickly as possible.
Security events have been added within the code which automatically emits events when certain conditions are met such as node slashing for unauthorized transactions, attempted double-spending, or very large withdraws. Emitted events are sent to a MAYASec Discord monitoring channel for immediate review. These emitted on-chain events can also be seen on Midgard.
You've probably read that MAYAChain, similar to THORChain, utilizes Threshold Signature Scheme (TSS) to manage its vaults. But, what exactly is TSS and what advantages does it offer?
Digital Assets/ Cryptocurrencies are stored, or more accurately, assigned to an Address. This Address is derived from the Public Key, which in turn is derived from the Private key. This process is a one way street and can't be reversed (You cannot figure out the Private Key from the Wallet Address). This is achieved using cryptography.
Picture a cryptocurrency private key and signing algorithms as a key to a vault. It is a perfect fit - only this key can open the vault. If attackers manage to access the key, they can steal the victim's money and goods, leaving them with no way to get it back. And, if the key is lost, the safe and its contents are locked away forever. To reduce the risk of loss, the vault user can duplicate the key, but then it increases the risk of theft. It's a tricky situation!
In MAYAChain's case where larger sums of money are at stake, relying on a single entity to protect the vault is an inadequate solution. It's like trying to carry a heavy burden on your own - it's just too much to handle! So, instead of shifting the problem to another single entity (a custodian), why not share the responsibility between multiple parties (in our case, Nodes)? That way, a more secure unlocking system can be established, so that attackers have to steal multiple independent keys to unlock the vault.
MultiSig (multi-signature) is like having multiple locks on your vault - it's like having a security guard for each lock! Instead of a single key to open the vault, MultiSig creates a vault with multiple locks and keys and assigns the keys to multiple parties/Nodes. Now even if one of the keys is lost or stolen, the attackers won't be able to open the vault.
Of course, this means the vault needs to be bigger to accommodate the multiple locks, and it also means that anyone can see it has an unusual security mechanism, making it easier to track, and with higher fees as the transactions need to be encoded with more bytes for the additional signatures.
With Threshold Signatures, each of the Nodes creates a key independently. Then, they forge the vault’s lock together, in a modular way, so each Node shapes a part of the lock that corresponds to its key. Eventually, at the end of this process, a vault with a single modular lock is created that corresponds to each of the keys.
The unlocking process involves the Nodes taking turns in unlocking the vault. Each key can turn the modular lock a few degrees forward. After a few rounds of partial turning of the different keys, the modular lock is fully unlocked.
This modular lock can be shaped so that even if only a subset of the keys are available, the vault can still be unlocked.
This makes TSS superior to Multisig in several ways:
Cheaper transactions
Indistinguishable from a standard private key, from the viewpoint of the blockchain.
Multisig needs different coding development for different types of blockchain (e.g. UTXO vs EVM vs Cosmos SDK, etc..), unlike TSS which can be implemented for any blockchain.
Sources:
How MAYAChain facilitates continuous, incentivised liquidity.
Instead of limit-order books, MAYAChain uses continuous liquidity pools (CLP). The CLP is arguably one of the most important features of MAYAChain, with the following benefits:
Provides “always-on” liquidity to all assets in its system.
Allows users to trade assets at transparent, fair prices, without relying on centralised third-parties.
Functions as source of trustless on-chain price feeds for internal and external use.
Democratises arbitrage opportunities.
Allows pools prices to converge to true market prices, since the fee asymptotes to zero.
Collects fee revenue for liquidity providers in a fair way.
Responds to fluctuating demands of liquidity.
Start with the fixed-product formula:
Derive the raw "XYK" output:
Establish the basis of Value (the spot purchasing power of x
in terms of Y
) and slip, the difference between the spot and the final realised y
:
Derive the slip-based fee:
Deduct it from the output, to give the final CLP algorithm:
Comparing the two equations (Equation 2 & 6), it can be seen that the Base XYK is simply being multiplied by the inverse of Slip (ie, if slip is 1%, then the output is being multiplied by 99%).
The simplest method to exchange assets is the pegged model, (1:1) where one asset is exchanged one for another. If there is a liquidity pool, then it can go insolvent, and there is no ability to dynamically price the assets, and no ability to intrinsically charge fees:
The fixed-sum model allows pricing to be built-in, but the pool can go insolvent (run out of money). The amount of assets exchanged is simply the spot price at any given time:
The fixed-product model (Base XYK above), instead bonds the tokens together which prevents the pool ever going insolvent, as well as allowing dynamic pricing. However, there is no intrinsic fee collection:
The Fixed-Rate Fee Model adds a 30 Basis Point (0.003) (or less) fee to the model. This allows fee retention, but the fee is not liquidity-sensitive:
The Slip-based Fee Model adds liquidity-sensitive fee to the model. This ensures the fee paid is commensurate to the demand of the pool's liquidity, and is the one MAYAChain uses. The fee equation is shown separate (12b), but it is actually embedded in 12a, so is not computed separately.
The slip-based fee model breaks path-independence and incentivises traders to break up their trade in small amounts. For protocols that can't order trades (such as anything built on Ethereum), this causes issues because traders will compete with each other in Ethereum Block Space and pay fees to miners, instead of paying fees to the protocol. It is possible to build primitive trade ordering in an Ethereum Smart Contract in order to counter this and make traders compete with each other on trade size again. MAYAChain is able to order trades based on fee & slip size, known as the Swap Queue. This ensures fees collected are maximal and prevents low-value trades.
Assuming a working Swap Queue, the CLP Model has the following benefits:
The fee paid asymptotes to zero as demand subsides, so price delta between the pool price and reference market price can also go to zero.
Traders will compete for trade opportunities and pay maximally to liquidity providers.
The fee paid for any trade is responsive to the demand for liquidity by market-takers.
Prices inherit an "inertia" since large fast changes cause high fee revenue
Arbitrage opportunities are democratised as there is a diminishing return to arbitrage as the price approaches parity with reference
Traders are forced to consider the "time domain" (how impatient they want to be) for each trade.
The salient point is the last one - that a liquidity-sensitive fee penalises traders for being impatient. This is an important quality in markets, since it allows time for market-changing information to be propagated to all market participants, rather than a narrow few having an edge.
Balances of the pool (X and Y), are used as inputs for the CLP model. An amplification factor can be applied (to both, or either) in order to change the "weights" of the balances:
If a = b = 2
then the pool behaves as if the depth is twice as deep, the slip is thus half as much, and the price the swapper receives is better. This is akin to smoothing the bonding curve, but it does not affect pool solvency in any way. Virtual depths are currently not implemented
If a = 2, b = 1
then the Y
asset will behave as though it is twice as deep as the X
asset, or, that the pool is no longer 1:1 bonded. Instead the pool can be said to have 67:33 balance, where the liquidity providers are twice as exposed to one asset over the other.
Virtual Depths were initially applied to Synth Swaps using a multiplier of 2. It was intended that Synth Swaps would create 50% less slip and users pay 50% less fees. However, this was disabled after discovering that this would allow front-running. The multiplier is specified on /constants
as:
but currently overridden by a Mimir value of 1.
When a liquidity provider commits capital, the ownership % of the pool is calculated:
units = newly created pool units for the liquidity provider
r = cacao deposited
a = asset deposited
R = total Cacao Balance (before deposit)
A = total Asset Balance (before deposit)
P = total Pool Units (before deposit)
The liquidity provider is allocated rewards proportional to their ownership of the pool. If they own 2% of the pool, they are allocated 2% of the pool's rewards.
The new units are derived from the mean of adding new liquidity to both sides, multiplied by final total pool units.
In terms of amounts before the deposit:
Impermanent Loss Protection ensures LPs always either make a profit, or leave with at break even after a minimum period of time (set at 100 days), and partially covered before that point. This should alleviate most of the concerns regarding become an LP.
MAYAChain tracks a member's deposit values. When the member goes to redeem, their loss (against their original deposit value) is calculated and is subsidised with CACAO from the reserve.
Impermanent Loss Protection is always recorded and calculated symmetrically.
There is a 100 day linear increase in the amount of coverage received, such that at 50 days, the member receives 50%, 90 days is 90% etc.
P1
is the pool ratio at withdrawal.
Deposit values are not the amounts the member deposited. They are the immediate symmetrical value of what the member deposited instead.
Since the protection amount is added asymmetrically, the protection will experience a small slip. This helps to prevent attack vectors.
How MAYA enables synthetic assets with single asset exposure.
MAYA can not ensure the security of wrapped assets, so it does not wrap L1 assets to represent them. Instead it uses its liquidity to synthesise them, since liquidity is always 100% secured.
Maya Protocol synthetics assets - "synthetics" - are unique in that they are 100% collateralised when they exist, but switch to being 1:1 pegged at the time of redemption. Other synthetic or wrapped asset designs are either over-collateralized, or pegged, never both. This means they are either capital-inefficient (require over-collateralisation), or capital-sensitive (can depeg if there is <100% collateralization).
The advantage of Maya's design is that the collateralization is managed by the system on a best-effort basis to be aspirationally 100%. However when the asset is redeemed, it switches to being pegged 1:1, which means they can tolerate going below 100% collateralization without losing the peg. The deficit is regained by liquidity-sensitive fees on the redemption so that the last holders of the asset can achieve re-collateralization.
The collateral for synthetic assets is constant-product liquidity, always 50% in the asset, with the other 50% in CACAO. As price changes, the pool re-balances on the curve, having much stronger inertia than if it were 100% collateralized by the endogenous asset (CACAO). The price-shift is subsidised by other liquidity in the pool.
Synthetic Assets are aspirationally 100% collateralized by pool liquidity when they exist, but are always redeemed on a 1:1 basis, no matter the health of the collateral.
Synthetic Assets are created by swapping CACAO (or the external asset) into its synthetic representation using the pool liquidity depth. The pools treat the synthetic assets and the native assets as having identical in purchasing power:
r = cacao deposited
R = Cacao Depth (before)
A = Asset Depth (before)
The total Synth Supply is then updated:
In the above swap - an asset was added to the pool (the CACAO or ASSET), but none taken out since the swap output is minted from nothing. Thus the pool has extra liquidity that needs to be isolated from other LPs. This is the purpose of Synth Units.
Synth Units represent the liquidity collateral value that is required to "back" the synths 100%, and stops other dual-LPs from claiming ownership of it. They are computationally derived at any point which ensures there is exactly enough at any time to represent the outstanding supply.
The ratio of Synth Units to Liquidity Units should be the same as the ratio of synth supply to the total value of the pool without the synths (since LP units are all pool units without the synth units).
U = Synth Units (what needs to be isolated to back the synthS)
L = Liquidity Units (dual-LPs)
S = Synth Supply (the synths to be backed)
A = Asset Depth (the assets in the pool)
Synth Collateralization is done aspirationally. If the total value of the liquidity in the pool drops below the total value of the synths, then Synth Units minted will go to infinity, diluting the dual-LPs to 0%.
Synthetic Assets are redeemed by swapping the Synth across the pool. The synth is swapped using the same formula as though it was an L1 asset, thus the synth has the same purchasing power to the L1. It is therefore pegged.
s = Synths to Redeem
R = Cacao Depth (before)
A = Asset Depth (before)
The Synth Supply is thus decremented, and this in turn updates the oustanding Synth Units since it is computationally derived.
Synth Swaps can be done as follows:
Layer 1 to Synth: L1 in, Synth Minted
Synth to Layer 1: Synth REDEEMED, L1 swapped out
Synth to Synth: Synth REDEEMED, CACAO moved between pools, synth MINTED
To specify the destination asset is synth, simply provide a MAYA address. If it is Layer 1, then provide a layer 1 address, e.g. a BTC address.
All swaps pay fees, and a synth Mint or Redeem to an L1 is two swaps. Thus 10.0 btc/btc swapped across a pool of 1000 BTC.BTC will receive 10 - ((10/1000)*10)*2 = 9.8
minus any outboundFees. Is the synth pegged 1:0.98? No, because the same holder could swap 10 BTC in 1.0 BTC increments and receive 10*(1 - ((1/1000)*1)*2) = 9.98
minus 10 outboundFees. Both outboundFees and liquidityFees as a function of the swap size can be controlled by the user.
The dynamic synth unit accounting is to ensure that gain or loss caused by price divergence in the synths is quickly realised to LPs. If Synths as a function of Pool Liquidity goes to 100%, then dual-LPs are diluted to 0%.
Due to synths, Liquidity Providers are taking a leveraged position on the CACAO asset today. This can help them earn more rewards if CACAO outperforms the asset, but can also go the other way. The higher the percentage of synths that exist on the network relative to pool depth, the higher the leveraged position Liquidity Providers are taking.
This will soon be deprecated to allow PoL to control Synths.
The network can monitor the synth utilisation on a per pool basis, and add liquidity (asymmetrically addition of CACAO) if utilisation is greater than cap - 5%
(if economic security allows). If synth utilisation is under this figure, then the reserve would remove liquidity (if the PoL has an LP position in this pool).
cap = e.g. 1500 (in basis points)
range = 500 (in basis points)
PA = pool asset depth
S = synth supply
By having the reserve add cacao into the pool, it de-risks LPs from over CACAO leverage, as the reserve takes on some of that risk. The Reserve is long on its own (and only) asset. This, in turn, creates synth space in the pool, more synth minting and more single-sided asset deposits in the form of synths to enter.
If an active pool that minted synths becomes staged, then swaps are disabled. However, synth holders can always redeem for CACAO, or the underlying asset, by specifying that on the way out.
The network launched with a set number of constants, which has not changed. Constants can be overridden via Mimir and nodes have the ability to and change Mimir values.
Constant Values:
Mimir Values:
More documentation can be found .
Community developers write a new Bifröst module and propose it via a .
MAYAChain has several layers of security within the code base to ensure solvency of the network, stability of the protocol and minimize the impact of any exploit. These measures are in addition to human security efforts, see more information .
To project against double-spend attacks and re-orgs (non-instant finality chains), MAYAChain users Conformation counting for specific chains when receiving incoming value. informs MAYAChain when to process the incoming value. How many confirmations are required is dependent on the size of the incoming value.
This feature is controlled by several values that can be changed by Node Operators as required.
To get more information see .
Under the Hood: Asgard Vaults, TSS and Node Churns - LP university:
Threshold Signatures: The Future of Private Keys - Zengo Wallet:
The Keys to Crypto Kingdom: Wallet Address, Public and Private Keys Explained - Blocktrade:
Bitcoin stackexchange:
The coverage is then adjusted for the
``= 1440000 // 100 days
Then the extra CACAO added into the member's liquidity position to issue them extra liquidity units. The member then redeems all their units, and they will realise extra CACAO and extra ASSET.
This is the .
Synth Units are issued to cover the new liquidity minted, but held by the pool (not owned by anyone). Pool Units are therefore the sum of + synthUnits.
As Liquidity Providers have , as long as they stay for longer than 100 days, the Protocol is taking on the price risk. With the Grandfathering of ILP, the RESERVE will instead enter the pools as a dual-LP of last-resort. This stops Synths going to 100%.
Due to this, the minting of synths is capped to an upper limit of the total pool depth to protect Liquidity Providers and the network. The setting MaxSynthPerAssetDepth
setting controls the cap which is the asset depth percentage.
With the addition of yield-bearing synths, there can be a high demand for minting synths that exceed the cap with normal liquidity. See the original .
POL has been introduced to deal with a high demand for minting synths while maintaining a safe synth minting limit by using the CACAO within the .
y
Inflation
%100
0
%90
0
%89
%5.4
%80
%9
%70
%13
%60
%17
%50
%21
x
input amount
X
Input Balance
y
output amount
Y
Output Balance
a
Input Balance Weight
b
Output Balance Weight
R0
CACAO Deposited
R1
CACAO to redeem
A0
Asset Deposited
A1
Asset to redeem
MAYAChain Native NFTs
M-NFTs are at the cutting edge of blockchain technology, providing users with a comprehensive and secure ecosystem for the deployment, transfer, sale, and purchase of Non-Fungible Tokens (NFTs). Powered by the Maya Blockchain and indexed by MayaScan, M-NFTs employ the innovative concept of memos and ordinal theory to guarantee secure operations and the authenticity of digital assets.
Memo-resonance technology, akin to ordinal theory, is at the heart of the M-NFT standard, allowing for the seamless integration of token deployment, minting, transfer, sale, and purchase. This revolutionary framework is revolutionizing the NFT landscape by empowering creators, collectors, and enthusiasts to forge deeper relationships with digital art and collectibles.
M-NFT is a pioneering force, ushering in a new era of unprecedented engagement and authenticity in MAYAChain. By innovating and reimagining the uses cases of MAYAChain, M-NFTs are paving the way for a seamless and efficient ecosystem where users can effortlessly interact with digital assets, and tokenize their ideas.
For more info on how to interact with M-NFTs, or even create your own collection, click here.
Find detailed information about the various security and code audits that have been conducted on the protocol.
Draft: ETH Router
Final: Layer 1 & Liquidity Nodes
Final: Liquidity Auction
Final: Dynamic Inflation
Final: Liquidity Auction Tiers
Final: Thorchain's Bifrost
Final: Dash's Bifrost
MAYAChain Native Tokens
MRC-20 tokens are a revolutionary step forward in the Maya Protocol, and are powered by the MAYAChain and indexed by MayaScan. This new ecosystem is designed to make token deployment, minting, transfer, selling, and buying effortless and efficient. It is based on the concept of memos and ordinal theory, which draws inspiration from both the ERC-20 standard on Ethereum and Bitcoin's ordinals.
MRC-20 combines these elements to create a comprehensive and secure framework for managing token interactions, ensuring the preservation of network integrity. By providing this new standardized approach to token operations, MRC-20 is revolutionizing the way users interact with tokens on the blockchain and reinforcing Maya's position as a leader in blockchain innovation.
For more info on how to interact with MRC-20 Tokens, or even create your own, click here.
Maya Protocol's Blockchain Explorer
MayaScan is the main blockchain explorer offered by Maya Protocol, offering an extensive range of services for users to track their transactions, swaps, liquidity, network status, nodes and more.
By entering any of the supported MAYAChain addresses (Bitcoin, Ethereum, THORChain, Dash, Kujira, and of course MAYAChain) into the search field, users can easily view all the relevant information regarding the address.
MayaScan provides a secure platform for on-chain p2p messaging, allowing for anonymous communications between nodes.
As if this wasn’t enough, MayaScan also uses cutting-edge Ordinals technology and Memos to create and trade Native MAYAChain Tokens and Non-Fungible Tokens (NFTs).
Please find the most frequently asked questions in the following sections.
What can I do on MAYAChain?
You can swap/trade (buy & sell) Assets, provide Liquidity and earn yield, and/or run a Node to help secure our network in exchange for fees and yield.
The team and founders have Zero CACAO allocation. If they do have it, they have acquired it by buying it from the market, like everyone else. 90% of CACAO has been donated to early Liquidity Providers during the Liquidity Auction, while the remaining 10% is in the Maya Fund vault to finance pools' Impermanent Loss.
Maya Protocol founders have 15.6% of MAYA, but these tokens can't be sold. You can check Maya Protocol's Operations Wallet (that pays the team, marketing, and other expenses) at this link.
For an updated list please check MayaScan Pools Page. But as of time of writing this guide, supported coins are: BTC, ETH, RUNE, USDT, USDC, wstETH, KUJI, USK, AETH, XRD & CACAO.
You can currently buy CACAO on both El Dorado and THORWallet.
There is no BEP20 or ERC20 CACAO in existence.
You can only buy Native CACAO from the market.
Only native CACAO is used in MAYAChain.
Currently, the only way to buy MAYA is OTC. If you wish to do so, you can head to our Discord.
Uniswap enables decentralized crypto trading within a blockchain (mainly Ethereum), while MAYAChain offers a secure method to trade/exchange native assets across blockchains.
Current Chains — Bitcoin, Ethereum, THORChain, Dash, Kujira, Arbitrum & Radix.
Tokens such as: ERC-20 (USDT, USDC & wstETH) and Kujira native assets (USK)
See full list on the blockchain explorer.
Does MAYAChain need Oracles?
No, it doesn't. MAYAChain's Continuous Liquidity Pool design & arbitrageurs set prices. When pools become imbalanced, arbitrage bots trade to rebalance them. CACAO binds all pools together, allowing arbitrage traders to purchase tokens at a lower price on MAYAChain & sell them for a profit. Arbitrage bots interact with the API 24/7, & anyone can run their own!
Yes, there is a fee for every withdrawal, whether it is an asymmetrical or symmetrical deposit.
TLDR: Transaction Fee = Inbound fee Network Fee = 3x fee charged by network Total = Sum of both
Overview of the process and why:
Nodes Pay 1* Standard Fee from the native pools (gas pools)
LPs get paid back 2* St Fee, they earn >1x in margin due to arbing
Reserve gets paid back 3x, it earns 1x in margin which goes to the reserve.
➜ See Outbound-Fee.
➜ Standard Fee inbound address end point.
➜ Watch Fees and Wait Times Explained video
No. Only short tail assets with high MarketCap, good velocity and economic activity would have chances to win liquidity competition to get listed. Although DEX Aggregators connected to MAYAChain can offer this service. Check Governance for how tokens are added, and our pools for the full list of supported tokens.
Open a ticket in Discord if you would like to see a new ERC-20 (on Ethereum or Arbitrum) or Kujira native asset added to Maya Protocol.
No. Synths enables synthetic assets with no IL and with single asset exposure. They do not generate yield.
MAYAChain uses Tendermint which is a classical BFT algorithm. 2/3 of the validators need to agree and the network values safety. The chain has instant finality and this is needed to secure cross-chain bridges.
If each pool is comprised of two assets (e.g. BTC:ETH) then there will be a scaling problem with n*(n-1)/2 possible connections. By having CACAO on one side of each pool, CACAO becomes a settlement bridging asset allowing swaps between any two other assets. Additionally, having CACAO in a pool ensures that the network can become aware of the value of assets it is securing.
Simply put, Cross-chain bridges are a better solution than Atomic Swaps. Atomic Swaps involve a complex process of signing cryptographic keys between two parties that require interactivity. You also need a counter-party on all trades. Cross-chain bridges, coupled with continuous liquidity pools means you don't need a designated counter-party, and swaps can happen in less than a second. 1-way state pegs are better than 2-way asset pegs because assets don't need to be wrapped or pegged. Instead of having IOU tokens, real native assets can be used instead.
The goal is to have a fixed supply at all times, instead of constantly emitting (infinite supply like Cosmos or Ethereum) or reducing the emission down to zero (Bitcoin). Although, Maya Protocol can elect to use dynamic inflation.
Approximately every three days, the pending pool with the deepest liquidity is churned in (becomes an active pool). This is called a Pool Churn. Note: A pending pool must have a minimum 10K CACAO to be eligible for a churn.
This means there is an open decentralised liquidity competition where the community can vote with their liquidity. N.B. Caps will prevent voting with liquidity.
There is a set max of 100 active pools, and once achieved, deeper pending pools will be able to replace shallowest active pools. See Governance for more information.
Make sure you have a sufficient amount of native cacao to process transactions. Also be sure to check if the liquidity caps are full. If so, you will not be able to add liquidity at that time. If you see errors like “No UTXOs to send” or “Need to wait for more UTXO confirmation”; likely you are trying to spend UTXO assets (BTC, LTC, BCH) that you have just transferred into your wallet. Please wait for more blockchain confirmations, and try again later!
MAYAChain produces a block every 6 seconds on average. So, MAYAChain produces around 14,400 blocks per day. Sometimes blocks can be produced slightly faster or slower, so these numbers are estimations.
You can check the churns here. Each entry is a churn.
You can convert any Thor address to Maya Address using this tool, as Thor and Maya share the same hdpath.
You can by visiting this link.
You do not need CACAO to interact with MAYAChain. You can perform swaps and add/remove liquidity without directly touching $CACAO or the MAYAChain protocol. You will need to find a MAYAChain-connected wallet.
Yes, the Network Fee is collected in CACAO. If the transaction involves an asset that is not CACAO, the user pays the asset's Network Fee. The equivalent amount is taken from that pool's CACAO supply and added to the Protocol Reserve.
Users can swap any assets which are on connected chains and which have been added to the network. Users can swap from any connected asset to any other connected asset. They can also swap from any connected asset to CACAO.
MAYA manages the swaps following the rules of the state machine - which is completely autonomous. Every swap that it observes is finalized, ordered, and processed. Invalid swaps are refunded, and valid swaps are ordered transparently and resistant to front-running. Validators can not influence the order of trades and are punished if they fail to observe a valid swap.
Swaps are completed as fast as they can be confirmed, around 5-10 seconds.
The cost of a swap is made up of two parts:
Outbound Fee
Price Slippage
All swaps are charged a network fee. The network fee is dynamic – calculated by averaging recent gas prices.
Swap fees are dependent on the depth of liquidity pools, the deeper the pools (aka the more liquidity) the less the fee is. Swap fee also depends on the size of the deposit. Bigger deposits incur more swap fees.
Note that users who force their swaps through quickly cause large slips and pay larger fees to liquidity providers. Learn more about Network Fees.
The Keystore is an encrypted version of a user's private key, protected by a password, and presented in JSON/text format. It is a more secure alternative to the private key, as it requires a password to access.
Liquidity providers deposit their assets in liquidity pools and earn yield in return. They earn tokens in Cacao and the pool's connected asset. For example, someone deposited in the BTC/CACAO pool will receive rewards in BTC and CACAO.
Read our whitepaper for a detailed breakdown of being a Liquidity Provider on Maya.
Yes! Depositing assets on MAYAChain is permissionless and non-custodial.
Several factors will affect how much yield you receive, including your ownership % of the pool, swap volume, and size of swaps. The yield comes from fees and rewards from the protocol.
Yield is calculated for liquidity providers in every block. Yield is paid out to liquidity providers when they remove assets from the pool. Rewards are calculated according to whether or not the block contains any swap transactions. If the block contains swap transactions, the amount of fees collected per pool sets the number of rewards. If the block doesn't have trades, the amount of assets in the pool determines the rewards.
There is no minimum or maximum time or amount. Join and leave whenever you wish. There is however a required confirmation time before MAYAChain credits you with liquidity when adding or swapping to protect against Reorgs.
If you bonded your liquidity you have to wait for the Node you bonded to to churn out.
Symmetrical deposits are where users deposit an equal value of 2 assets to a pool. For example, a user deposits $500 of BTC and $500 of CACAO to the BTC/CACAO pool.
Asymmetrical deposits are where users deposit unequal values of 2 assets to a pool. For example, a user deposits $2000 BTC and $0 CACAO to the BTC/CACAO pool. In the backend, the member is given ownership of the pool that considers the slip created in the price. The liquidity provider will end up with <$1000 in BTC and <$1000 in CACAO. The deeper the pool, the closer to a total of $2000 the member will own.
No. You cannot withdraw symmetrically. You can withdraw only asymmetrically for LP you deposited asymmetrically.
Yes, because when you pool asymmetrically your asset is swapped into 50% cacao and 50% asset. When swapping you are subject to slippage and fees. There are 2 types charged on asymmetrical deposits/withdrawals:
The on-chain deposit transaction fee (inbound tx)
The liquidity fee as a function of slip
Upon withdrawal, there will also be a transaction fee (outbound tx)
No, there is only the deposit transaction fee.
If you deposit asymmetrically you can ONLY withdraw asymmetrically.
You can withdraw your symmetrical deposit both asymmetrically and symmetrically.
Yes, but the IL Protection is applied to the asymmetrical deposit after it has been converted into a symmetrical deposit (also meaning after slippage and fees). This means that the IL Protection will cover both assets. See ILP above.
Currently, yes. Our ILP guarantees that LPs will either make a profit or at least recoup their investment (in USD value) in comparison to holding them externally after a certain period (currently set to 100 days) and even that they can be partially reimbursed for any impermanent losses incurred before that time. Any potential losses in the LP deposit are subsidized in CACAO.
ILP kicks in 50 days after providing liquidity, with a 1% compensation for any realized IL. After that, 1% more is added everyday until , on day 150, 100% of the IL realized is covered. As an example, on day 100 after adding liquidity, your ILP is 50%.
ILP kicks in 50 days after providing liquidity, with a .25% compensation for any realized IL. After that, .25% more is added everyday until , on day 450, 100% of the IL realized is covered.
The Soft Cap has been removed, so there should be no limit to the amount of liquidity entered. There is a hard cap in place to ensure the total pooled cannot exceed the total bonded, making the network unsafe however the Incentive Pendulum makes this cap near impossible to reach.
There are two main strategies; active and passive.
Passive liquidity providers should seek out pools with deep liquidity to minimize risk and maximize returns.
Active liquidity providers can maximize returns by seeking pools with shallow liquidity but high demand. This demand will cause greater slips and higher fees for liquidity providers.
A Node Operator may or may not have their own bond provider address. If they do, node address = bond address. If they don't have it, node address = node operator address.
Head to MayaScan pools page. Choose the pool of interest. Get the swap fees and annualize them (x365) then divide by the total pool size.
Go to this link.
Choose your pool (BTC, ETH, etc..)
Paste in your wallet address.
Press "Check Position".
A list of all $MAYA Airdrops, conditions and expected dates.
Beware of scammers! Maya Protocol will NEVER announce a surprise or emergency Airdrop. ALL airdrops will be announced well in advance on our Discord, Twitter, Reddit, and other Social Media. Make sure to check multiple sources of information before claiming any Airdrop.
All future Airdrop dates are estimates.
On the 2nd of April, 2023, 2% of $MAYA token total supply (20,000 $MAYA) was Airdropped to early LPs. 5% still remain to be distributed 200, 350, 500 days after the Liquidity Auction $CACAO distribution (17th of April, 2023). The 5% will be divided to thirds and Airdropped to Tier 1 LPs that stayed in the pools. Here are the dates:
Liquidity Providers Airdrops are calculated based on liquidity left, not liquidity initially provided.
On the 17th of May, 2023, 7% of $MAYA tokens total supply (70,000 $MAYA) was Airdropped To $RUNE holders & $RUNE liquidity providers. The conditions were:
A. Having $RUNE bonded in a Node,
B. Having $RUNE locked in a symmetrical LP position,
C. Having a $RUNE asymmetrical LP position,
D. Holding $RUNE in a wallet and/or,
E. Holding $RUNE in Maya pools during the auction.
Cases A and B had a 4x boost. Cases C and D had a 2x boost. Case E had a 1x boost.
On the 1st of July, 2023, 1% of the total $MAYA tokens supply (10,000 $MAYA) was Airdropped to Maya Mask Holders.
20% of $MAYA has been airdropped to the Maya Mask holders who claimed the Airdrop.
80% of $MAYA stays inside the masks to stake later on AZTECChain's staking module.
The remainder of the unclaimed 20% will also be added to the staking module on AZTECChain.
Bear in mind there will be an $AZTEC airdrop as well for Maya Mask holders in the future.
The $AZTEC amount for Airdrop and staking is identical to $MAYA.
7% of the $MAYA total supply will be rewarded to early Liquidity Node operators.
How will the $MAYA Airdrop be distributed among Liquidity Node operators and Liquidity Bonders?
50% of the Airdrop will go to the LN operator regardless of their liquidity contribution, and 50% will go to the LBs (including the LN operator, if they have liquidity bonded as well).
Maya Protocol's Official NFT Collection
Maya Masks is the NFT collection that visualizes and unites the Maya Protocol community. The Masks are designed to be wearable assets for your favorite Web3 avatar. Whether you're a Bored Ape, Moonbird, or ThorGuard, you can put a Mask on to show that you're a Mayan!
Only 1,689 Genesis Maya Masks exist in the market. The remaining 4,371 were taken out of supply after the public mint ended. These Maya Masks currently exist on the Ethereum blockchain, and will migrate to Aztec Chain once ready.
Within the collection there are 2 main types of Masks; Golden Masks, and regular Masks. Golden Masks are the rarest pieces in the collection and offer increased utility compared to regular Masks. Maya Masks not only represents the Maya Protocol Community, but it is heavily utility-focused.
Maya Masks main utility is to:
Stake for daily CACAO rewards from the protocol when Aztec Chain is launched.
Access pass for community events, channels, and future collections.
Receive a one time airdrop of MAYA and AZTEC (Each Maya mask contains 4.5 MAYA & 4.5 AZTEC, 80% is locked in the Mask and the rest %20 airdropped).
There are 1,000,000 tokens (MAYA/AZTEC). 10,000 will be shared among 1689 Maya Masks.
2,500 tokens allocated to 20 Golden Masks (2,500/ 20 = 125 MAYA).
7,500 tokens allocated to 1669 regular Masks (7,500/ 1669 = 4.49 MAYA).
Same calculations apply to AZTEC.
MAYA has already been Airdropped to Maya Mask holders. AZTEC will be Airdropped after the launch of AZTECChain .
OpenSea: https://opensea.io/collection/mayamasks
Contract: https://etherscan.io/token/0xe00d8f3dca2ac474f4d7f177570f77de0774e754
Website: https://www.mayamask.com/
Maya Protocol's Visual Identity guide.
Whether your creative outlet is a YouTube video, an article, a tweet, or a meme, here are a few simple guidelines that will make your content look more polished and consistent with the visual identity of Maya Protocol's brand.
Maya Protocol is an ecosystem that encompasses MAYAChain (Live) & AZTECChain (in development)
MAYAChain is a cross-chain AMM that facilitates cross-chain swaps without the need for bridging or wrapping assets.
AZTECChain is the smart contract layer for Maya Protocol that will enable suite of DeFi solutions to compliment & leverage MAYAChain cross-chain capabilities.
For more information and expanded explanations please visit What is Maya Protocol & How it works sections.
Note how the names are written. Make sure to use this conventions.
Maya Protocol: 2 separate words, with only the first letters capitalized for both words.
MAYAChain: 1 word, with the word "MAYA" and the first letter of "Chain" capitalized.
AZTECChain: 1 word, with the word "AZTEC" and the first letter of "Chain" capitalized.
You can find all the logos in different formats on this link.
If you're going to reference any Maya Protocol social media or websites, please use the official links.
If you need anymore information, please contact the team directly on our official Discord.
Social Media
We are thrilled to announce the launch of our Maya Ambassador Program! As part of our ongoing mission to empower and educate our community, we are introducing this exciting initiative aimed at promoting Maya and all of its benefits. Applications will be open for a limited time, so don't miss your chance to be part of the program!
The Maya Ambassador Program is a collaboration between Maya Protocol, talented content creators, and key opinion leaders (KOLs) who are passionate about the DeFi ecosystem. Our goal is to expand our reach, create informative content, and engage with a wider audience. In return, we are offering unique rewards and opportunities for our ambassadors, making it a mutually beneficial partnership.
By producing informative content about Maya Protocol, ambassadors can earn up from $500 to $700 in MAYA tokens per month.
Eligibility for this opportunity is open to creators who fulfill the following criteria:
Proven Crypto or Web3 Content Creators: You have established yourself as a credible creator in the realm of cryptocurrency or Web3, and you possess a substantial following on any of the popular social media platforms such as YouTube, TikTok, Twitter, and others.
Passion for DeFi: You demonstrate a genuine enthusiasm for Decentralized Finance (DeFi) and actively engage with its concepts and developments.
Alignment with Maya DNA: You possess a shared sense of identity and values with the Maya community.
Apply to the program (instructions below).
Get selected based on your enthusiasm, engagement, and influence within the community.
Create content that informs our community about the technical or social aspects of the project, ensuring it is well-presented, up-to-date, and of high quality.
Submit content for review.
Receive your MAYA tokens at the end of every month!
Our team will carefully review the applications and select the most promising candidates based on their enthusiasm, engagement, and influence within the community. The chosen Maya Ambassadors will then create well-presented, informative content in various formats, such as video and text, to introduce Maya Protocol to new audiences.
You can earn up from $500 to $700 monthly in Maya tokens.
Eligibility for this opportunity is open to creators who fulfill the following criteria:
Proven Crypto or Web3 Content Creators.
You have established yourself as a credible content creator in cryptocurrency or Web3.
Possess a substantial following on popular social media platforms such as YouTube, TikTok, Twitter, or others, with reasonable engagement.
Minimum Audience in at least one of the following:
Twitter: 3k followers
YouTube: 6k subscribers
TikTok: 15k likes
Medium, Discord, and Telegram - no minimum range - we will review quality individually.
Provided numbers are for reference only. Meeting these numbers is not the sole factor in determining eligibility. The overall quality of your content, audience engagement, and credibility within the crypto and Web3 communities are also likely to be considered.
If you're interested in joining the Maya Ambassador Program, please fill this form and we will get back to you ASAP.
Don't miss this incredible opportunity to be part of our growing community and help spread the word about Maya Protocol. Apply now, and good luck!
Setting up a Kubernetes Cluster with GCP (GKE)
GCP account
gcloud
and GCP credentials configured
kubectl
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
After the installation, perform the steps outlined below. This will authorize the SDK to access GCP using your user account credentials and add the SDK to your PATH. It requires you to log in and select the project you want to work in. Then add your account to the Application Default Credentials (ADC). This will allow Terraform to access these credentials to provision resources on GCP. Finally, you need to enable the Compute Engine and Kubernetes Engine API services for your GCP project.
You will be asked for your Personal Access Token with read/write privileges (retrieved from API Panel from the GCP web console.)
API -> Tokens/Keys -> Create Token.
Make sure you handle your secrets securely!
Use the commands below to deploy an GKE cluster:
During the deployment, you will be asked to enter information about your cluster:
Project ID
Zone -- gcloud compute zones list
Confirm yes
Deploying a cluster takes ~15 minutes
Now that you've provisioned your GKE cluster, you need to configure kubectl. The following command will get the access credentials for your cluster and automatically configure kubectl.
This replaces the existing configuration at ~/.kube/config.
Once done, you can check if your cluster is responding correctly by running the following commands.
You are now ready to deploy a MAYANode.
Watch our Co-Founder Aaluxx speak about Maya with various hosts!
Aug 23, 2024
Aug 22, 2024
March 10, 2024
Jan 27, 2024
Jan 5, 2024
Oct 6, 2023
Oct 4, 2023
Sep 11, 2023
What Is Maya Protocol: Cross-Chain Paradigm, Integrating Cardano!
July 1, 2023
Dash Podcast 206 with Aaluxx: Dash Activation on the Maya Protocol
June 20, 2023:
Update on Dash-Maya Integration | Incubator WEEKLY
March 13, 2023:
Maya Protocol - Non-custodial Cross-chain swaps on Kujira
March 6, 2023
Will DASH Plus MAYA Equal DEX Success? | Incubator WEEKLY
March 3, 2023
Halborn Flash Videos with Aaluxx Myth of Maya Protocol
February 27, 2023
Maya Protocol Launch - Interview With AaluxxMyth About The Launch And Long-Term Plans
February 21, 2023
Citizen Cosmos: A citizen odyssey, ep. XVI, special mission - Maya Protocol
February 8, 2023
An Intro To... Maya Protocol!
January 18, 2023
Aaluxx of the Maya Protocol on Expanding THORChain's Vision of Cross-Chain Swaps and Liquidity
October 13, 2022
What is Maya Protocol?
December 19th, 2022
CROSS CHAIN CRYPTO EXPLOSION!? With Maya Protocol
Setting up a Kubernetes Cluster with Azure (AKS)
Azure account
az
and Azure credentials configured
kubectl
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
You will be asked for you Personal Access Token with read/write priveleges (retrieve from API Panel from the Azure web console.)
API -> Tokens/Keys -> Create Token.
Make sure you handle your secrets securely!
Use the commands below to deploy an AKS cluster:
During the deploy, you will be asked to enter information about your cluster:
Location -- az account list-locations -o table
Name
Confirm yes
Deploying a cluster takes ~15 minutes
Now that you've provisioned your AKS cluster, you need to configure kubectl. Customize the following command with your cluster name and resource group. It will get the access credentials for your cluster and automatically configure kubectl.
This replaces the existing configuration at ~/.kube/config.
Once done, you can check if your cluster is responding correctly by running the following commands.
You are now ready to deploy a MAYANode.
Setting up a Kubernetes Cluster with Linode (linode)
a Linode account
linode-cli
and linode credentials configured
kubectl
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
You need to have pip (python) on your system.
Use the API token to grant linode-cli access to your Linode account. Pass in the token string when prompted by linode-cli.
MacOS:
Windows:
MacOS:
Windows:
Use the commands below to deploy a Kubernetes cluster.
You can run the make command that automates those command for you like this:
Or manually run each commands:
Now that you've provisioned your Kubernetes cluster, you need to configure kubectl.
To configure authentication from the command line, use the following command, substituting the ID of your cluster.
This replaces the existing configuration at ~/.kube/config.
Once done, you can check your cluster is responding correctly by running the command:
To destroy and remove previously created resources, you can run the command below.
Or run the commands manually:
Setting up a Kubernetes Cluster with Hetzner Dedicated Servers
This guide for Hetzner Bare Metal is WIP and not currently recommended. Proceed with caution until an update is released and this warning removed.
Executing the scripts in combination with some manual procedures will get you highly available, secure clusters with the following features on bare metal.
Clone this repository cd
into it and download kubespray.
Create a Python virtual environment or similar.
Install dependencies required by Python and Ansible Glaxy.
Create a deployment environment inventory file for each cluster you want to manage.
Edit the inventory file with your server ip's and network information and customize everything to your needs.
This will install and use Ubuntu 20.04 on only one of the two internal NVMe drives. The unused ones will be used for persistent storage with ceph/rook. You can check the internal drive setup with lsblk
. Change it accordingly in the command shown above when necessary.
Create a pristine state by running the playbooks in sequence.
Instantiate the servers.
Deploying a MAYANode with Kubernetes
In order to deploy all the different services and provide a high availability environment to operate your node, Kubernetes is the preferred scheduling platform. Any production-grade Kubernetes cluster can be used to run and deploy a MAYANode. You need your Kubernetes provider to offer external load balancers services type features. Azure, Digital Ocean, GCE, OpenStack are compatible with external load balancers.
Terraform is a type of domain-specific language (DSL) used to describe code infrastructure. It is designed to make it easier to create/destroy infrastructure hosted locally or by a provider.
This Terraform deployment will deploy a Kubernetes cluster using your VPS provider credentials and EKS service. The cluster will have autoscaling capabilities, which means you don’t have to deal with how many nodes you need to deploy to run your MAYANode services.
All the default configurations used in these instructions are for a production environment with enough resources to run your MAYANode in good conditions.
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
There are three important steps to getting your node set up, deployed and churned in.
Your repository should be organised as follows:
All of your set up commands are run in cluster-launcher
and all of your deploying/joining/managing/leaving commands are run from node-launcher
All of your commands can now be run separately.
It is heavily advised to not set up nodes on the same provider. Deploy 1 node on Azure, 1 node on Digital Ocean etc.
Overview of MAYANodes
MAYANodes service the MAYAChain network. Each MAYANode is comprised of several independent servers in a cluster. All MAYANodes communicate and operate in cooperation to create a cross-chain swapping network.
To set up a node, you have three choices:
Set up manually (not recommended unless you are an expert)
Set up via Kubernetes (recommended)
Set up via Provider (coming soon).
Each MAYANode is comprised of 5 major components.
mayanode
- this is a daemon that runs the MAYAChain chain itself and a HTTP server, that gives a RESTful API to the chain.
bifrost
- this daemon creates connections to remote chains (like Bitcoin, Ethereum, Binance, etc) to both observe activity on those chains (incoming/outgoing transactions), and also sign/broadcast outgoing transactions (moving funds on remote chains).
gateway
: MAYANode gateway proxy to get a single IP address for multiple deployments
midgard
- this daemotn is a layer 2 REST API that provides front-end consumers with semi real-time rolled up data and analytics of the MAYAChain network. Most requests to the network will come through Midgard. This daemon is here to keep the chain itself from fielding large quantities of requests. You can think of it as a “read-only slave” to the chain. This keeps the resources of the network focused on processing transactions.
Full nodes - for every chain that is supported by the network, each MAYANode operator will run their own full node of each chain (Bitcoin, Ethereum, Binance, etc).
As new nodes join/leave the network, this triggers a “churning event”. Which means the list of validators that can commit blocks to the chain changes, and also creates a new Asgard vault, while retiring an old one. All funds in this retiring vault are moved to the new Asgard vault.
Normally, a churning event happens every 3 days (50,000 blocks), although it is possible for it to happen more frequently (such as when a node optionally requests to leave the network using the LEAVE
memo).
On every churn, the network selects one or more nodes to be churned out of the network (which can be typically churned back in later). In a given churning event, multiple nodes may be selected to be churned out, but never more than 1/3rd of the current validator set. The criterion the network will take into account is the following:
Requests to leave the network (self-removal)
Banned by other nodes (network-removal)
How long an active nodes has been committing blocks (oldest gets removed)
Bad behavior (accrued slash points for poor node operation)
On every churn, the network may select one or more nodes to be churned into the network but never adds more than one to the total. Which nodes that are selected are purely by validator bond size. Larger bond nodes are selected over lower bond nodes.
There is an endpoint on Midgard that has deep analytics in mean and median active & standby bond sizes to drive efficient discovery of the best "bond" size. Maya's minimum bond is currently: 100K Cacao (MIMIR Override).
The network is safe when it is over-bonded, but shrewd Node Operators will probably actively manage their bond and pool part of it instead to maximize yield.
Deciding to run a node should be carefully considered and thought through. While the payoffs/rewards can be significant, there can also be an equally significant cost.
Running a malicious node or stealing from the network results in a slashing of this bond. Here are the ways in which a validator’s bond can get slashed.
Double Sign (5% of minimum bond) - if it is observed that a single validator node is committing blocks on multiple chains. To avoid this, never run two nodes with the same node account at the same time.
Unauthorized transaction (1.5x transaction value) - if a node sends funds without authorization, the bond is slashed 1.5x the value of the stolen funds. The slashed bond is dumped into the pool(s) where the funds were stolen and added to the reserve.
Bond slashing takes directly from the bond and does not affect rewards.
When a node is active, it earns rewards from the network in CACAO. Sufficient rewards are required to be earned for a Validator to be profitable. Running an unreliable node results in rewards being slashed. Here are the ways in which a validator’s rewards can be slashed.
Not Observing (2 slash pts) - if a node does not observe transactions for all chains while other nodes do, they get slash points added.
Not signing a transaction (600 slash pts) - if a node does not sign an outbound transaction, as requested by the network, they will get slash points added.
Fail to keygen (1 hr of revenue) - When the network attempts to churn and attempts to create a new Asgard pubkey for the network and fails to do so due to a specific node(s), they will lose 1 hr of revenue from their bond.
Slash points undo profits made on the network. For every 1 slash point a node receives, they lose 1 block of rewards. Rewards slashing reduces earned rewards and does not affect a validator’s bond.
Dynamic Inflation adds up to rewards. When the system is healthy, there is no inflation; should LPs withdraw CACAO considerably, inflation starts to kick in to incentivize pooled liquidity.
When a node joins the network, the current block height is recorded. The system creates one block unit for every active node for every active block and has a running total of the block units created. When a node leaves, it cashes in its block units for a portion of the bond rewards. The spent block units are destroyed.
For example, there are 10000 CACAO in bond rewards outstanding. Node A has been active for 30 blocks and has 33 block units but accrued 3 slash points. There are 1000 block units in total. Node A leaves the network and cash in its 30 block units (33 - 3). It receives 300 CACAO ((30/1000) * 10000), leaving 9700 CACAO in node rewards. Its 33 block units are destroyed, leaving 967 block units left.
Depending on how the node was set up, it will likely cost between $1000 and $2000 per month, potentially more as the blockchain scales. The main driver of costs is resource allocation to hosting each MAYANode service.
Running a MAYANode is no simple task. As an operator, you must run/maintain multiple Linux servers with extremely high uptime. It is encouraged that only professional systems engineers run nodes to maintain the highest quality, reliability, and security of the network. The simple question to know if you have the skillsets to run a MAYANode is:
Have you used pagerduty before?
If the answer is no, it’s probably best not to run a node and participate in the network in other ways. The following skill sets are required to be an effective node operator.
Advanced knowledge of Linux server administration and security
Advanced knowledge of Kubernetes
Advanced experience running a host of nodes on a hosted platform such as AWS, Google Cloud, Digital Ocean, etc
Knowledge of running full nodes for other chains such as Bitcoin, Ethereum, and Binance.
Willingness to be “on call” at all times to respond to issues when/if your node becomes unavailable
When you run a MAYANode, each MAYANode will have its own node account. An example node account looks like this:
Most importantly, this will tell you how many slash points the node account has accrued, their status, and the size of their bond (which is in 1e8 notation, 1 Cacao == 100000000).
Types of node status:
Unknown - this should never be possible for a valid node account
Whitelisted - node has been bonded, but hasn’t set their keys yet
Standby - waiting to have minimum requirements verified to become “ready” status. This check happens on each churn event (3 days on average).
Ready - node has met minimum requirements to be churned and is ready to do so. Could be selected to churn into the network. Cannot unbond while in this status.
Active - node is an active participant of the network, by securing funds and committing new blocks to the MAYAChain blockchain. Cannot unbond while in this status.
Disabled - node has been disabled by use of LEAVE, and cannot re-join.
To get node account information, make an HTTP call to your maya-api
port which will look like the following:
A node can vote at any time on any key value.
A node's vote is valid as long as they are active (and removed if they are not).
2/3rds of active nodes need to agree for the change to happen
If 2/3rds consensus is not reached, Mimir admin takes priority, or a constant if present.
A node can change its vote anytime.
A node can delete its vote by using -1 value
Voting costs one native transaction fee, which is deducted from their bond.
Use Windows Subsystem for Linux - ****
Firstly, clone and enter the . All commands in this section are to be run inside this repo.
Then install the :
Install Terraform:
The allows you to manage your GCP services.
Use the package manager to install the GCP CLI.
You must install and configure the Kubernetes CLI tool (kubectl). **To install kubectl** , follow , or choose a package manager based on your operating system.
Use the package manager to install kubectl.
You also need wget and jq, follow , or choose a package manager based on your operating system.
Use the package manager to install wget and jq Note: You most likely have these installed already.
Use Windows Subsystem for Linux - ****
Firstly, clone and enter the . All commands in this section are to be run inside this repo.
Then install the :
Install Terraform:
The allows you to manage your Azure services.
Use the package manager to install the Azure CLI.
You must install and configure the Kubernetes CLI tool (kubectl). **To install kubectl** , follow , or choose a package manager based on your operating system.
Use the package manager to install kubectl.
You also need wget and jq, follow , or choose a package manager based on your operating system.
Use the package manager to install wget and jq Note: You most likely have these installed already.
Use Windows Subsystem for Linux - ****
To install the linode-cli (Linode CLI), follow .
Create a Linode API token for your account with read and write access from your . The token string is only displayed once, so save it in a safe place.
To install the kubectl (Kubernetes CLI), follow or choose a package manager based on your operating system.
Use the package manager to install kubectl.
Use the package manager to install kubectl.
To install the wget, follow or choose a package manager based on your operating system.
Use the package manager to install wget.
Use the package manager to install wget.
Note: If the above linode-cli
command is broken you can download the file from the web for the respective cluster.
Checkout the repository to manage a cluster of dedicated servers on Hetzner.
The scripts in this repository will set up and maintain one or more clusters consisting of dedicated servers. Each cluster will also be provisioned to operate as a node in the network.
(based)
Internal NVMe storage (/)
Virtual LAN (also over multiple locations) ()
Load Balancing ()
Acquire a couple of as the basis for a cluster (AX41-NVME
's are working well, for instance). Visit the and name the servers appropriately.
Refer to the to initialize them properly.
Create a and order an appropriate subnet (it may take a while to show up after the order). Give the vSwitch a name (i.e. ma-k8s-net
) and assign this vSwitch to the servers.
Check out the for help.
Note: does not work with ansible collections and the strategy must be changed (i.e. strategy: linear
).
Check out for more playbooks on cluster management.
For the cluster to operate as a node in the MAYACHain network, deploy as instructed . You can also refer to the , if necessary, or the MAYAChain as a whole.
Visit the and put each server of the cluster into rescue mode. Then execute the following script.
Use Windows Subsystem for Linux -
To prevent a catastrophic mistake in handling multiple nodes, checkout the branch of the node-launcher and preferrably use different repos for each node configuration.
Running a node is a serious undertaking. While Node Operators are well for running a node, there are also , and .
See the to learn more before running a node.
To run a node, you must obtain a significant amount of LP, and minimums . This CACAO is sent into the network as a “bond” and held as leverage on each node to ensure they behave in the best interest of the network.
Node Operators receive rewards if they are bonded and active on the network and are paid out in Cacao. While revenue is generated every block (every 5 seconds) to each operator, those funds are not available to the operator until they churn out of the network. Over time, this incentive increases the median bonded amount, increases the network's security, and allows the network to grow. They're claimed whenever a node leaves the network. See below for more details.
Rewards are affected by Curve. The Incentive Pendulum increases and decreases the amount of CACAO allocated to nodes according to the security and capital leverage of the network.
MAYANodes have the ability to vote on settings.
Mimir settings have specific . The process for voting from a Node is:
Mimir keys and values are listed in the .
Setting up a Kubernetes Cluster with Hetzner Cloud (hcloud)
This approach is only recommended for experienced operators because the kubernetes control plane among other things needs to be managed manually.
hcloud account
hcloud
and hcloud credentials configured
kubectl
ansible
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
Use Windows Subsystem for Linux - https://docs.microsoft.com/en-us/windows/wsl/about****
Firstly, clone and enter the cluster-launcher repository. All commands in this section are to be run inside this repo.
Then install the terraform CLI:
Install Terraform:
The hcloud CLI allows you to manage your hcloud services.
Use the package manager homebrew to install the hcloud CLI.
You will be asked for you Personal Access Token with read/write priveleges (retrieve from API Panel from the hcloud web console.)
API -> Tokens/Keys -> Create Token.
Make sure you handle your secrets securely!
You must install and configure the Kubernetes CLI tool (kubectl). **To install kubectl** , follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install kubectl.
You also need wget and jq, follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install wget and jq Note: You most likely have these installed already.
Initialize the git submodule.
Use direnv
, venv
or whatever you prefer to manage a python environment inside the hcloud folder.
Install dependencies required by Python and Ansible Galaxy.
Use the commands below to deploy an hcloud cluster:
During the deploy, you will be asked to enter information about your cluster:
Name
Token
Confirm yes
Deploying a cluster takes ~15 minutes
If necessary, request a quota increase here.
Now that you've provisioned your hcloud cluster, you need to configure kubectl. Customize the following command with your cluster name and resource group. It will get the access credentials for your cluster and automatically configure kubectl.
You are now ready to deploy a MAYANode.
#102 Jan 27, 2025 Title: Asgardex and Maya Protocol updates. 🔗 Listen here
#101 Jan 20, 2025 Title: Aaluxx and Itzamna 1-on-1 Recap 🔗 Listen here
#100 Jan 13, 2025 Title: MWM #100 Recap: Celebrating a hundred episodes! 🔗 Listen here
#99 Jan 6, 2025
Title: Maya Updates & El Dorito 🔗 Listen here
#98 Dec 30, 2024 Title: V115 and future plans 🔗 Listen here
#97 Dec 23, 2024 Title: KeepKey’s Innovations & Maya Protocol Updates 🔗 Listen here
#96 Dec 16, 2024 Title: Ctrl Wallet and Maya Protocol updates. 🔗Listen Here
#95 Dec 9th, 2024 Title: Maya Protocol and Junction 🔗Listen Here
#94 Dec 2nd, 2024 Title: V112 and V113 🔗Listen Here
#93 Nov 25, 2025 Title: Cross-Chain Milestones: Dash, InLeo, and Maya Protocol. 🔗Listen Here:
#92 Nov 18, 2024 Title: Mondays with Maya x Vultisig 🔗 Listen here
#91: Nov 11, 2024
Title: Exploring the Future of DeFi with Edge Wallet and Maya Protocol 🔗 Listen here
#90: Nov 4, 2024 Title: Reactivation & Validator Success 🔗 Listen here
#89: Oct 28, 2024 Title: Trading Halted & Milestone Records 🔗 Listen here
#88: Oct 14, 2024 Title: Dive into Maya Names 🔗 Listen here
#87: Oct 07, 2024 Title: New Volume Record & Node Testing 🔗 Listen here
#86: Sep 29, 2024 Title: Tier 1 Airdrop Verification & Team Growing 🔗 Listen here
#85: Sep 16, 2024 Title: Version 112 Final Testing 🔗 Listen here
#84: Sep 9, 2024 Title: Astrolecent Partnership 🔗 Listen here
#83: Sep 1, 2024 Title: Snapshot & Version 1.12 Updates 🔗 Listen here
#82: Aug 05, 2024 Title: CacaoSwap & Radix Guests 🔗 Listen here
#81: Jul 29, 2024 Title: Radix Goes Live 🔗 Listen here
#80: Jul 22, 2024 Title: Post-Rare Evo Updates & XRD 🔗 Listen here
#79: Aug 05, 2024 Title: Version 1.11 Preview & New Partnerships 🔗 Listen here
#78: Jul 29, 2024 Title: New Integrations & Project Goals 🔗 Listen here
#77: Jul 22, 2024 Title: Project Roadmap & Tokenomics Discussion 🔗 Listen here
#76: Jul 15, 2024 Title: Mainnet Testing & New Bondable Assets 🔗 Listen here
#75: Jul 08, 2024 Title: Last Testing for Streaming Swaps 🔗 Listen here
#74: Jul 01, 2024 Title: Finalizing v1.10 🔗 Listen here
#73: Jun 24, 2024 Title: Streaming Swap Testing & New Integrations 🔗 Listen here
#72: Jun 17, 2024 Title: Roadmap Growth & Streaming Swaps Strategy 🔗 Listen here
#71: Jun 10, 2024 Title: Validator Node Churn & Streaming Swap Update 🔗 Listen here
#70: Jun 03, 2024 Title: Team Growth & Streaming Swaps Progress 🔗 Listen here
#69: May 27, 2024 Title: XDEFI Integration & Project Roadmap 🔗 Listen here
#68: May 20, 2024 Title: Cardano Progress & Bifrost Setup 🔗 Listen here
#67: May 13, 2024 Title: Rango Exchange Integration & Airdrop Update 🔗 Listen here
#66: May 06, 2024 Title: ThorSwap Launch & Streaming Swaps Sneak Peek 🔗 Listen here
#65: Apr 29, 2024 Title: What’s Next for ThorSwap & v1.10 Updates 🔗 Listen here
#64: Apr 22, 2024 Title: Exploring Zcash Integration 🔗 Listen here
#63: Apr 15, 2024 Title: Arbitrum Live & New Pools on MayaScan 🔗 Listen here
#62: Apr 08, 2024 Title: The Future of DeFi with JP Thor & Chad B 🔗 Listen here
#61: Apr 01, 2024 Title: Turbo Trade Integration & KeepKey News 🔗 Listen here
#60: Mar 25, 2024 Title: Node Launcher & Arbitrum Sync Update 🔗 Listen here
#59: Mar 18, 2024 Title: Future of DeFi with ThorWallet & MayaScan 🔗 Listen here
#58: Mar 11, 2024 Title: Key Points: CacaoSwap Crew, Savers, and Arbitrum Integration. 🔗 Listen here
#57: Mar 04, 2024 Title: CacaoSwap & Upcoming Release Highlights 🔗 Listen here
#56 | Feb 26, 2024 Title: Deep Dive into Fees with ThorChain University 🔗 Listen here
#55 | Feb 19, 2024 Title: Kenso Finance Integration & v1.09 Updates 🔗 Listen here
#54 | Feb 12, 2024
Title: Early Node Snapshots & New Integrations 🔗 Listen here
#53: Feb 05, 2024 Title: Dev Updates & DeFiSpot Insights
https://x.com/i/spaces/1vOxwjPWNzPJB
#52: Jan 29, 2024.
Title: XDEFI Integration Takes Maya to the Next Level - Get Ready for the Epic Launch!
https://twitter.com/i/spaces/1vOGwjBZmqEKB?s=20
#51: Jan 22, 2024.
Title: Churn, Arbitrum, & XDEFI
https://twitter.com/Maya_Protocol/status/1749446939387854954
#50: Jan 15, 2024.
Title: Arbitrum Addition, Refunds for Overpaid Fees, and Rare Shrimp Collection.
https://twitter.com/Maya_Protocol/status/1746910372463009950
#49: Jan 8, 2024.
Title: Get Ready for the NFT Mids Collection.
https://twitter.com/Maya_Protocol/status/1744373674470253006
#48: Jan 2, 2024.
Title: Breakthroughs from Maya Protocol's Latest Meeting! Secrets, Surprises, and More Unveiled!
https://twitter.com/Maya_Protocol/status/1741897158104616990
#47: Dec 18, 2023.
Title: Happy Holidays! WE appreciate your Support This Year.
https://twitter.com/Maya_Protocol/status/1736763373369393233
#46: Dec 11, 2023.
Title: $1 Billion Transactions, Exciting Partnerships, and More!
https://twitter.com/Maya_Protocol/status/1734226620741796030 https://twitter.com/Maya_Protocol/status/1734232460643258430
#45: Dec 4, 2023.
Title: 10,000 Followers, New Integrations, and Special Airdrops Await!
https://twitter.com/Maya_Protocol/status/1731689903228883340
#44: Nov 28, 2023.
Title: New Cardano Catalyst Proposal, Churn Routine Resuming, with Upgrades and Exciting Features
https://twitter.com/Maya_Protocol/status/1729183376383631605
#43: Nov 20, 2023.
Title: "Maya's Tier1 LP Airdrop is Just a Stop - Major Updates and Airdrops Coming Soon!"
https://twitter.com/Maya_Protocol/status/1726616426159784051
#42: Nov 13, 2023.
https://twitter.com/Maya_Protocol/status/1724079763449389333
#41: Nov 06, 2023.
https://twitter.com/Maya_Protocol/status/1721543464892891363
#40: Oct 23, 2023.
https://twitter.com/Maya_Protocol/status/1716469734294839509
#39: Oct 16, 2023.
https://twitter.com/Maya_Protocol/status/1713947967395160501
#38: Oct 9, 2023.
https://twitter.com/Maya_Protocol/status/1711396163323388248
#37: Oct 2, 2023.
https://twitter.com/Maya_Protocol/status/1708859529591464011
#36: Sep 25, 2023.
https://twitter.com/Maya_Protocol/status/1706322760174010536
#35: Sep 18, 2023.
https://twitter.com/Maya_Protocol/status/1703786253618159926
#34: Sep 11, 2023.
https://twitter.com/Maya_Protocol/status/1701249471193952542
#33: Sep 4, 2023.
https://twitter.com/Maya_Protocol/status/1698712993121366120
#32: Aug 28, 2023.
https://twitter.com/Maya_Protocol/status/1696176009110802887
#31: Aug 21, 2023.
https://twitter.com/Maya_Protocol/status/1693639214410105310
#30: Aug 14, 2023.
https://twitter.com/Maya_Protocol/status/1691103455421636608
#29: Aug 7, 2023.
https://twitter.com/Maya_Protocol/status/1688565705711489024
#28: July 31, 2023.
https://twitter.com/Maya_Protocol/status/1686029238544011265
#27: July 24, 2023.
https://twitter.com/Maya_Protocol/status/1683492356643868678
#26: July 17, 2023.
https://twitter.com/Maya_Protocol/status/1680947009866575874
#25: July 3, 2023.
https://twitter.com/Maya_Protocol/status/1675882220748144640
#24: June 26, 2023. https://twitter.com/Maya_Protocol/status/1673346009626206209
#23: June 19, 2023. https://twitter.com/Maya_Protocol/status/1670808614317981696
#22: June 12, 2023
https://twitter.com/Maya_Protocol/status/1666987304785973249
#21: June 5, 2023
https://twitter.com/Maya_Protocol/status/1665535307163525121
#20: May 29, 2023.
https://twitter.com/Maya_Protocol/status/1663198707486015490
#19: May 23, 2023.
https://twitter.com/i/spaces/1ZkKzXrrNVyJv?s=20
#18: May 16, 2023.
https://twitter.com/Maya_Protocol/status/1658140343668441089
#17: May 9, 2023.
https://twitter.com/Maya_Protocol/status/1655603671210639365
#16: May 3, 2023.
https://twitter.com/Maya_Protocol/status/1653444528949305345
#15: April 25, 2023.
https://twitter.com/Maya_Protocol/status/1650545334320345107
#14: April 17, 2023.
https://twitter.com/Maya_Protocol/status/1647978356644651008
#13: April 10,2023.
https://twitter.com/Maya_Protocol/status/1645449202141364224
#12: April 3, 2023.
https://twitter.com/Maya_Protocol/status/1642894658803232769
#11: March 27, 2023.
https://twitter.com/Maya_Protocol/status/1640368305969016833
#10: March 21, 2023.
https://twitter.com/Maya_Protocol/status/1637869579471839235
#9: March 14, 2023.
https://twitter.com/Maya_Protocol/status/1635355237258248192
#8: March 7, 2023.
https://twitter.com/Maya_Protocol/status/1632908951804157952
#7: February 28, 2023.
https://twitter.com/Maya_Protocol/status/1630236344772448256
#6: Maya & Thorwallet - February 21, 2023.
https://twitter.com/Maya_Protocol/status/1627700335836790787
#5: Maya & Halborn - February 13, 2023.
https://twitter.com/Maya_Protocol/status/1625132975607418880
#4: February 7, 2023.
https://twitter.com/Maya_Protocol/status/1622746989724110848
#3: January 31, 2023.
Maya & Thorstarter https://twitter.com/Maya_Protocol/status/1620210390641659912
#2: January 24, 2023.
https://twitter.com/Maya_Protocol/status/1617673467599687680
#1: January 17, 2023.
https://twitter.com/i/spaces/1dRKZMqNNqQxB?s=20
Dash is live on the Maya Protocol: https://twitter.com/Dashpay/status/1684933932645539840
Cosmos Club & Aaluxx: https://twitter.com/CosmosClub_/status/1622881702233141249
LPU & Maya: https://twitter.com/i/spaces/1OwxWwqXXaVxQ
AMA with Danku: https://twitter.com/Maya_Protocol/status/1616118122137657345
THORWallet x Maya integration: https://twitter.com/THORWalletDEX/status/1597528829207392256
Liquidity Auction Tier ROI calculator with Kyle Krason: https://twitter.com/Maya_Protocol/status/1630723295254548482
How to join MAYAChain as an Node.
Now that you have a MAYANode deployed in your Kubernetes cluster, you need to start operating your node to join the network.
There are a couple of steps to follow to do so.
The first wallet to bond their liquidity to a node will be the operator address (i.e. the address that controls the node).
MAYAChain nodes are backed up by added liquidity, just as a normal liquidity provider to one of the supported bonding pools: ARB, BTC, DASH, ETH, KUJI or THOR at the moment.
For now, the only ways to send custom deposit memos are using custom memo deposit on El Dorado or with your node-launcher
setup:
The amount specified in the bond transaction will be sent to your node, which will then be used to set your ip address, version and node keys.
Next, verify your node is running correctly. _**_To check the current status of your node, you can run the command status from the node-launcher
repository on your terminal:
You will get an output along those lines, the example below is for a mainnet node:
Your node is running but as you can see in the `Preflight` section, your node is not yet ready to be churned in and currently is in standby status, since your node has no IP address setup yet.
But to be able to set up the node IP address, you first need to get it registered in the chain by sending your BOND.
Before sending the BOND, verify that your MAYANode is fully synced with connected chains. Connected chains such as Ethereum & Bitcoin may take a day to sync. If your node is fully bonded and is selected to churn into MAYAChain as ACTIVE without fully syncing all connected chains, you will immediately get slashed for missing observations and lose money. It is normal to see Ethereum sit on 99.999% for many hours - be patient.
If you get an error of not having enough balance. Send some cacao to your node
You must tell MAYAChain your IP-Address for its address book and seed-service to run properly:
If you run the status command again, you should now see a different message for the Preflight section saying you need to set your node keys.
Once your IP address has been registered for discovery, you can use your own host for queries.
If you get an error of not having enough balance. Send some cacao to your node
Tell MAYAChain about your public keys for signing sessions:
If you run the make status
command again, you should now see that your node is in status “ready” and is now ready to be churned in the next rotation.
If you get an error of not having enough balance. Send some cacao to your node
Make sure your node broadcasts its latest version, else you won't churn in since MAYAChain enforces a version requirement. This version will appear in your make status
. If you are on 0.0.0
then you haven't set your version:
Although your node is ready to be churned in, it doesn’t mean it will be the next one to be selected, since someone else could have posted a higher bond than you. To maximize chances of a quick entry, monitor Midgard to see what everyone else is bonding and try to outbid them. Keep an eye on maximumStandbyBond
and make sure you are bonding higher than that amount.
The endpoint will show data on average, median, total, minimum and maximum bond amounts. For fastest entry, bond higher than the current maximum.
CACAO is always displayed in 1e8 format, 100000000 = 1 CACAO
At any time during standby or active, you can bond more by adding more liquidity to any LP position of the whitelisted bond providers (including the bond_address
)
Telegram Notification Service
To listen for update announcements, join the following channels:
Telegram MAYANode Announcements Join here
Discord MAYAChain Community Devs Join here especially #mayanode-mccn
Be sure to use a pseudonym in order to prevent doxxing yourself. Node operators should remain anonymous for the health of the network and your personal/node security.
Skilled Node Operators who don't individually have enough Liquidity Units (Asset + CACAO) to run a node themselves can use the Bond Provider feature to collect bond from other Liquidity Providers.
Node Operators can define up to 8 Maya addresses as Bond Providers. These addresses will be able to bond and unbond to the node, earning rewards proportional to the amount of bond they contribute. Node Operators define an operator fee in basis points, which defaults to zero and must be set explicitly when bond providers are added. The Node Operator fee is taken from rewards and paid directly to the Node Operator address after each churn.
The minimum Value of Liquidity Units needed to churn in as a MAYANode can be pricy (currently above $100k).
Not many people in the world have both the technical skills to run a validator AND at least $100k, which limits the supply of Node Operators who secure MAYAChain.
Pooled MAYANodes provide a way for a skilled Operator to enter a trusted agreement with Bond Providers to bootstrap enough capital for running a MAYANode. The Network's security increases, and Liquidity Providers can earn more yield.
At first glance it might seem Pooled Validators contradict the economic security model of MAYAChain (i.e. that Node Operators put up more in value in slash-able bond than the assets they secure). With Pooled Validators it is possible for the Node Operator to individually put up less bond than the value of the assets that the node secures. However this nuance only exists within the relationship between the Node Operator and the Bond Providers. The Network only considers the MAYANode as single entity thus the economic model is intact.
It would be disastrous to MAYAChain if operators could collect unlimited bond quantities from anon/retail providers. Malicious Operators could start marketing campaigns collecting liquidity and then rug-pull their users, or worse, access economies of scale and take over the network.
This is why Pooled MAYANodes are invite-only and limited to 8 per node. It is difficult to access economies of scale in these small quantities.
All CACAO Amount
values are in 1e10 decimals, e.g. 1 CACAO = 10000000000.
Add a bond provider using a BOND transaction with a modified memo from a wallet you control (APP or mayacli):
BOND:<NodeAddress>:<BondProviderAddress>:<NodeOperatorFee>
Example: BOND:maya7djftrgu98z84hef6dt6ykhe7cmjf3f8dcpkfun:maya9diy4q8u50qzsznpvh02s8j483aga63cl02k6jt:2000
NodeAddress - MAYANode address (prefixed by maya
)
BondProviderAddress - Bond Provider address to whitelist (prefixed by maya
)
NodeOperatorFee - fee in basis points to be taken from rewards and paid directly to Node Operator's address after each churn.
CACAO TX Value - 2 minimum (anything over 1 is added to the Operator's Bond).
A Node Operator is the first on-chain bonding transaction to a new node. You cannot change the operator address after the fact.
The Operator is also added as a Bond Provider.
Removing a Bond Provider
While the node is churned out, A Node Operator can remove a Bond Provider using an UNBOND transaction with a modified memo:
UNBOND:<NodeAddress>:<Amount>:<BondProviderAddress>
NodeAddress - MAYANode address (prefixed by maya
)
Amount - amount of Bond Provider's bond to refund
BondProviderAddress - Bond Provider address to refund/remove (prefixed by maya
)
RUNE Tx Value - 1 minimum
This command will refund the Bond Provider their bond and remove them from the Bond Provider list only if Amount
constitutes all of the bond the Bond Provider is owed.
Node operators can set a fee that is paid to them from the earnings each churn.
To set a Node Operator fee, send a deposit transaction with the following memo:
BOND:<node address>:<bond wallet address>:<operator fee in basis pts>
Example: BOND:maya1agftrgu74z84hef6dt6ykhe7cmjf3f8dcpkfun:maya1tfm4q8u57qzsznpvh02s8j483aga63cl02k6jt:2000
To adjust the Fee, The no operators can send:
BOND:<node address>::<operator fee in basis pts>
Example: BOND:maya3guru5gu74z79hef6dt6ykhe7cmjf3f8dcfudge::4000
to see the fee to 40%.
Fees can range from 100 to 9900 basis pts. Setting 10000 causes all rewards to be to the node operator each churn. Setting it to 0 causes rewards to accrue to the bond.
Once whitelisted, a Bond Provider can Bond and Unbond from the node as normal.
Adding Bond:
BOND:<NodeAddress>
NodeAddress - MAYANode address (prefixed by maya
)
CACAO Tx Value - Amount of LP to bond
Removing Bond:
UNBOND:<NodeAddress>:<Amount>
NodeAddress - MAYANode address (prefixed by maya
)
Amount - Amount of LP to unbond
CACAO Tx Value - 1
When can you add Bond?
When the node is standby, active or not churning, bond amounts can be increased/decreased.
Operators and Providers all have a bond amount registered to the node. Operators can start at 0.00 bonded. This on-chain bond amount is summed to the total bond, and thus everyone has a fair share in the MAYANode's principle + Liquidity Pool & transaction fees.
The Operator Fee is distributed to the Node Operator address from all CACAO rewards earned by a node after each churn.
If an Operator LEAVES, all the bond is fairly distributed.
This page describes how to react in a network-wide emergency (funds-at-risk).
MAYAChain is a distributed network. When the network is under attack or a funds-at-risk bug is discovered, Node Operators should react quickly to secure and defend.
Even during emergencies, Node Operators should refrain from doxxing themselves. Staying pseudo-anonymous is critical to ensuring the network is impartial, neutral and resistant to capture.
There is a formal Bounty Program in place for reporting bugs. If you have discovered a bug, you should immediately DM the team or any other admins and/or report via the bounty program. If the bug is deemed to be serious/criticial, you will be paid a bounty commensurate to the severity of the issue. Reports need to include:
Description of the bug
Steps to reproduce
If funds are at risk
Once the bug has been verified, admin should make a decision on the level of response, including any mimir over-rides and announcements:
The network cannot upgrade until 100% of active nodes are on the updated version. This can be accelerated:
Naturally, by allowing the network to churn out old nodes
Assertive, by waiting until a super-majority has upgraded (demonstrating acceptance of the upgrade) than banning old nodes
Forced by hard-forking out old nodes.
During a natural upgrade cycle, it may take several days to churn out old nodes. If the upgrade is time-critical, the network may elect to ban old nodes. Banning a node will cycle them to be churned, kick them from TSS and eject them from the consensus set. That node will never be able to churn in again, they will need to fully leave, destroy their node, and set up a new one. Hard-forking out old nodes is also possible but comes with a significant risk of consensus failures.
The network will not be able to recover until the upgrade is complete, any mimir over-rides are removed, and TSS is re-synced. Additionally, there may be a backlog of transactions that will need to be processed. This may take some time. If external chain daemons were stopped, re-syncing times may also be a factor.
All wallets and frontends should monitor for any of the halts and automatically go into maintenance mode when invoked.
/root/.mayanode/MAYAChain-ED25519 /root/.mayanode/keyring-file/ (directory) /root/.mayanode/config/node_key.json /root/.mayanode/config/priv_validator_key.json
bifrost-recovery.yaml:
If you're maling live migration, then after stopping temporary pods on the NEW node stop mayanode and bifrost daemons on the OLD node
Chain ID: mayachain-mainnet-v1 | Current Node Version: v1.111.0
Install Go
We will use Go v1.22.0
as an example here. The code below also cleanly removes any previous Go installation.
Configure Go
Unless you want to configure in a non-standard way, then set these in the ~/.bash_profile
for bash and ~/.zshrc
for zsh.
Install dependencies protobuf-compiler
Install docker and docker compose plugin
https://docs.docker.com/engine/install/
Install Node
Install the current version of node binary.
*You can see tags in mayanode's repo tags
Install binary
Run Node
Create Service File
Create a mayanode.service
file in the /etc/systemd/system
folder with the following code snippet. Make sure to replace USER
with your Linux username. You need sudo privilege to do this step.
Download Snapshot
Please use a snapshot in order to avoid syncing from start. You will need to install aws-cli
Start Node Service
Other Considerations
This installation guide is the bare minimum to get a node started. You should consider the following as you become a more experienced node operator.
Configure firewall to close most ports while only leaving the p2p port (typically 27146) open
Use custom ports for each node so you can run multiple nodes on the same server
If you find a bug in this installation guide, please reach out to our Discord Server and let us know.
Create and manage a MAYAName to earn fees and monitor your integration.
MAYANames are MAYAChain's vanity address system that allows affiliates to collect fees and track their user's transactions. MAYANames exist on the MAYAChain L1, so you will need a MAYAChain address and $CACAO to create and manage a MAYAName.
MAYANames have the following properties:
Name: The MAYAName's string. Between 1-30 hexadecimal characters and -_+
special characters.
Owner: This is the MAYAChain address that owns the MAYAName
Aliases: MAYANames can have an alias address for any external chain supported by MAYAChain, and can have an alias for the MAYAChain L1 that is different than the owner.
Expiry: MAYAChain Block-height at which the MAYAName expires.
Preferred Asset: The asset to pay out affiliate fees in. This can be any asset supported by MAYAChain.
Affiliate Basis Points: The default fee percentage (in basis points) charged when the MAYAName is specified as an affiliate during swaps or when adding liquidity.
Subaffiliates: MAYANames can have subaffiliates for revenue sharing. Each subaffiliate has an associated fee share percentage (in basis points).
MAYANames are created by posting a MsgDeposit
to the MAYAChain network with the appropriate memo and enough $CACAO to cover the registration fee and to pay for the amount of blocks the MAYAName should be registered for.
Registration fee: TNSREGISTERFEE
on the Mimir endpoint. This value is in 1e10, so 10000000000 = 1 $CACAO
Per block fee: tns_fee_per_block_rune
on the same endpoint, also in 1e10.
For example, for a new MAYAName to be registered for 10 years the amount paid would be:
amt = TNSREGISTERFEE + TNSFEEPERBLOCK * 10 * 5256000
5256000 = avg # of blocks per year
The expiration of the MAYAName will automatically be set to the number of blocks in the future that was paid for minus the registration fee.
Memo Format
The accepted memo template is:
~:name:?chain:?address:?owner:?preferredAsset:?expiry:?affialiateBps:?subaffiliate[/subaffiliate2...]:?subaffiliateBps[/subaffiliateBps2...]
Memo Parameters:
name: Your MAYAName. Must be unique, between 1-30 characters, hexadecimal and -_+
special characters.
chain: (Optional) The chain of the alias to set. If MAYAName already exists, chain
is optional.
address: (Optional) The alias address. Must be an address of chain. If MAYAName already exists, address
is optional.
owner: (Optional) MAYAChain address of owner.
preferredAsset: (Optional) Asset to receive fees in. Must be supported by an active pool on MAYAChain. Value should be asset
property from the Pools endpoint. If MAYA.CACAO is set as the preferred asset, affiliate fees will be sent directly to the MAYA alias as if the preferred asset was not set.
expiry: (Optional) The expiration block height for the MAYAName.
affiliateBps: (Optional) Default affiliate basis points (fee percentage) used when the MAYAName is specified as an affiliate during swaps or when adding liquidity. Value is in basis points (e.g., 200 for 2%). The maximum value is 200.
subaffiliate: (Optional) Subaffiliate MAYAName for revenue sharing. You can provide more "/" separated subaffiliates. The number of subaffiliates must be equal to the number of subaffiliateBps provided in next parameter.
subaffiliateBps: (Optional) Basis points for the subaffiliate's fee share (e.g., 2000 for 20%). You can provide more "/" separated subaffiliateBps. The number of subaffiliateBps must be equal to the number of subaffiliates provided in the previous parameter.
Example: ~:AALUXX:BTC:bc1Address:mayaAddress:BTC.BTC
This will register a new MAYAName called AALUXX with a Bitcoin alias of bc1Address
owner of mayaAddress
and preferred asset of BTC.BTC.
Example: ~:AALUXX2:MAYA:maya1address::THOR.RUNE::50
This will register a new MAYAName called AALUXX2 with a MayaChain alias of maya1Address
, a preferred asset of THOR.RUNE
, and an Affiliate Basis Points value of 50
(0.5% affiliate fee).
Example: ~:AALUXX3:BTC:bc1Address:::::SUBA:2000
This will register a new MAYAName called AALUXX3 with a Bitcoin alias of bc1Address
and a subaffiliate called SUBA
with a fee share of 2000 basis points (20%). If the MAYAName AALUXX3 already exists, it will simply set the Bitcoin alias and add the SUBA
subaffiliate to the existing MAYAName.
Example: ~:AALUXX4:BTC:bc1Address:::::SUBA:0
If the MAYAName AALUXX4 exists, this will change the Bitcoin alias to bc1Address
and remove the SUBA
subaffiliate from the subaffiliate list of AALUXX4. If AALUXX4 doesn't exist, it will register a new MAYAName called AALUXX4 with a Bitcoin alias of bc1Address
. Since the newly registered MAYAName does not have the SUBA
subaffiliate, this part of the memo will have no effect.
Example: ~:AALUXX4:MAYA:maya1address::THOR.RUNE::500:SUBA:2000
This will register or change AALUXX4's MayaChain alias tomaya1Address
, preferred asset to THOR.RUNE
, default affiliate basis points to 500 (5%) and adds SUBA as a subaffiliate with a fee share of 2000 basis points (20%).
Example: ~:AALUXX4::::::100:SUBA1/SUBA2:2000/3000
This will add SUBA1
and SUBA2
as subaffiliates with fee shares of 2000
and 3000
respectively (20%
and 30%
) for existing AALUXX4
MAYAName.
You can use Asgardex to post a MsgDeposit with a custom memo. Load your wallet, then open your MAYAChain wallet page > Deposit > Custom.
View your MAYAName's configuration at the MAYAName endpoint:
e.g. https://mayanode.mayachain.info/mayachain/mayaname/{name}
All MAYAName's have a expiration represented by a MAYAChain block-height. Once the expiration block-height has passed, another MAYAChain address can claim the MAYAName and any associated balance in the Affiliate Fee Collector Module (Read Preferred Asset for Affiliate Fees ), so it's important to monitor this and renew your MAYAName as needed.
To keep your MAYAName registered you can extend the registration period (move back the expiration block height), by posting a MsgDeposit
with the correct MAYAName memo and $CACAO amount.
Memo:
~:AALUXX:MAYA:<maya-alias-address>
(Chain and alias address are required, so just use current values to keep alias unchanged)
$CACAO Amount:
cacao_amt = num_blocks_to_extend * tns_fee_per_block
(Remember this value will be in 1e10, so adjust accordingly for your transaction)
Starting in MAYANode V112, affiliates can collect their fees in the asset of their choice (choosing from the assets that have a pool on MAYAChain). In order to collect fees in a preferred asset, affiliates must use a MAYAName in their swap memos.
If an affiliate'sMAYAName has the proper preferred asset configuration set, the network will begin collecting their affiliate fees in $CACAO in the AffiliateCollector module. Once the accrued CACAO in the module is greater than PreferredAssetOutboundFeeMultiplier
* outbound_fee
of the preferred asset's chain, the network initiates a swap from $CACAO -> Preferred Asset on behalf of the affiliate. At the time of writing, PreferredAssetOutboundFeeMultiplier
is set to 100
, so the preferred asset swap happens when the outbound fee is 1% of the accrued $CACAO.
Configuring a Preferred Asset for a MAYAName
Register your MAYAName following instructions above.
Set your preferred asset's chain alias (the address you'll be paid out to), and your preferred asset. Note: your preferred asset must be currently supported by MAYAChain.
For example, if you wanted to be paid out in USDC you would:
Grab the full USDC name from the Pools endpoint: ETH.USDC-0XA0B86991C6218B36C1D19D4A2E9EB0CE3606EB48
Post a MsgDeposit
to the MAYAChain network with the appropriate memo to register your MAYAName, set your preferred asset as USDC, and set your Ethereum network address alias. Assuming the following info:
MAYAChain address: maya1g8dzs4ywxhf8hynaddw4mhwzlwzjfccakkfch7
MAYAName: wr
ETH payout address: 0x6621d872f17109d6601c49edba526ebcfd332d5d
The full memo would look like:
You can use Asgardex to post a MsgDeposit with a custom memo. Load your wallet, then open your MAYAChain wallet page > Deposit > Custom.
You will also need a MAYA alias set to collect affiliate fees. Use another MsgDeposit with memo: ~:wr:MAYA:<mayachain-address>
to set your MAYA alias. Your MAYA alias address can be the same as your owner address, but won't be used for anything if a preferred asset is set.
You can also set one or more subaffiliates to share revenue from affiliate fees. Use another MsgDeposits with memos:
~:wr:500:SUBA1:2000
~:wr:500:SUBA2:1000
If MAYA.CACAO is set as the preferred asset, the affiliate fees are not accumulating in the affiliate collector, instead they are sent directly to the MAYA alias address on every swap. If MAYA alias is not set in MAYAName, MAYANAme Owner address is used.
Once you successfully post your MsgDeposit you can verify that your MAYAName is configured properly. View your MAYAName info from MAYANode at the following endpoint: https://mayanode.mayachain.info/mayachain/mayaname/wr
The response should look like:
Your MAYAName is now properly configured and any affiliate fees will begin accruing in the AffiliateCollector module. You can verify that fees are being collected by checking the affiliate_collector_cacao
value of the above endpoint.
Affiliates can specify subaffiliates to share revenue from affiliate fees. This allows for nested affiliate relationships and revenue sharing models.
Multiple Affiliates and Subaffiliates are effective only for swaps. Subaffiliates are not considered when adding or removing liquidity.
Calculating Affiliate Fee Shares
The affiliate fee is split among the affiliate and its subaffiliates based on their specified basis points.
In case of swap affiliate shares fees are recursively calculated for each affiliate and its nested subaffiliates, ensuring the total does not exceed 100% of the affiliate fee.
Let's take the folowing example:
The cat
affiliate MAYAName operates with a 1.5% fee. From this, fox
MAYAName receives 30% and pig
MAYAName gets 20%. Additionally, fox
passes 40% of its share to its sub-sub-affiliate MAYName, frog
.
Resulting distribution:
cat: 0.75%
fox: 0.27% (60% of 30% of 1.5%)
pig: 0.3% (20% of 1.5%)
frog: 0.18% (40% of 30% of 1.5%).
Here are the MsgDeposit memos used in this example:
Some node operators may desire to run multiple validators within the same cluster, while sharing a single set of daemons among them to save resource cost. This can be performed via the following method. These instructions are relevant for mainnet at the time of writing, but please ensure that correct network and current set of daemons are used.
https://gitlab.com/mayachain/devops/node-launcher/-/blob/master/docs/Multi-Validator-Cluster.md
TBA
Deploying a MAYANode and its associated services.
Now you have a Kubernetes cluster ready to use, you can install the MAYANode services.
Helm charts are the defacto and currently easiest and simple way to package and deploy Kubernetes application. The team created different Helm charts to help to deploy all the necessary services. Please retrieve the source files from the Git repository here to follow the instructions below:
Running Kubernetes cluster
Kubectl configured, ready and connected to running cluster
If you came here from the Setup page, you are already good to go.
Clone the node-launcher
repo. All commands in this section are to be run inside of this repo.
Install Helm 3 if not already available on your current machine:
To deploy all tools, metrics, logs management, Kubernetes Dashboard, run the command below.
To destroy all those resources run the command below.
If you are successful, you will see the following message:
If there are any errors, they are typically fixed by running the command again.
It is important to deploy the tools first before deploying the MAYANode services as some services will have metrics configuration that would fail and stop the MAYANode deployment.
Currently MAYAChain supports ARB, BTC, ETH, DASH, KUJI & THOR. For all of the chains that we support a fullnode is used in order to read transactions from them. Sync time varies from chain to chain, but there's a couple of things you can do to speed up some of them:
By default the fullnode of ETH will connect checkpoint node provided by Maya Protocol. If you want to customize the checkpoint node to use you can edit the checkpoint_url
in ethereum-daemon/values.yaml
attribute.
In order to sync THOR from a ninerealms snapshot you need to explicitly enable it by setting recover: true
in thornode-daemon/values.yaml
.
You have multiple commands available to deploy different configurations of MAYANode. You can deploy mainnet or stagenet (currently not churning in third-party nodes). The commands deploy the umbrella chart mayanode-stack
in the background in the Kubernetes namespace mayanode
(or mayanode-stagenet
for stagenet) by default.
If you are intending to run all chain clients, bond in & earn rewards, you want to choose "validator".
Once it's all deployed you'll need to sync from a snapshot.
We recommend choosing the defaults, but in case you have a specific need you can choose otherwise.
You are now ready to join the network:
Set mayanode
to be your default namespace so you don't need to type -n mayanode
each time:
kubectl config set-context --current --namespace=mayanode
Use the following useful commands to view and debug accordingly. You should see everything running and active. Logs can be retrieved to find errors:
Kubernetes should automatically restart any service, but you can force a restart by running:
Note, to expedite syncing external chains, it is feasible to continually delete the pod that has the slow-syncing chain daemon (eg, binance-daemon-xxx).
Killing it will automatically restart it with free resources and syncing is notably faster. You can check sync status by viewing logs for the client to find the synced chain tip and comparing it with the real-world blockheight, ("xxx" is your unique ID):
Get real-world blockheights on the external blockchain explorers, eg: BTC Explorer
mayanode: Umbrella chart packaging all services needed to run a fullnode or validator MAYANode.
This should be the only chart used to run MAYANode stack unless you know what you are doing and want to run each chart separately (not recommended).
mayanode: MAYANode daemon
gateway: MAYANode gateway proxy to get a single IP address for multiple deployments
bifrost: Bifrost service
midgard: Midgard API service
mayachain-daemon: Mayachain fullnode daemon
arbitrum-daemon: Arbitrum fullnode daemon
bitcoin-daemon: Bitcoin fullnode daemon
dash-daemon: Dash fullnode daemon
ethereum-daemon: Ethereum fullnode daemon
kuji-daemon: Kujira fullnode daemon
thornode-daemon: Thorchain fullnode daemon
chain-daemon: as required for supported chains
prometheus: Prometheus stack for metrics
loki: Loki stack for logs
kubernetes-dashboard: Kubernetes dashboard
Setting up a Kubernetes Cluster with Digital Ocean (DO)
DO account
doctl
and DO credentials configured
kubectl
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
Use Windows Subsystem for Linux - https://docs.microsoft.com/en-us/windows/wsl/about****
Firstly, clone and enter the cluster-launcher repository. All commands in this section are to be run inside this repo.
Then install the terraform CLI:
Install Terraform:
The Digital Ocean Control tool allows you to manage your DO services.
Use the package manager homebrew to install the DO CTL.
You will be asked for you Personal Access Token with read/write priveleges (retrieve from API Panel from the Digital Ocean web console.)
API -> Tokens/Keys -> Create Token.
Make sure you handle your secrets securely!
You must install and configure the Kubernetes CLI tool (kubectl). **To install kubectl** , follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install kubectl.
You also need wget and jq, follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install wget and jq Note: You most likely have these installed already.
Use the commands below to deploy a DOKS cluster:
During the deploy, you will be asked to enter information about your cluster:
Name
DO Region -- see valid List of Regions (use lower-case)
Confirm yes
Final success message: Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Deploying a cluster takes ~10 minutes
Now that you've provisioned your DOKS cluster, you need to configure kubectl. Customize the following command with your cluster name and region.
If successful, you will see:
Test this configuration,
To verify, run this, and check the status is "Ready":
You are now ready to deploy a MAYANode.
How to leave MAYAChain
Every 3 days the system will churn its nodes. The exact churn interval in blocks is ChurnInterval in the MAYAChain Constants.
Outgoing:
Nodes wishing to leave, and/or
The most unreliable node(s), and/or
The oldest node
But a maximum of 1/3rd the network
Incoming:
The node(s) with the highest bond (typically 4).
Churned out nodes will be put in standby, but their bond will not automatically be returned. They will be credited any earned rewards in their last session. If they do nothing but keep their cluster online, they will be eventually churned back in.
Alternatively, an "Active" node can leave the system voluntarily, in which case they are marked to churn out first. Leaving is considered permanent, and the node-address is permanently jailed. This prevents abuse of the LEAVE system since leaving at short notice is disruptive and expensive.
It is assumed nodes that wish to LEAVE will be away for a significant period of time, so by permanently jailing their address it forces them to completely destroy and re-build before re-entering. This also ensures they are running the latest software.
Yggdrasil vaults have been deprecated, see ADR-002. They may be used again in the future. Nodes that were active before ADR-002 need to leave as described below.
You cannot unbond if you are "Ready" or "Active" or have any amount of funds in your Yggdrasil address
If a Node Operator wants to retrieve part of their bond & rewards (such as deciding to take profits), they can simply Unbond. This keeps their Node on standby, ready to be churned back in.
To unbond from the system, simply send an UNBOND transaction.
Example, this will draw out 10k in CACAO from the bond, as long as the remaining amount is higher than the minimum bond.
UNBOND:maya1ryr5eancepklax5am8mdpkx6mr0rg4xjnjx6zz:1000000000000
MAYAChain always treats assets in 1e8 'base format' ie, 1.0 CACAO = 100,000,000 units (tor). To get from one to the other, simply multiply by 100m.
If using ASGARDEX to BOND or UNBOND, simply put the CACAO amount, e.g. "100" for 100 CACAO. It does the memo in 1e8 for you.
You can get your node address by running make status
Only the address that originally bonded the funds can UNBOND or LEAVE. This ensures you can safely leave this system if you no longer have access to your node (but it is still running).
If you can't UNBOND, it means your ygg-vault still has funds on it. This means your node spent more gas than it was supposed to during the cycle (various reasons) and is partially insolvent. To fix this you need to rectify your node's insolvency first (send it the missing funds directly) before doing anything.
Leaving is considered permanent. There are two steps.
If you are Active, send a LEAVE transaction to be ear-marked to churn out. This will take several hours even after changing your status to 'Standby'.
If you are Standby, send a LEAVE transaction to get your bond back and be permanently jailed.
Prior to running a mainnet validator, you should practice a full sequence of deploy, BOND in and LEAVE on a testnet cluster to ensure you know what you are doing and what to expect.
To leave the system, send the following transaction from your original bond address to the Vault Address: LEAVE:<ADDRESS>
with at least 1 tor in funds. Or use ASGARDEX.
Example:
LEAVE:maya1ryr5eancepklax5am8mdpkx6mr0rg4xjnjx6zz
⏱_Wait a few hours, verify on the /nodeaccount endpoint that you are now **Disabled
**👀_ Then send another LEAVE:
LEAVE:maya1ryr5eancepklax5am8mdpkx6mr0rg4xjnjx6zz
⏱_Wait a few minutes, verify you have received your bond back 👀_ - make status
should show BOND 0.00
and your wallet should get the full Bond back.
Sometimes your Yggdrasil ETH vault may be slightly insolvent due to out-of-gas transactions consuming gas whilst Active. If the network will not let you LEAVE, you may need to manually send your Yggdrasil ETH vault 0.01 - 0.05 ETH from your own personal funds as a top-up, then try LEAVE again. Note: any funds you send to top-up ETH vault you cannot send back to yourself until AFTER your node has left and you have received your bond back, otherwise it will be fined 1.5x what you transfer out.
View your node's vault to find insolvencies: https://viewblock.io/mayachain/address/<nodeAddress> https://mayanode.mayachain.info/mayachain/vault/<vaultPubKey>
🔥 Commence destroying your node 🔥
If your node is both offline and inaccessible, then it will be unable to automatically return any assets in its yggdrasil vaults and it will be slashed 1.5x the value of those assets.
Example: If your node has a $5m bond (in CACAO), but has $1m in assets in its vaults it can't return, it will lose $1.5m in CACAO from its bond. The Node will only get back $3.5m of its bond.
If your node is completely offline or destroyed, you will have to perform a manual return of Yggdrasil funds in order to prevent 1.5x bond fine. Ensure you have reviewed this procedure and have all tools ready to go in case you need to do it in anger. This is a time-critical event - you have a few hours to return all funds before the network assumes you have stolen them.
If you do not perform all of these steps in time, your bond will be fined 1.5x stolen funds. The remaining funds belonging to Yggdrasil make mnemonic
are now yours; but you just paid a 50% premium for them, losing a lot of money. You can use the following procedure in a similar way to recover these funds.
Requirement: You have your make mnemonic
Yggdrasil mnemonic available. If you do not have this, you cannot manually return funds.
Options: 1. Coming Soon: Use ASGARDEX for Manual Return. 2. Coming Soon: Check Discord Dev channels for manual return cli tool. 3. Extract Private Key + Manual return each asset using wallets:
Your Yggdrasil make mnemonic
phrase is used to generate the m/44'/931'/0'/0/0
private key which is used for all chains. Pasting the mnemonic into common wallets will not work as they will be looking under a different "standard" HD Path. Instead, go to https://iancoleman.io/bip39/ and paste in your mnemonic, select CACAO from the Dropdown list and in the bottom table, copy the m/44'/931'/0'/0/0
private key string. Use this to import into wallets.
The next step is to find the latest inbound addresses. Use https://mayanode.mayachain.info/mayachain/inbound_addresses
Do not cache inbound_addresses. These are only valid for a short period of time. Always refresh to get the latest before sending funds.
Use the address field. Chains with a router present such as ETH need to send funds via the router smart-contract. Paste the router address into etherscan, click "Contract" and "Write Contract" and use a Web3 wallet to connect.
The memo required is YGGDRASIL-:<BlockHeight>
. For example YGGDRASIL-:782412
. The block height can be found from the status_since
field here:
If your node is standby
or disabled
status, any integer block height will work for return. e.g. YGGDRASIL-:1
. The most important thing is to ensure you send to the correct active vault address or router.
For BTC wallets (BTC, Litecoin) use importprivkey
in cli.
For ETH router manual returns, use the deposit()
function for individual assets. For ETH use contract 0x0
. Use the returnVaultAssets()
for multiple assets.
You should complete this checklist before you do the next step:
Have you sent a final LEAVE transaction and have you received your BOND back - ie 1,000,000 CACAO, and can your account for any slash points or rewards?
If yes, then proceed:
To destroy and remove previously created resources, you can run the command below.
Destroying your cluster will completely destroy your node, including purging all keys on it.
DO NOT DO THIS UNTIL YOUR NODE HAS CHURNED OUT AND YOU HAVE VERIFIED YOUR BOND IS COMPLETELY RETURNED
IF YOU DESTROY A NODE PREMATURELY, YOU MAY LOSE A SIGNIFICANT AMOUNT OF FUNDS
First, destroy the node and tools, this will delete your node then your tooling 1-by-1. Do this from the node-launcher
repo:
Then destroy the cluster from the cluster-launcher
repo:
You will be asked to enter your cluster name and region (the same as what you put in when you first deployed).
You will be asked to enter your cluster name and region, as well as your Personal Token (the same as what you put in when you first deployed).
You will be asked to confirm:
DO NOT DESTROY YOUR NODE UNTIL YOU HAVE CHURNED OUT AND HAVE RECEIVED YOUR FULL BOND BACK IN YOUR CUSTODY
IF YOU DESTROY YOUR NODE WITH FUNDS LOCKED UP - YOU WILL LOSE A SIGNIFICANT QUANTITY OF FUNDS
Accessing Logs, Metrics and more
The Makefile provide different commands to help you operate your MAYANode.
There are two types of make commands, READ and WRITE.
Run make help
at any stage to get an exhaustive list of help options and how to interact with the system.
Read commands simply read your node state and doesn't commit any transactions.
To get information about your node on how to connect to services or its IP, run the command below. You will also get your node address and the vault address where you will need to send your bond.
Opens a shell into your thor-daemon
deployment: From within that shell you have access to the thorcli
command.
Display stream of logs of MAYANode deployment:
This will print your node mnemonic (phrase). Use this to ever rescue your node funds if something goes wrong.
Note: This phrase should only be used "in anger". This is your node "hot vault", also referred to as its yggdrasil vault, which allows the network to delegate swaps for faster execution. You will be slashed significantly if any funds are moved from this vault, since it is monitored by the MAYAChain network. Your bond is held at ransom in order to prevent you from stealing funds from this vault. Your bond will always be more valuable than funds on this vault, so you have no economic reason to touch these funds.
A keystore file that secures your private keys is also stored on the MAYANode. The password that is used to decrypt it can be printed by the following command
Restart a MAYANode deployment service selected:
Reset a MAYANode deployment service selected, including deleting the persistent volume. This command is destructive and will reset the chain back to 0%. You would use this for unrecoverable issues that make restart
did not solve.
Write commands actually build and write transactions into the underlying statechain. They cost CACAO from your bond, currently 0.02, but you can check this on the /constants
endpoint "CLICOSTINCACAO". This will post state in the chain which will be now updated globally. The CACAO fee is to prevent DDoS attacks.
Send a set-node-keys
to your node, which will set your node keys automatically for you by retrieving them directly from the maya-daemon
deployment.
Send a set-ip-address
to your node, which will set your node ip address automatically for you by retrieving the load balancer deployed directly.
In order to update your MAYANode to a new version, you will need to update the docker tag image used in your deployments. Depending on your choice of deployment this can be done differently.
For Kubernetes deployments, you can edit the deployments of the different services you want to update using the commands below.
To update your thor-daemon
, thor-api
and bifrost
deployment images to version 0.2.0:
To update your `midgard` deployment image to version 0.2.0
You can then follow the deployments restarting status either by checking your Kubernetes dashboard or using the CLI command below:
Once the deployments are all in the ready state again, you need to broadcast to the network that you are running a new version using the command below:
Note, all of these should already be installed from make tools
. However you can install them separately useing the DEPLOY tabs below.
To access the tools, navigate to the ACCESS tabs below.
All of these commands are to be run from node-launcher
It is recommended to deploy a logs management ingestor stack within Kubernetes to redirect all logs within a database to keep history over time as Kubernetes automatically rotates logs after a while to avoid filling the disks. The default stack used within this repository is Loki, created by Grafana and open source. To access the logs you can then use the Grafana admin interface that was deployed through the Prometheus command.
You can deploy the log management automatically using the command below:
This command will deploy the Loki chart. It can take a while to deploy all the services, usually up to 5 minutes depending on resources running your kubernetes cluster.
You can check the services being deployed in your kubernetes namespace loki-system
.
Access Grafana
See previous section to access the Grafana admin interface through the command make grafana
.
Browse Logs
Within the Grafana admin interface, to access the logs, find the Explore
view from the left menu sidebar. Once in the Explore
view, select Loki as the source, then select the service you want to show the logs by creating a query. The easiest way is to open the "Log browser" menu, then select the "job" label and then as value, select the service you want. For example you can select mayanode/bifrost
to show the logs of the Bifrost service within the default mayanode
namespace when deploying a mainnet validator MAYANode.
Destroy Loki logs management stack
It is also recommended to deploy a Prometheus stack to monitor your cluster and your running services.
You can deploy the metrics management automatically using the command below:
This command will deploy the prometheus chart. It can take a while to deploy all the services, usually up to 5 minutes depending on resources running your kubernetes cluster.
You can check the services being deployed in your kubernetes namespace prometheus-system
.
We have created a make command to automate this task to access Grafana from your local workstation:
Open http://localhost:3000 in your browser.
Login as the admin
user. The default password should have been displayed in the previous command (make grafana
).
Access Prometheus admin UI
We have created a make command to automate this task to access Prometheus from your local workstation:
Open http://localhost:9090 in your browser.
As part of the tools command deployment, you also have deployed a Prometheus stack in addition to the Elasticsearch in your Kubernetes cluster. All CPU, memory, disk space, and MAYANode / MAYAChain custom metrics are automatically being sent to the Prometheus database backend deployed in your cluster.
You should have available different dashboards to see the metrics across your cluster by nodes, deployments, etc, and also a specific MAYANode / MAYAChain
dashboard to see the MAYAChain status, with current block height, how many validators are currently active and other chain related information.
Click the 🔍 SEARCH ICON to find the list of dashboards
For a more in-depth introduction of Grafana, please follow the documentation here.
You can also deploy the Kubernetes dashboard to monitor your cluster resources.
This command will deploy the Kubernetes dashboard chart. It can take a while to deploy all the services, usually up to 5 minutes depending on resources running your kubernetes cluster.
We have created a make command to automate this task to access the Dashboard from your local workstation:
Open http://localhost:8000 in your browser.
View your kubernetes dashboard by running the following:
You should backup your MAYANode in case of failures. By default, if you are using the Kubernetes deployments solution, all the the deployments are automatically backed up by persistent volume disks. Depending on your provider, the volumes are usually available in the provider administration UI, for example in AWS, you can find those volumes in your regular console, in the region you chose to deploy your Kubernetes cluster.
Again by default, with Kubernetes, by using persistent volumes used in the default configuration, you are already protected again restart failures at container level, or node failures. As long as you don’t specifically use the destroy commands from the Makefile or manually delete your Kubernetes deployments, your volumes will NOT be deleted at any time.
It is still recommended, as any project, to have different backups on top of those volumes to make sure you can recover in admin error deleting those volumes or other Kubernetes resources that would imply deleting those volumes.
For AWS, you can easily setup in your console to have snapshots of your cluster volumes be taken every day. For other provider there can be different ways to achieve this as well either manually or automatically.
It is up to the node operator to setup those extra backups of the core volumes to be able to recover in any kind of failures or human errors.
Some volumes would be more critical than others, for example Midgard deployment are also by default backed up by persistent volumes, so it can recover in case of container restarts, failures or node failures and the deployment being automatically scheduled to a different node, but if you were to delete the Midgard volume, it would reconstruct its data from your MAYANode API and events from scratch. For that specific service having extra backups might not be critical, at the time of the writing of that document, Midgard implementation might change in the future.
At minimum you should also securely backup your node keys: node_key.json
and priv_validator_key.json
. Do this as follows:
Copy the mayanode pod name, e.g. mayanode-abcdefg-hijkl
and replace with {mayanode pod name}
below:
For full disaster recovery (complete loss of cluster), it is possible to issue LEAVE command from the original BOND wallet and manual return of funds from your Yggdrasil. In this case you need a secure backup of make mnemonic
(Yggdrasil mnemonic) and a working wallet that did the original BOND. See Leaving.
The following are attack vectors:
If anyone accesses your cloud credentials, they can log in and steal your funds
If anyone accesses the device you used to log into kubernetes, they can log in and steal your funds
If anyone accesses your hardware device used to bond, they can sign a LEAVE transaction and steal your bond once it is returned
If anyone has your Yggdrasil make mnemonic
phrase, including in logs, they can steal your funds
If any GitLab repo is compromised and you git pull
any nefarius code into your node and run make <any command>
, you can lose all your funds.
Prior to git pull
or make pull
updates, review node-launcher repo diffs:
Regularly review patches in GitLab: https://gitlab.com/mayachain/devops/node-launcher/-/commits/multichain
When chain clients have updated tags (version number or sha256), inspect the GitLab diffs for the relevant image in https://gitlab.com/mayachain/devops and ensure the CI build checksum matches the expected. This ensures you are executing code on your node that you are satisfied is free from exploits. Some images such as Ethereum use the 'official' docker image, e.g. https://hub.docker.com/r/ethereum/client-go/tags.
RUNNING A NODE IS SERIOUS BUSINESS
DO SO AT YOUR OWN RISK, YOU CAN LOSE A SIGNIFICANT QUANTITY OF FUNDS IF AN ERROR IS MADE
MAYANODE SOFTWARE IS PROVIDED AS IS - YOU ARE SOLELY RESPONSIBLE FOR USING IT
YOU ARE RESPONSIBLE FOR THE CODE RUNNING ON YOUR NODE. YOU ARE THE NETWORK. INSPECT ALL CODE YOU EXECUTE.
At the moment , there are five external chain get connected to MAYAChain, there are
Binance Chain
Bitcoin
Bitcoin cash
Litecoin
Ethereum
Each node has a unique address on each supported chain. This is their Yggdrasil vault. The network will fund all nodes Yggdrasil vaults and instruct them to perform small transactions in order to lower the number of computationally expensive TSS signatures.
To find your Yggdrasil addresses, firstly navigate to https://viewblock.io/mayachain/vaults
Find your node address and click on the link.
Alternatively, visit any mayachain endpoint using your node address from make status
:
Copy your secp256k1
public key and put it here:
And look for addresses
array at the bottom.
Run make mnemonic
and securely store this.
Visit https://iancoleman.io/bip39/ - or for more safety, clone the GitHub repo and open src/index.html
offline.
Paste in your mnemonic and choose CACAO - MAYAChain from the drop-down list.
Your private key string is the first one: m/44'/931'/0'/0/0
When running a node, it is quite common to get slashed. The network relies on slash points to rate node quality. When your node is slashed, the first thing you need to do is run make status
, and make sure all your chains are 100% in sync. If any of the external chains are not 100% in sync, then it will cause node to be slashed due to missing observations.
The best prevention is to have a cluster with lots of fast resources (cpu, memory, IO, network) and good backups/redundancy to prevent downtime.
Unfortunately even when your node is fully in-sync, it is still possible to be slashed due to external chain events. Here are some of the scenarios:
When a node is slashed 600 points, it is typically because the yggdrasil vault failed to send an outbound transaction (more accurately: the transaction it was tasked to perform wasn't mined within a specified time limit). This most likely to happen on ETH chain. Here is what you need to check:
Find your Yggdrasil ETH address. Use the previous instructions.
Visit https://etherscan.io/ and paste in your Yggdrasil ETH address.
Potential problem 1: Transaction ran out of Gas (wrong estimate):
Cause: The network uses geth
inbuilt eth_estimateGas
function to estimate how much gas to set as limit for a transaction. On rare occasions this can return a number too low causing the transaction to fail. In this case there is nothing you can do - just wait it out. Note: your Yggdrasil ETH vault is now insolvent by a small amount of gas burned in the failed transaction that you will need to personally top-up prior to LEAVE. See section on LEAVE for more details.
Potential problem 2: Transaction didn't mine after 15mins
Cause: External unexpected Gas price hike. The network uses a 1.5x the previous N blocks as the gas rate to use. If there is a sudden increase in Gas price required due to unforseen external events, the transaction may not be mined. In order to make sure customer is paid in a reasonable time, there is a auto cancel transaction process build in bifrost. The network will keep monitoring the outbound transactions and if any of the outbound transaction signed out by yggdrasil vault didn't commit after 15 minutes, it will automatically cancel it and assign to another node to send.
You should be able to see a transaction like the following, which is sending 0
ETH back to itself which cancels anything pending:
If your node is slashed 600 points continuously, it is likely your ETH vault is stuck or transactions sent to your local geth aren't propagated fully into mempools used by miners. This might happen if your local ethereum-daemon doesn't sync well with the network, even though it reports 100% in sync.
Run make logs
and choose bifrost
Search your logs for cancel
and look for transactions such as:
Find the last cancel tx in the logs (with the highest nonce).
Search etherscan for the new tx hash
transaction ID.
Your geth is stuck and out of sync if etherscan does NOT find the new tx hash
cancelled transaction. If you do not find your tx in etherscan - proceed as follows:
Find the lowest nonce from Etherscan:
Go to https://etherscan.io and paste your yggdrasil ETH address in the search box
Find the last successful transaction send out from your yggdrasil ETH address. It is the top transaction in the list:
Click the transaction. Note the nonce used in the last good transaction (e.g. 39
), and then plus 1 (e.g. 40
). This is the lowest stuck tx nonce.
Find the highest stuck nonce from your local geth:
make shell
then choose ethereum-daemon
geth attach
eth.getTransactionCount('{YOUR YGGDRASIL ETH ADDRESS}','pending')
-- this is the highest stuck tx nonce
exit
and exit
again.
If the highest nonce is larger than your lowest nonce, it means there are a few transactions sent and stuck in the mempool of your local ETH daemon. You need to unstuck these from highest to lowest.
Make a fork of https://replit.com/@mayachain/YggCancelETH
Update index.js
lastPendingNonce
and firstStuckNonce
. Also put in your hex encoded private key to KEY variable. Remember to add the 0x
prefix which bip39 calculator above will not have.
Update gasPrice
to a very high gas price. The price should be higher than all the transactions stuck in the mempool. Recommend to spend more than 200 Gwei or double the highest from https://mayanode.mayachain.info/mayachain/inbound_addresses (which ever is higher).
Run the script using node index.js
. Note: you may need to install some dependecies first with npm install ethers
. The output should look like:
make restart
and choose ethereum-daemon
Problem: Sometimes bifrost fails to forward observations to mayanode, due to an account number / sequence number mismatch. Here is what you need to check:
run make logs
, and choose bifrost
Search your bifrost logs for {"level":"error","service":"bifrost","module":"observer","error":"fail to send the tx to mayachain: fail to broadcast to MAYAChain,code:32, log:account sequence mismatch, expected 26806, got 26807: incorrect account sequence","time":"2021-05-30T07:28:18Z","message":"fail to send to MAYAChain"}
3. Solution: make restart
and choose bifrost
An overview of guides made for bare metal setups
Bare Metal nodes come with several advantages over cloud provider nodes. Although the initial costs for purchasing all node equipment are higher, the monthly costs are eventually much lower, and thus the nett yield is higher. Bare Metal nodes are also more resilient. They can't be taken down by hosting services in the case of governmental bans on crypto infrastructure.
Several guides have been made for purchasing and setting up bare metal nodes.
A guide on how to bond/unbond LP units on MAYAChain using El Dorado Market
Only proceed with the following steps after you've been whitelisted by your node operator
Visit https://app.eldorado.market/swap and connect your wallet
This keystore file should also contain the LP position(s) you want to bond.
Click on Wallet on the top right corner of your screen. This will bring you to a page that shows the balances of your wallet
Click on Transfer
button next to your CACAO balance.
Click on the button right before Make a deposit with custom memo
.
You should see the following screen:
The memo is the most important of this whole process.
The structure for the bonding memo is as follows:
BOND:ASSET:LPUNITS:NODEADDRESS
ASSET
is one of the assets available to bond. Check the Pools endpoint for all current pools
Not all assets are available for bonding. Check with your node operator or on Discord which assets are bondable
LPUNITS
specifies how many LP units of given asset you want to bond. You can enter your Maya address in MayaScan, press on your desired pool, to see the amount of LP units you have on each pool.
NODEADDRESS
is the Maya address of the Node you want to bond to.
An example memo would look like this:
BOND:THOR.RUNE:100000000000:maya13pv4zgyy85lzadjjkyvy3mmmr7l0yx9lzamay4
- Bond 100000000000 THOR.RUNE LP Units to node maya13pv4zgyy85lzadjjkyvy3mmmr7l0yx9lzamay4
Now that you have the memo, all that's left is the Amount to fill in. The Amount is always 1 CACAO.
You should have all the boxes filled in now. The final step is sending the transaction.
Once you have sent the transaction, check with your node operator went well. You should now be a bond provider to a MAYANode.
First, you'll need to check with your Node operator to check if your node is churned out (you can't unbond otherwise).
Follow the exact same steps as above. The only change will be the memo which should use UNBOND instead of BOND, with this format UNBOND:ASSET:LPUNITS:NODEADDRESS
Example: UNBOND:THOR.RUNE:100000000000:maya13pv4zgyy85lzadjjkyvy3mmmr7l0yx9lzamay4
New solutions are being worked on to make bonding and managing nodes easier.
Swap Fees and Delay
Users pay up to four kinds of fees when conducting a swap.
Layer1 Network Fees (gas): paid by the user when sending the asset to MAYAChain to be swapped. This is controlled by the user's wallet.
Outbound Fee - the fee the Network pays on behalf of the user to send the outbound transaction. See Outbound Fee (LINK).
The Swap Quote endpoint will calculate and show all fees.
If a transaction fails, it is refunded, thus it will pay the outboundFee
for the SourceChain not the DestinationChain. Thus devs should always swap an amount that is a maximum of the following, multiplied by at least a 4x buffer to allow for gas spikes:
The Destination Chain outboundFee, or
The Source Chain outboundFee, or
$1.00 (the minimum outboundFee).
There are four phases of a transaction sent to MAYAChain each taking time to complete.
Layer1 Inbound Confirmation - assuming the inboundTx will be confirmed in the next block, it is the source blockchain block time.
Observation Counting - time for 67% MAYAChain Nodes to observe and agree on the inboundTx.
Confirmation Counting - for non-instant finality blockchains, the amount of time MAYAChain will wait before processing to protect against double spends and re-org attacks.
Outbound Delay - dependent on size and network traffic. Large outbounds will be delayed.
Layer1 Outbound Confirmation - Outbound blockchain block time.
Wait times can be between a few seconds up to an hour. The assets being swapped, the size of the swap and the current network traffic within MAYAChain will determine the wait time.
The Swap Quote endpoint will calculate points 3 and 4.
Streaming Swaps is a means for a swapper to get better price execution if they are patient. This ensures Capital Efficiency while still keeping with the philosophy "impatient people pay more".
There are two important parts to streaming swaps:
The interval part of the stream allows arbs enough time to rebalance intra-swap - this means the capital demands of swaps are met throughout, instead of after.
The quantity part of the stream allows the swapper to reduce the size of their sub-swap so each is executed with less slip (so the total swap will be executed with less slip) without losing capital to on-chain L1 fees.
If a swapper is willing to be patient, they can execute the swap with a better price, by allowing arbs to rebalance the pool between the streaming swaps.
Once all swaps are executed and the streaming swap is completed, the target token is sent to the user (minus outbound fees).
Streaming Swaps is similar to a Time Weighted Average Price (TWAP) trade however it is restricted to 24 hours (Mimir STREAMINGSWAPMAXLENGTH = 14400
blocks).
Trade Target or Limit / Swap Interval / Swap Quantity.
Limit or Trade Target: Uses the trade limit to set the maximum asset ratio at which a mini-swap can occur; otherwise, a refund is issued.
Interval: Block separation of each swap. For example, a value of 10 means a mini-swap is performed every 10 blocks.
Quantity: The number of swaps to be conducted. If set to 0, the network will determine the appropriate quantity.
Using the values Limit/10/5 would conduct five mini-swaps with a block separation of 10. Only swaps that achieve the specified asset ratio (defined by Limit) will be performed, while others will result in a refund.
On each swap attempt, the network will track how much (in funds) failed to swap and how much was successful. After all swap attempts are made (specified by "swap quantity"), the network will send out all successfully swapped value, and the remaining source asset via refund (that failed to swap for some reason, most likely due to the trade target).
If the first swap attempt fails for some reason, the entire streaming swap is refunded and no further attempts will be made. If the swap quantity
is set to zero, the network will determine the number of swaps on its own with a focus on the lowest fees and maximize the number of trades.
A min swap size is placed on the network for streaming swaps (Mimir StreamingSwapMinBPFee = 5
Basis Points). This is the minimum slip for each individual swap within a streaming swap allowed. This also puts a cap on the number of swaps in a streaming swap. This allows the network to be more friendly to large trades, while also keeping revenues up for small or medium-sized trades.
The network works out the optimal streaming swap solution based on the Mimumn Swap Size and the swapAmount.
Single Swap: To calculate the minimum swap size for a single swap, you take 2.5 basis points (bps) of the depth of the pool. The formula is as follows:
Example using BTC Pool:
BTC Cacao Depth = 20,007,476 CACAO
StreamingSwapMinBPFee = 5 bp
MinimumSwapSize = 0.0005 * 20,007,476 = 10,003. CACAO
Double Swap: When dealing with two pools of arbitrary depths and aiming for a precise 5 bps swap fee (set by StreamingSwapMinBPFee
), you need to create a virtual pool size called cacaoDepth
using the following formula:
r1
represents the cacao depth of pool1, and r2
represents the cacao depth of pool2.
The cacaoDepth
is then used with 1.25 bps (half of 2.5 bps since there are two swaps), which gives you the minimum swap size that results in a 5 bps swap fee.
The larger the difference between the pools, the more the virtual pool skews towards the smaller pool. This results in less rewards given to the larger pool, and more rewards given to the smaller pool.
Example using BTC and ETH Pool
BTC Cacao Depth = 20,007,476 CACAO
ETH Cacao Depth = 8,870,648 CACAO
StreamingSwapMinBPFee = 5 bp
virtualCacaoDepth = (2*20,007,476*8,870,648) / (20,007,476 + 8,870,648) = 12,291,607 CACAO
MinimumSwapSize = (0.0005/4) * 12,291,607 = 1536.45 CACAO
The number of swaps required is determined by dividing the swap Amount
by the minimum swap size calculated in the previous step.
The swapAmount
represents the total amount to be swapped.
Example: swap 20,000 CACAO worth of BTC to ETH. (approx 0.653 BTC).
20,000 / 3,072.90 = 6.5 = 7 Swaps.
The difference between streaming swaps and non-streaming swaps can be calculated using the swap count with the following formula:
The difference
value represents the percentage of the swap fee saved compared to doing the same swap with a regular fee structure. There higher the swapCount, the bigger the difference.
Example:
(7-1)/7 = 6/7 = 85% better price execution by being patient.
Example actions within MAYAChain
Endpoints have been made to look up a savers position quickly.
Response:
Request Get Savers Position for address 33XBYjiR3B7g8755mCB56aHtxQYL2Go9xf
Response:
Find Liquidity Position
Similar to savers, looking up the liquidity position with a given address is possible.
Response:
Several endpoints exist however the member's endpoint is the most comprehensive
Request: Get liquidity provider information for the address bc1q0kmdagyqhkzw4sgs7f0vycxw7jhexw0rl9x9as
Response:
Any address can be used with this endpoint, e.g. bc1q0kmdagyqhkzw4sgs7f0vycxw7jhexw0rl9x9as with ?showSavers=true
to show any savers position also.
User Transaction History
Actions within THORChain can be obtained from Midgard which will list the actions taken by any given address.
Request: List actions by the address bnb1hsmrred449qcmhg9sa42deejr8nurwsqgu9ga4
Response:
Response:
Note this endpoint is in alpha and the response will differ for swaps.
Overview
Make a cross-chain swap on MAYAChain in less than 5 minutes.
Let's demonstrate decentralized, non-custodial cross-chain swaps. In this example, we will build a transaction that instructs MAYAChain to swap native Bitcoin to native Ethereum in one transaction.
BTC => BTC.BTC
ETH => ETH.ETH
Only available pools can be used. (where 'status' == Available)
All amounts are 1e8. Multiply native asset amounts by 100000000 when dealing with amounts in THORChain. 1 BTC = 100,000,000.
Request: Swap 1 BTC to ETH and send the ETH to 0x3021c479f7f8c9f1d5c7d8523ba5e22c0bcb5430
.
Response:
If you send 1 BTC to bc1qlccxv985m20qvd8g5yp6g9lc0wlc70v6zlalz8
with the memo =:ETH.ETH:0x3021c479f7f8c9f1d5c7d8523ba5e22c0bcb5430
, you can expect to receive 18.55545107
ETH.
For security reasons, your inbound transaction will be delayed by 600 seconds (1 BTC Block) and 2685 seconds (or 179 native MAYAChain blocks) for the outbound transaction, 3285 seconds all up. You will pay an outbound gas fee of 0.0085 ETH and will incur 168 basis points (1.68%) of slippage.
See an example implementation LINK HERE
Construct, sign and broadcast a transaction on the BTC network with the following parameters:
Amount => 1.0
Recipient => bc1qlccxv985m20qvd8g5yp6g9lc0wlc70v6zlalz8
Memo => =:ETH.ETH:0x3021c479f7f8c9f1d5c7d8523ba5e22c0bcb5430
Never cache inbound addresses! Quotes should only be considered valid for 10 minutes. Sending funds to an old inbound address will result in loss of funds.
Once a majority of nodes have observed your inbound BTC transaction, they will sign the Ethereum funds out of the network and send them to the address specified in your transaction. You have just completed a non-custodial, cross-chain swap by simply sending a native L1 transaction.
There is a rate limit of 1 request per second per IP address on /quote endpoints. It is advised to put a timeout on frontend components input fields, so that a request for quote only fires at most once per second. If not implemented correctly, you will receive 503 errors.
For best results, request a new quote right before the user submits a transaction. This will tell you whether the expected_amount_out has changed or if the inbound_address has changed. Ensuring that the expected_amount_out is still valid will lead to better user experience and less frequent failed transactions.
Specify tolerance_bps to give users control over the maximum slip they are willing to experience before canceling the trade. If not specified, users will pay an unbounded amount of slip.
Notice how a minimum amount (1822007296/ ~18.22 ETH) has been appended to the end of the memo. This tells THORChain to revert the transaction if the transacted amount is more than 500 basis points less than what the expected_amount_out returns.
Specify affiliate_address and affiliate_bps to skim a percentage of the expected_amount_out.
Notice how wr:10
has been appended to the end of the memo. This instructs MAYAChain to skim 10 basis points from the swap. The user should still expect to receive the expected_amount_out, meaning the affiliate fee has already been subtracted from this number.
Specify streaming_interval to define the interval in which streaming swaps are swapped.
Notice how approx_streaming_savings shows the savings by using streaming swaps. total_swap_seconds also shows the amount of time the swap will take.
TBA
Developers experiencing issues with these APIs can go to the Maya Protocol Discord server (LINK) for assistance. Interface developers should subscribe to the #interface-alerts channel for information pertinent to the endpoints and functionality discussed here.
MAYAChain is a decentralised cross-chain liquidity protocol that allows users to add liquidity or swap over that liquidity. It does not peg or wrap assets. Swaps are processed as easily as making a single on-chain transaction.
For wallets/interfaces to interact with MAYAChain, they need to:
Connect to MAYAChain to obtain information from one or more endpoints.
Construct transactions with the correct memos.
Send the transactions to MAYAChain Inbound Vaults.
Frontend developers can use MAYAChain to access decentralised layer1 swaps between BTC, ETH, DASH, KUJI and more.
MAYAChain offers a Savings product, which earns yield from Swap fees. Deposit Layer1 Assets to earn in-kind yield. No lockups, penalties, impermanent loss, minimums, maximums or KYC.
Aggregators can deploy contracts that use custom swapIn
and swapOut
cross-chain aggregation to perform swaps before and after MAYAChain.
Eg, swap from an asset on Sushiswap, then MAYAChain, to an asset on Fin in one transaction.
In-depth guides to understand MAYAChain's implementation have been created.
Several libraries exist to allow for rapid integration. xchainjs has seen the most development is recommended.
Eg, swap from layer 1 ETH to BTC and back.
Analysts can build on Midgard or Flipside to access cross-chain metrics and analytics.
Eg, gather information on cross-chain liquidity
MAYAChain has several APIs with Swagger documentation.
Slip Fee: protects the pool from being manipulated by large swaps. Calculated as a function of transaction size and current pool depth. The slip fee formula is explained here(LINK) and an example implementation is .
Affiliate Fee - (optional) a percentage skimmed from the inbound amount that can be paid to exchanges or wallet providers. Wallets can now accept fees in any MAYAChain-supported asset (USDC, BTC, etc). Check the "Preferred Asset for Affiliate Fees" section in for more details and setup information.
See the section for full details.
For convenience, a recommended_min_amount_in
is included on the endpoint, which is the value described above. This value is priced in the inbound asset of the quote request (in 1e8). This should be the minimum-allowed swap amount for the requested quote.
See the section for full details.
To utilise a streaming swap, use the following within a :
Request: Get BTC saver information for the address 33XBYjiR3B7g8755mCB56aHtxQYL2Go9xf
Returns all savers for a given asset. To get all savers you can use
Request: Get liquidity provider information in the BTC pool for the address bc1q00nrswtpp3zddgc0uvppuszhnr8k8zfcdps9gn
Will also include savers' actions. The Action endpoint is very flexible, see the .
Transactions can once sent to THORChain.
Request: Get the status for BTC tx A56B423250020E4960D9836C6F843E1D3333FAE583C9CA26776F0D68DA69CE4A sent to the Savers vault.
For more details information, can be used looking for updated_vault
MAYAChain allows native L1 Swaps. On-chain are used instruct MAYAChain how to swap, with the option to add and . MAYAChain nodes observe the inbound transactions and when the majority have observed the transactions, the transaction is processed by threshold-signature transactions from MAYAChain vaults.
The following examples use a free, hosted API provided by the Maya Protocol team. If you want to run your own full node, please see
MAYAChain uses a specific Available assets are at: .
Full quote swap endpoint specification can be found here: .
If you'd prefer to calculate the swap yourself, see the section to understand what fees need to be accounted for in the output amount. Also, review the section to understand how to create the swap memos.
Learn more about how to construct inbound transactions for each chain type here:
For more information on affiliate fees:
can be used to break up the trade to reduce slip fees.
MAYAChain works by observing transactions to its vaults across all the chains it supports. When the majority of nodes observe funds flowing into the system, they agree on the user's intent (usually expressed through a within a transaction) and take the appropriate action.
For more information see or .
guides have been developed for fast and simple implementation.
Midgard -
MAYANode -
Cosmos RPC -
See for more information.
API for performing actions with THORChain
While the Query package allows quick and powerful information retrieval from THORChain such as a swap estimate., this package performs the actions (sends the transactions), such as a swap, add and remove.As a general rule, this package should be used in conjunction with the query package to first check if an action is going to be possible be performing the action.Example: call estimateSwap first to see if the swap is going to be successful before calling doSwap, as doSwap will not check.
Code examples in Replit
Currently implemented functions are listed below with code examples. Press the Run button to run the code and see the output. Press,Show Files
, and select index.ts
to see the code. Select package.json
to see all the package dependencies. and .
Executes a swap from a given wallet. This will result in the inbound transaction into THORChain.DoSwap runs first then if successful with a constructed using a . Do swap can be used with an existing xchain client implementation or a custom wallet and will return the transaction hash of the inbound transaction.A seed is provided in the example but it has no funds so it will error.
Adds and removed liquidity from Savers. Requires a seed with funds.
Adds liquidity to a pool. Provide both assets for the pool. lp type is determined from the amount of the asset. The example is a single-sided rune deposit. A seed is provided in the example but it has no funds so it will error.
Removes Liquidity from a pool. The opposite of adding liquidity.
XChainJS library overview and the main components
XChainJS is an open-source library with a common interface for multiple blockchains, built for simple and fast integration for wallets and Dexs and more. XChainJS is designed to abstract MAYAChain and specific blockchain complexity and to provide an easy-to-use API for developers.
The packages implement the complexity detailed in the other sections of this site.
XChain has several key modules allowing powerful functionality.
Allows easy information retrieval and estimates from MAYAChain.
Conducts actions such as swap, add and remove. It wraps xchain clients and creates a new wallet class for and balance collection.
For every blockchain connected to MAYAChain with a common interface.
Current clients implemented are:
xchain-arb
xchain-bitcoin
xchain-dash
xchain-ethereum
xchain-kujira
xchain-mayachain
xchain-thorchain
APIs for getting data from MAYAChain.
Midgard
MAYAnode
See the package breakdown for more information.
Ensure you have the following
npm --version v8.5.5 or above
node --version v16.15.0
yarn --version v1.22.18 or above
Create a new project by creating a new folder, then type npx tsc --init
.
The replit code examples have all the required packages within the project.json file, just copy the project dependencies into your own project.json.
Example for the query-package, estimateSwap packages
Go to the replit code example then press show files. Select the project.json file.
Locate and then copy the dependencies
section into your project.json file.
From the command line, type yarn
. This will download and install the required packages.
The code is available on GitHub and managed by several key developers. Reach out at Telegram group: https://t.me/xchainjs for more information.
Each blockchain that is integrated into MAYAChain has a corresponding xchain client with a suite of functionality to work with that chain. They all extend the xchain-client
class.
MAYAChain automatic market maker that uses MAYANode & Midgard Api's AMM functions like swapping, adding and removing liquidity. It wraps xchain clients and creates a new wallet class and balance collection.
Uses midgard and mayanode Api's to query MAYAChain for information. This module should be used as the starting place get any MAYAChain information that resides in MAYANode or Midgard as it does the heaving lifting and configuration.
Default endpoints are provided with redundancy, custom MAYANode or Midgard endpoints can be provided in the constructor.
This package is built from OpenAPI-generator. It is used by the mayachain-query.
Thorchain-query contains midgard class that uses xchain-midgard and the following end points:
/v2/mayachain/mimir
/v2/mayachain/inbound_addresses
/v2/mayachain/constants
/v2/mayachain/queue
For simplicity, is recommended to use the midgard class within mayachain-query instead of using the midgard package directly.
Default endpoints defaultMidgardConfig
are provided with redundancy within the Midgard class.
Custom Midgard endpoints can be provided in the constructor using the MidgardConfig
type.
See ListPools for a working example.
This package is built from OpenAPI-generator and is also used by the thorchain-query. The design is similar to the midgard. MAYANode should only be used when time-sensitive data is required else midgard should be used.
As with the midgard package, MAYANode can also be given custom end points via theMayanodeConfig
type.
xchain-util
A helper packager used by all the other packages. It has the following modules:
asset
- Utilities for handling assets
async
- Utitilies for async
handling
bn
- Utitilies for using bignumber.js
chain
- Utilities for multi-chain
string
- Utilities for strings
https://docs.thorswap.finance/swapkit-docs/
To be added...
A coding overview to XChainJS.
The foundation of xchainjs is defined in the xchain-util package
Address
: a crypto address as a string.
BaseAmount
: a bigNumber in 1e8 format. E.g. 1 BTC = 100,000,000 in BaseAmount
AssetAmount
: a BaseAmount*10^8. E.g. 1 BTC = 1 in Asset Amount.
Asset
: Asset details {Chain, symbol, ticker, isSynth}
All Assets
must conform to the Asset NotationassetFromString()
is used to quickly create assets and will assign chain and synth.
CryptoAmount:
is a class that has:
All crypto should use the CryptoAmount
object with the understanding they are in BaseAmount format. An example to switch between them:
Major data types for the mayarchain-query package.
The input Type for estimateSwap
. This is designed to be created by interfaces and passed into EstimateSwap. Also see Swap Memo for more information.
Variable
Data Type
Comments
input
CryptoAmount
inbound asset and amount
destinationAsset
Asset
outbound asset
destinationAddress
String
outbound asset address
slipLimit
BigNumber
Optional: Used to set LIM
affiliateFeePercent
number
Optional: 0-0.1 allowed
affiliateAddress
Address
Optional: thor address
interfaceID
string
Optional: assigned interface ID
The internal return type is used within estimateSwap after the calculation is done.
Variable
Data Type
Comments
totalFees
TotalFees
All fees for swap
slipPercentage
BigNumber
Actual slip of the swap
netOutput
CryptoAmount
input - totalFees
waitTimeSeconds
number
Estimated time for the swap
canSwap
boolean
false if there is an issue
errors
string array
contains info if canSwap is false
Return type of estimateSwap
. This is designed to be used by interfaces to give them all the information they need to display to the user.
Variable
Data Type
Comments
txEstimate
SwapEstimate
swap details
memo
string
constructed memo MAYAChain will understand
expiry
DateTime
when the SwapEstimate information will no longer be valid.
toAddress
string
current Asgard Vault address From inbound_address
Do not use toAddress
after expiry
as the Asgard vault rotates
Major data types for the thorchain-query package.
Package description
Code examples
Install procedures
Input Type for doSwap where a swap will be actually conducted. Based on EstimateSwapParams.
Variable
Text
Text
hash
string
inbound Tx Hash
url
string
Block exploer url
waitTimeSeconds
number
Estimated time for the swap
How to Query MAYAChain
Vaults are fetched from the /inbound_addresses
:
https://mayanode.mayachain.info/mayachain/inbound_addresses
You need to select the address of the Chain the inbound transaction will go to.
The address will be the current active Asgard Address that accepts inbounds. Do not cache these address as they change regularly. Do not delay inbound transactions (e.g. do not use future timeLocks).
Example Output, each connected chain will be displayed.
Never cache vault addresses, they churn regularly.
Inbound transactions should not be delayed for any reason else there is risk funds will be sent to an unreachable address. Use standard transactions, check the inbound address
before sending and use the recommended gas rate
to ensure transactions are confirmed in the next block to the latest Inbound_Address
.
Check for the halted
parameter and never send funds if it is set to true
If a chain has a router
on the inbound address endpoint, then everything must be deposited via the router. The router is a contract that the user first approves, and the deposit call transfers the asset into the network and emits an event to THORChain.
This is done because "tokens" on protocols don't support memos on-chain, thus need to be wrapped by a router which can force a memo.
Note: you can transfer the base asset, eg ETH, directly to the address and skip the router, but it is recommended to deposit everything via the router.
If you connect to a public Midgard, you must be conscious of the fact that you can be phished and could send money to the WRONG vault. You should do safety checks, i.e. comparing with other nodes, or even inspecting the vault itself for the presence of funds. You should also consider running your own 'fullnode' instance to query for trusted data.
Chain
: Chain Name
Address
: Asgard Vault inbound address for that chain.,
Halted
: Boolean, if the chain is halted. This should be monitored.
gas_rate
: rate to be used, e.g. in Stats or GWei. See Fees.
Use the /pools
endpoint of Midgard to retrieve all swappable assets on MAYAChain. The response will be an array of objects like this:
Only pools with "status": "available"
are available to trade
Make sure to manually add Native $CACAO as a swappable asset.
"assetPrice" tells you the asset's price in CACAO (RUNE Depth/AssetDepth ). In the above example
1 KUJI.KUJI = 3.62 RUNE
All values on MAYAChain (MAYANode and Midgard) are given in 1e8 eg, 100000000 base units (like Bitcoin), and unless postpended by "USD", they are in units of RUNE. Even 1e18 assets, such as ETH.ETH, are shortened to 1e8. 1e6 Assets like ETH.USDC, are padded to 1e8. MAYANode will tell you the decimals for each asset, giving you the opportunity to convert back to native units in your interface.
See code examples using the MAYAChain xchain package here https://github.com/xchainjs/xchainjs-lib/tree/master/packages/xchain-mayachain
There are two ways to see if a Chain is halted.
Looking at the /inbound_addresses
endpoint and inspecting the halted flag.
Looking at Mimir and inspecting the HALT[Chain]TRADING setting. See Network Halts for more details.
How to connect to Midgard, MAYANode and the base Tendermint layer.
The Network Information comes from four sources:
Midgard: Consumer information relating to swaps, pools, and volume. Dashboards will primarily interact with Midgard.
MAYANode: Raw blockchain data provided by the MAYAChain state machine. MAYAChain wallets and block explorers will query MAYAChain-specific information here.
Cosmos RPC: Used to query for generic CosmosSDK information.
Tendermint RPC: Used to query for consensus-related information.
The below endpoints are run by specific organisations for public use. There is a cost to running these services. If you want to run your own full node, see the information here.
Midgard returns time-series information regarding the THORChain network, such as volume, pool information, users, liquidity providers and more. It also proxies to THORNode to reduce burden on the network. Runs on every node.
Mainnet
Runs on every Node
Port: 8080
RPC Guide: http://<host>:8080/v2/doc
Stagenet
MAYANode returns application-specific information regarding the MAYAChain state machine, such as balances, transactions and more. Careful querying this too much - you could overload the public nodes. Consider running your own node. Runs on every node.
Mainnet
Runs on every Node
Port: 1317
RPC Guide: http://<host>:1317/mayachain/doc/
Stagenet
The Cosmos RPC allows Cosmos base blockchain information to be returned. However, not all endpoints have been enabled. Endpoints guide
https://v1.cosmos.network/rpc/v0.45.1
The Tendermint RPC allows Tendermint consensus information to be returned.
Any Node Ports
MAINNET Port: 27147
STAGENET Port: 26657
TESTNET Port: 26657
Endpoints guide https://docs.tendermint.com/master/rpc/#/
Mainnet
Stagenet
P2P is the network layer between nodes, useful for network debugging.
MAINNET Port: 27146
STAGENET Port: 27146
Overview of all MAYAChain concepts
Using xchain client packages
A wallet class has been created that instantiates every chain client and leverages the interface which greatly simplifies working with wallets and THORChain. See the below code example.
Client packages have been created for each blockchain that connects to THORChain. All clients implement xchain-crypto which acts like a super class and gives each client a common interface.
Common functions with code examples are:
All clients implement these functions. While most can use the same code, some have slight client differences.
Get Explorer URL - for the specific blockchain
Get Balance - returns the balance of an address
Get Transactions - returns a simplified array of recent transactions for an address.
Get Transaction Data - returns transaction information from the transaction ID/hash.
See below for a Bitcoin example. Also see Ethereum, Binance, THORChain, Cosmos, and Avalance examples.
Get Fees - get the transaction fee for the chain, separate from THORChain fees
Transfer - transfer funds from one wallet to another.
Purge - When a wallet is "locked" the private key should be purged in each client by setting it back to null.
See http://docs.xchainjs.org/xchain-client/overview.html for more information.
How to query MAYAChain information
This package is designed to obtain any desired information from MAYAChain that a developer could want. While it uses Midgard and Mayanode packages it is much more powerful as it knows where to get the best information and how to package the information for easy consumption by developers or higher functions.
It exposes several simple functions that implement all of MAYAChain's complexity to allow easy information retrieval. The Query package does not perform any actions on MAYAChain or send transactions, that is the job of the Mayachain-AMM package.
Currently implemented functions are listed below with code examples. Press the Run button to run the code and see the output. Press Show files, and select index.ts to see the code. Select package.json to see all the package dependencies. Repo link and install instructions.
Provides estimated swap information for a single or double swap for any given two assets within THORChain. Designed to be used by interfaces, see more info here. EstimateSwap will do the following:
Validate swap inputs
Checks for network or chain halts
Get the latest pool data from Midgard
Work out the swap slip, swap fee and output
Deducts all fees from the input amount (inbound, swap, outbound and any affiliate) in the correct order to produce netOutput
and detail fees in totalFees
Ensures totalFees
is not greater than input
.
Work out the expected wait time including confirmation counting and outbound delay.
Get the current Asgard Vault address for the inbound asset
Advise if a swap is possible and provide a reason if it is not.
Note: This will be the best estimate using the information available, however exact values will be different depending on pool depth changes and network congestion.
Shows use of the savers quote endpoints.
Checks the liquidity position of a given address in a given pool. Retrieves information such as current value, ILP coverage, pool share and last added.
Provide the status of a transaction given an input hash (e.g. the output of doSwap). Looks at the different stages a transaction can be in and report.
In development
Provides an estimate for given add liquidity parameters such as slip fee, transaction fees, and expected wait time. Supports symmetrical, asymmetrical and uneven additions.
Provides information for a planned withdrawal for a given liquidity position and withdrawal percentage. Information such as fees, wait time and ILP coverage
Lists all the pool detail within THORChain.
List current network values from constants and mimir. If mimir override exists, it is displayed instead.
If there is a function you want to be added, reach out in Telegram or the dev discord server.
Setting up a Kubernetes Cluster with AWS
AWS account
CLI and AWS credentials configured
AWS IAM Authenticator
kubectl
wget
(required for EKS module)
LINUX/MAC is the preferred method of setup.
Windows should choose either:
Deploy a MAYANode from a Linux VPS.
Use Windows Subsystem for Linux - https://docs.microsoft.com/en-us/windows/wsl/about****
Firstly, clone and enter the cluster-launcher repository. All commands in this section are to be run inside this repo.
Then install the terraform CLI:
Install Terraform:
In order for Terraform to run operations on your behalf, you must install and configure the AWS CLI tool. ****To install the AWS CLI, follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install the AWS CLI.
You will be asked for you AWS access credentials (retrieve from AWS IAM from the AWS web console.)
IAM -> User -> Security Credentials -> Create Access Key.
Make sure you handle your secrets securely!
You also must install and configure the AWS IAM Authenticator tool. ****To install, follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install the AWS IAM Authenticator.
You must install and configure the Kubernetes CLI tool (kubectl). ****To install kubectl , follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install kubectl.
You also need wget and jq, follow these instructions, or choose a package manager based on your operating system.
Use the package manager homebrew to install wget and jq Note: You most likely have these installed already.
Use the commands below to deploy an AWS EKS cluster. You can run the make command that automates those command for you like this:
During the deploy, you will be asked to enter information about your cluster:
Name
AWS Region -- see valid List of Regions
Confirm yes
Or manually:
Final success message: Apply complete! Resources: 30 added, 0 changed, 0 destroyed.
If you are a returning node operator and you wish to use the same node name, the Cloudwatch log files from your previous session will block this step. You need to manually delete the logs from your console:
Cloudwatch / Cloudwatch Logs / Log Groups -> "delete"
Deploying a cluster takes ~10 minutes
This is done automatically during provisioning. To configure authentication from the command line, use the following command. It will get the access credentials for your cluster and automatically configure kubectl in case you need to to manually reconfigure kubectl.
Or get your kubeconfig file manually:
To verify, run this, and check the status is "Ready":
You are now ready to deploy a MAYANode.
Once your node is running, use the following command to automatically backup the Persistent Volumes for your Kubernetes cluster. This may help in recovering your node in the event of a disaster.
Enable backups:
Disable backups: