Using MAYAChain

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.

How to Buy Cacao?

1. Head to one of the interfaces supporting Maya Protocol and connect your wallet.

2. Transfer any of the MAYAChain supported Assets (e.g. BTC, ETH, RUNE, DASH, XRD, KUJI or ARB) to your newly created wallet.

3. Head to the swap page, select the tokens and quantity, and perform the swap.

What Wallets support Maya Protocol?

• THORWallet

• Leap Wallet

• Ctrl Wallet

• KeepKey

• Ledger

• Edge

• Caviar Nine

• Moca

• Shard Space

• Clio Swap

What Frontends support Maya Protocol?

• El Dorito Swap

• THORWallet

• Rango Exchange

• Defispot

• Asgardex

• CacaoSwap

• ThorSwap

• LeoDEX

• Rango Exchange

What are the Maya Protocol Blockchain Explorers?

• MayaScan

There are four key roles in the system:

1. Liquidity providers who add liquidity to pools and earn fees and rewards

2. Swappers who use the liquidity to swap assets ad-hoc, paying fees

3. Arbitrageurs who monitor pools and rebalance continually, paying fees but with the intent to earn a profit.

4. Node Operators who provide a bond and are paid to secure the system

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.

How it Works

Process

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.

Impact of Liquidity

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.

Infinitely Deep Liquidity

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.

Finite, but Uneven Liquidity

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.

Low Liquidity

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.

Compensation, Requirements, Costs & Penalties

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.

Maya Scan

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.

Maya Swap

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.

Mayans.app

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.

Maya Info Bot

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.

Memo Format

SWAP:ASSET:DESTADDR

Procedure

Through a MAYAChain UI (eg. El Dorito Swap, Asgardex)

1. Connect/Create wallet.

2. Transfer from the ASSET you want to swap from (eg. ETH).

3. 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

4. In the amount field, type the amount you wish to swap

1. Press send.

2. Check your transaction/Maya Address on .

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, .

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, .

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 (Live)

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 .

AZTECChain (Under Development)

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.

Tokenomics Structure

Maya Protocol ecosystem utilizes 3 distinct tokens within its framework:

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.

MAYAChain Innovations

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.

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

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.

The 3-Pillars of MAYAChain:

1. 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.

2. Increase the Liquidity of the network, via Total Value Locked (TVL), or better UX around providing liquidity.

3. Boost the Volume of the network, via Swap UX (Synths, Order Books), or wallet Integrations (Quotes Endpoint, Dev UX, Business Development).

You can buy CACAO by swapping BTC, ETH, USDT, USDC, wstETH, RUNE, DASH, KUJI, or USK to CACAO on one of the following interfaces:

• ThorWallet

• El Dorito Market

• Rango Exchange

• Asgardex

• Swapper

• Defispot

• CacaoSwap

• LeoDex

• THORSwap

Step by Step:

1. Create your wallet on your chosen interface.

2. Load your wallet with your chosen asset (BTC, ETH, USDT, USDC, wstETH, RUNE, DASH, KUJI, USK or AETH).

3. Select Swap.

4. 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:

• Guides to set up your MAYAChain wallet

• Swap assets guide

CACAO Price:

Follow up on CACAO behavior on CoinGecko or MayaScan.

https://docs.thorswap.finance/swapkit-docs/

To be added...

Create Maya address and mnemonic

1. Install go 1.20+.

2. Clone the Maya repository.

3. Install docker.

4. Install protobuf $ git clone https://gitlab.com/mayachain/mayanode

5. Change to the mainnet branch $ git checkout mainnet

6. Build the binary$ TAG=mainnet make build && TAG=mainnet make install

7. To add a mnemonic that you already own

$ mayanode keys add [key name] --recover
> Enter your bip39 mnemonic
[paste/write your mnemonic]

1. You’re done! It should look as follows:

$ mayanode keys add [key name] --recover
- name: mywallet
  type: local
  address: tmaya1gp27t2hcj603p8448qwkhfh0v4y0r3jkmdgsyn
  pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A0LirKOHGVq0y1JBcadN10UvqtnvYNvg8QOn4Mj5Gy31"}'
  mnemonic: ""

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).

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 .

DoSwap

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.

Savers

Adds and removed liquidity from Savers. Requires a seed with funds.

Add Liquidity

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.

Remove Liquidity

Removes Liquidity from a pool. The opposite of adding liquidity.

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).

How Swaps Work

Available Assets

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.

Decentralisation

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.

Continuous Liquidity Pools

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:

1. Swap to CACAO in the first pool,

2. Move that CACAO into the second pool,

3. 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.

Calculating Swap Output

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

Example

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.

Costs

The cost of a swap is made up of two parts:

1. Outbound Fee

2. 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.

Video Guide

Here is the video guide to create a Keystore wallet on El Dorito. If you prefer a written guide, please continue scrolling.

Written/ Text Guide

1- Visit El Dorito Website and press the "Enter El Dorado" button.

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.

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.

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.

For further assistance, please visit ElDorito's Discord channel and/ or Maya Protocol's Discord channel.

Overview

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.

Rewards

Node Operators earn 80% of the system income when it is stable. You can read more here:

Set up Instructions

Follow these setup up instructions

Anonymity

Node Operators should stay anonymous and never socially signal that they are running a node.

Tools

There are a variety of tools available in the ecosystem for Node Operators, such as the Telegram Alerts bot:

Security

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.

Private Delegation

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.

1. Create a new XDEFI wallet, or use an existing one. Make sure to “Prioritize XDEFI” in the settings.

1. Import Ledger accts into XDEFI via Settings > Wallet management > Connect to the hardware wallet. This opens a new screen.

1. 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).

1. In the browser, select the addresses from that chain to import.

1. Once complete, go back to XDEFI and repeat the process to add hardware wallets to XDEFI from other Ledger chains.

2. Make sure to quit the Ledger device app first, then open the chain app on Ledger you’re adding next.

Debugging process for Ledger devices

• Make sure to use the latest Ctrl Wallet Wallet version, Updates are automatic. However, you can also close and reopen your web browser or open your extensions manager, activate the developer mode and click on the "Update' button.

• Open LEDGER Live and update the firmware.

• In LEDGER Live, open 'My Ledger', uninstall (from the 'Apps installed' tab) and reinstall (from the 'App catalog' tab) the dedicated app of the blockchain you want to interact with.

• Close Ledger Live and all other processes using your LEDGER device.

• Disconnect your LEDGER device from your desktop/laptop and reconnect it to your computer.

• Enter your LEDGER PIN code from your hardware wallet device.

• From your LEDGER device, open the app dedicated to the blockchain you want to interact with.

• 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 .

• If you still encounter the same issue, please save everything you need and clear your web browser History via the advanced tab (scroll up/down to select all data types, time range: all time).

• End your web activities and close all open web browser tabs.

• Close your web browser (kill the process) and reopen it.

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: -

1. Download VultiWallet on your iOS or Android device.

1. 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:

1. 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”.

1. Click Backup Wallet. You will see the following screen with your seed phrase.

1. Copy the seed to your clipboard and keep it on your phone, or (highly recommended) write it down and keep it off-line.

1. Create a PIN.

1. Confirm your PIN.

1. 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.

1. 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.

I

1. Go to and click "Connect."

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..."

Deploy a Kubernetes cluster

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.

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.

Steps

There are three important steps to getting your node set up, deployed and churned in.

Repository Management

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

Running Two or More Nodes

All of your commands can now be run separately.

Halborn

• Draft:

• Final:

• Final:

• Final:

• Final:

• Final:

• Final:

Community alert channels

To listen for update announcements, join the following channels:

• Telegram MAYANode Announcements

• Discord MAYAChain Community Devs especially #mayanode-mccn

Here you'll find step-by-step guides on how to , using custom memos, and & Liquidity.

Tier 1 Liquidity Providers

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:

• 3rd of November, 2023.

• 1st of April, 2024.

• 29th of August, 2024.

$RUNE holders & Liquidity Providers

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.

Maya Mask Holders

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.

Early Node Operators and Liquidity Bonders

7% of the $MAYA total supply will be rewarded to early Liquidity Node operators.

• 1.75% of all the $MAYA tokens (17,500 $MAYA) will be Airdropped to the active Liquidity Nodes and Liquidity Bonders one month after the first churn-in (After completion of 6 successful Churns).

• 1.75% of all the $MAYA tokens (17,500 $MAYA) will be Airdropped to the active Liquidity Nodes and Liquidity Bonders three months after the first churn-in (After completion of 18 successful Churns).

• 1.75% of all the $MAYA tokens (17,500 $MAYA) will be Airdropped to the active Liquidity Nodes and Liquidity Bonders six months after the first churn-in (After completion of 36 successful Churns).

• 1.75% of all the $MAYA tokens (17,500 $MAYA) will be Airdropped to the active Liquidity Nodes and Liquidity Bonders twelve months after the first churn-in (After completion of 72 successful Churns).

Fee Types

Users pay up to four kinds of fees when conducting a swap.

1. 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.

2. 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 here.

3. 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 Fees for more details and setup information.

4. Outbound Fee - the fee the Network pays on behalf of the user to send the outbound transaction. See Outbound Fee (LINK).

See the fees section for full details.

Refunds and Minimum Swap Amount

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:

1. The Destination Chain outboundFee, or

2. The Source Chain outboundFee, or

3. $1.00 (the minimum outboundFee).

For convenience, a recommended_min_amount_in is included on the Swap Quote 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.

Wait Times

There are four phases of a transaction sent to MAYAChain each taking time to complete.

1. Layer1 Inbound Confirmation - assuming the inboundTx will be confirmed in the next block, it is the source blockchain block time.

2. Observation Counting - time for 67% MAYAChain Nodes to observe and agree on the inboundTx.

3. 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.

4. Outbound Delay - dependent on size and network traffic. Large outbounds will be delayed.

5. 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.

See the Delays section for full details.

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.

Mayachain-query

Allows easy information retrieval and estimates from MAYAChain.

Mayachain-amm

Conducts actions such as swap, add and remove. It wraps xchain clients and creates a new wallet class for and balance collection.

Chain clients

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.

Install Procedures

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.

Finding required dependencies

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

1. Go to the replit code example then press show files. Select the project.json file.

2. Locate and then copy the dependencies section into your project.json file.

3. 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.

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?

Private Keys, Public Keys, and Wallet Addresses

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.

Multisigs

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.

Threshold Signature Scheme (TSS)

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:

• Under the Hood: Asgard Vaults, TSS and Node Churns - LP university: https://crypto-university.medium.com/under-the-hood-asgard-vaults-tss-and-node-churns-4767f3a5624b

• Threshold Signatures: The Future of Private Keys - Zengo Wallet: https://medium.com/zengo/threshold-signatures-private-key-the-next-generation-f27b30793b

• The Keys to Crypto Kingdom: Wallet Address, Public and Private Keys Explained - Blocktrade: https://blocktrade.com/wallet-addresses-public-and-private-keys-explained/

• Bitcoin stackexchange: https://bitcoin.stackexchange.com/questions/80708/what-is-the-difference-between-your-address-and-your-public-keys

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.

Quick Definitions:

• 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.

Naming Convention:

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.

Color Scheme:

Typography:

Assets:

You can find all the logos in different formats on this link.

Links:

If you're going to reference any Maya Protocol social media or websites, please use the official links.

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.

Balancing System States

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.

Optimal State

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.

Unsafe State

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.

Inefficient 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.

Under and Over-Bonded States

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.

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).

OpenSea: https://opensea.io/collection/mayamasks

Contract: https://etherscan.io/token/0xe00d8f3dca2ac474f4d7f177570f77de0774e754

Website: https://www.mayamask.com/

Mimir V2

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.

Aztec

Enables users to access Smart Contracts and build advanced DeFi tools like derivatives and algorithmic stablecoins within the Maya ecosystem.

Zcash Integration

Zcash $ZEC is depositable into Maya for Swaps & Liquidity actions.

Taproot

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

Kaspa $KAS is depositable into Maya for Swaps & Liquidity actions.

Swapper Clout

THORChain Dex Aggregation

Enabling swaps between THORChain & MAYAChain assets.

Cardano Integration

Cardano $ADA is depositable into Maya for Swaps & Liquidity actions.

More Chains

Will be announced accordingly.

Fees

Conceptually, fees are both value-capture, access-control and resource-subsidisation mechanisms.

Value Capture

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.

Access-control

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.

Other Benefits

In addition to the above, fees also create the following benefits:

1. Avoid dust attacks

2. Store up income after the initial Emission Schedule reduces

3. Give the user a stable fee, rather than a dynamic one which changes with the external network's fees

Fee Process

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.

Outbound Fee

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:

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.

Slip-Based Fee

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.

Network Fee

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.

Overview

MAYAChain is a leaderless vault manager:

1. 1-way State Pegs allow syncing state from external chains.

2. A State Machine to coordinate asset exchange logic and delegate outgoing transactions.

3. Bifröst Chain Client to processs chain-specific transactions.

4. A TSS protocol to enable distributed threshold key-signing.

The Bifröst Protocol: 1-way State Pegs

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.

MAYAChain State Machine

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).

Signer (Bifröst)

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.

MAYAChain Vaults

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.

Sharded Asgard Vaults

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.

Migrating

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.

Install Go and other requirements

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

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 in order to avoid syncing from start. You will need to install

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.

Deploy a Kubernetes cluster in Linode using LKE service.

Requirements

1. a Linode account

2. linode-cli and linode credentials configured

3. kubectl

linode-cli

To install the linode-cli (Linode CLI), follow these instructions.

You need to have pip (python) on your system.

pip install linode-cli --upgrade

Create a Linode API token for your account with read and write access from your profile page. The token string is only displayed once, so save it in a safe place.

Use the API token to grant linode-cli access to your Linode account. Pass in the token string when prompted by linode-cli.

linode-cli

kubectl

To install the kubectl (Kubernetes CLI), follow these instructions or choose a package manager based on your operating system.

MacOS:

Use the package manager homebrew to install kubectl.

brew install kubernetes-cli

Windows:

Use the package manager Chocolatey to install kubectl.

choco install kubernetes-cli

wget

To install the wget, follow these instructions or choose a package manager based on your operating system.

MacOS:

Use the package manager homebrew to install wget.

brew install wget

Windows:

Use the package manager Chocolatey to install wget.

choco install wget

Deploy Kubernetes Cluster

Use the commands below to deploy a Kubernetes cluster.

You can run the make command that automates those command for you like this:

make linode

Or manually run each commands:

cd linode/
terraform init
terraform plan # to see the plan
terraform apply

Configure kubectl

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.

# Store it - method #1
jq -r ".resources[].instances[].attributes.kubeconfig" linode/terraform.tfstate | base64 -D > ~/.kube/config-linode

# Store it - method #2
linode-cli lke kubeconfig-view <use_your_cluster_id> > ~/.kube/config-linode

# Merge it and set current context
KUBECONFIG=~/.kube/config:~/.kube/config-linode kubectl config view --flatten > ~/.kube/tmpcfg && mv -f ~/.kube/tmpcfg ~/.kube/config && kubectl config use-context $(kubectl config current-context --kubeconfig=~/.kube/config-linode)

# Or just view it - method #1
jq -r ".resources[].instances[].attributes.kubeconfig" linode/terraform.tfstate | base64 -D
# Or just view it - method #2
linode-cli lke kubeconfig-view <use_your_cluster_id>

Note: If the above linode-cli command is broken you can download the file from the web dashboar for the respective cluster.

This replaces the existing configuration at ~/.kube/config.

Once done, you can check your cluster is responding correctly by running the command:

kubectl version
kubectl get nodes

Clean up your workspace

To destroy and remove previously created resources, you can run the command below.

make destroy-linode

Or run the commands manually:

cd linode/
terraform destroy

Deploy a Kubernetes cluster in GCP using GKE service.

Requirements

1. GCP account

2. gcloud and GCP credentials configured

3. kubectl

Steps

Firstly, clone and enter the cluster-launcher repository. All commands in this section are to be run inside this repo.

git clone https://gitlab.com/mayachain/devops/cluster-launcher
cd cluster-launcher

Then install the terraform CLI:

brew install terraform

gcloud CLI

The gcloud CLI allows you to manage your GCP services.

brew install google-cloud-sdk

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.

gcloud init
gcloud auth application-default login
gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com

Kubernetes Control Tool

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.

brew install kubernetes-cli

wget && jq

You also need wget and jq, follow these instructions, or choose a package manager based on your operating system.

brew install wget
brew install jq

Deploy Kubernetes Cluster

Use the commands below to deploy an GKE cluster:

make gcp

During the deployment, you will be asked to enter information about your cluster:

var.project_id
  Project ID

  Enter a value: ma-k8s-123456

var.zone
  GCP zone in region

  Enter a value: us-east1-d

• Project ID

• Zone -- gcloud compute zones list

• Confirm yes

CONFIGURE

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.

(cd gcp && gcloud container clusters get-credentials $(terraform output cluster_name) --zone $(terraform output zone))

This replaces the existing configuration at ~/.kube/config.

Once done, you can check if your cluster is responding correctly by running the following commands.

kubectl version
kubectl get nodes

You are now ready to deploy a MAYANode.

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.

Maya Protocol ILP Rules:

1. 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).

2. 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).

3. 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.

4. ILP is paid and reset after full withdrawal, not affected by partial withdrawals, and only reset but not paid on top-ups.

5. 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.

The impermanent loss protection can be mathematically Calculated using the following process.:

1. Calculate the amount to cover in CACAO.

2. 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.

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.

The Network Information comes from four sources:

1. Midgard: Consumer information relating to swaps, pools, and volume. Dashboards will primarily interact with Midgard.

2. MAYANode: Raw blockchain data provided by the MAYAChain state machine. MAYAChain wallets and block explorers will query MAYAChain-specific information here.

3. Cosmos RPC: Used to query for generic CosmosSDK information.

4. Tendermint RPC: Used to query for consensus-related information.

Midgard

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

• https://midgard.mayachain.info/v2/doc

Runs on every Node

Port: 8080

RPC Guide: http://<host>:8080/v2/doc

Stagenet

• https://stagenet.midgard.mayachain.info/v2/doc

MAYANode

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

• https://mayanode.mayachain.info/mayachain/doc

Runs on every Node

Port: 1317

RPC Guide: http://<host>:1317/mayachain/doc/

Stagenet

• https://stagenet.mayanode.mayachain.info/doc

Cosmos RPC

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

Example URL https://stagenet.mayanode.mayachain.info/cosmos/bank/v1beta1/balances/smaya18z343fsdlav47chtkyp0aawqt6sgxsh3ctcu6u

Tendermint RPC

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

• https://tendermint.mayachain.info

Stagenet

• https://stagenet.tendermint.mayachain.info

P2P

P2P is the network layer between nodes, useful for network debugging.

MAINNET Port: 27146

STAGENET Port: 27146

P2P Guide https://docs.tendermint.com/master/spec/p2p/

Summary

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.

Rationale

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.

Economic Security

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.

Managing a Pooled MAYANode

Node Operator

Adding a Bond Provider

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 Operator Fee

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.

Bond Provider

Adding/Removing 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

Reward Shares

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.

1. Connecting your wallet

Visit https://app.eldorado.market/swap and connect your wallet

2. Select the keystore file of your wallet and enter your password

This keystore file should also contain the LP position(s) you want to bond.

3. Go to your wallet

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

4. Go to the $CACAO transfer screen

Click on Transfer button next to your CACAO balance.

5. Hit the Custom Memo button

Click on the button right before Make a deposit with custom memo.

6. Fill in the 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

• 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.

7. Send the transaction

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.

Unbonding

1. First, you'll need to check with your Node operator to check if your node is churned out (you can't unbond otherwise).

2. 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

Deploying

• I have set up a local mayanode repository with a cluster-launcher and node-launcher git cloned into the right sub-folders

• I have installed all the pre-requisites

• I have a AWS/DO account ready with credentials if using a service provider

• I have deployed a cluster and saved my node details (name of node, region)

• I have installed tools via make tools

• I have deployed a node by running make <provider>

• I have securely saved my MAYANode Password and MAYANode Mnemonic

Joining

• I have added liquidity to one of the supported pools

• I have bonded my liquidity to my corresponding node

• I have confirmed my node has been credited the small bond and I am the bond_address of the node

• (Optional) I have confirmed I can unbond a small amount

• (Optional) I have whitelisted any bond providers for my node and set the node operator fee

• I have sent the final bond, higher than the MinimumBond

• I have run make set-ip-address to set my Node's IP address

• I have run make set-node-keys to set my Node's public keys

• I have run make set-version to set my Node's version

• I have verfied in make status that my node is ready to churn in

Upgrading

• I have run make status to verify the current state of my node

• I have run make pods to verify all my node's services are running properly

• I have run make update

• I have run make set-version to set my new Node version

• I have run make status to verify the final state of my node

Unbonding

• I have waited until my node is churned out and is in standby

• I have sent an UNBOND transaction from the same wallet registered to my node

• I have verified that my liquidity is no longer bonded

Leaving Whilst Active

• I have confirmed my node is active and I wish to leave before waiting to churn naturally

• I have sent the first LEAVE transaction and verified my node has "requested to leave".

• I have verified that a churn has taken place and my node is in STANDBY

• I have sent the final LEAVE transaction and my liquidity is no longer bonded

Leaving Whilst Standby

• I have verified that a churn has taken place and my node is in STANDBY

• I have verified that my node has returned all hot funds by checking my node's yggdrasil vault on the explorer

• I have sent the final LEAVE transaction and my liquidity is no longer bonded

Destroying a Node

• I have verified that I have either UNBONDED my entire BOND or LEFT and received my BOND back.

• I have run make destroy destroy-tools to destroy my node from node-launcher

• I have run make destroy-<provider> to destroy my cluster from cluster-launcher

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

Asset Listing

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.

Asset Delisting

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:

1. When a new bootstrap pool is enabled, its depth is compared with the depth of the smallest active pools.

2. 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.

Chain Listing/Delisting

When the community wants to support a new chain

1. Community developers write a new Bifröst module and propose it via a MAYAChain Improvement Proposal (MIP).

2. MAYAChain developer community decides whether or not to approve it

3. If approved, the code gets tested and validated by core developers

4. If accepted, it gets added to MAYANode software

5. Nodes upgrade their software as they are cycled off and back onto the network

6. 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.

Protocol Upgrades & MAYAChain Improvement Proposals (MIPs)

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

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.

Economic Limit

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

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.

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.

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 memo within a transaction) and take the appropriate action.

For wallets/interfaces to interact with MAYAChain, they need to:

1. Connect to MAYAChain to obtain information from one or more endpoints.

2. Construct transactions with the correct memos.

3. Send the transactions to MAYAChain Inbound Vaults.

Front-end Development Guides

Native Swaps Guide

Frontend developers can use MAYAChain to access decentralised layer1 swaps between BTC, ETH, DASH, KUJI and more.

Native Savings Guide

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

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.

Concepts

In-depth guides to understand MAYAChain's implementation have been created.

Libraries

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.

https://docs.xchainjs.org/overview/

Analytics

Analysts can build on Midgard or Flipside to access cross-chain metrics and analytics.

Eg, gather information on cross-chain liquidity

Connecting to MAYAChain

MAYAChain has several APIs with Swagger documentation.

• Midgard - https://midgard.ninerealms.com/v2/doc

• MAYANode - https://mayanode.mayachain.info/mayachain/doc

• Cosmos RPC - https://tendermint.mayachain.info

See Connecting to MAYAChain for more information.

Synthetic Assets

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.

Minting - 1:1 pegged

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)

This is the .

The total Synth Supply is then updated:

Synth Units - 100% collateralization

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 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.

Redeeming: 1:1 pegged

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.

Swapping

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.

Economics

Fees

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.

Effect on Dual-LPs

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%.

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%.

Synth Minting Cap

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.

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.

This will soon be deprecated to allow PoL to control Synths.

Protocol Owned Liquidity (POL)

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 .

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.

Staged Pools

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.

Deploy a Kubernetes cluster in DO using EKS service.

Requirements

1. DO account

2. doctl and DO credentials configured

3. kubectl

Steps

Firstly, clone and enter the . All commands in this section are to be run inside this repo.

Then install the :

DOCLI

The allows you to manage your DO services.

Kubernetes Control Tool

You must install and configure the Kubernetes CLI tool (kubectl). **To install kubectl** , follow , or choose a package manager based on your operating system.

wget && jq

You also need wget and jq, follow , or choose a package manager based on your operating system.

Deploy Kubernetes Cluster

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 (use lower-case)

• Confirm yes

Final success message: Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

CONFIGURE

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.

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 .

Conformation Counting

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.

Note, MAYAChain and Binance Beacon Chain have near-instant finality so confirmation counting is not required.

Outbound Transaction Throttling

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 feature is controlled by several values that can be changed by Node Operators as required.

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:

1. Halt Signing- outbounds que

2. Halt LP - add/remove stopped, swapping allowed.

3. Halt Trading - no trading allows

4. Halt Chain - nodes stop observing that chain

There are also network level halts

1. Trading halt

To get more information see .

Automatic Solvency Checker

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 Operator Triggered Halts

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.

Unauthorized Transaction Detection

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.

Automatic Security Flagging

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.

How xChainjs is constructed

xchain-[chain] clients

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.

xchain-mayachain-amm

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.

xchain-mayachain-query

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.

xchain-midgard

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.

Midgard Configuration in mayachain-query

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 for a working example.

xchain-mayanode

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.

MAYANode Configuration in mayachain-query

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

Deploy a Kubernetes cluster in Azure using AKS service.

Requirements

1. Azure account

2. az and Azure credentials configured

3. kubectl

Steps

Firstly, clone and enter the . All commands in this section are to be run inside this repo.

Then install the :

Azure CLI

The allows you to manage your Azure services.

Kubernetes Control Tool

You must install and configure the Kubernetes CLI tool (kubectl). **To install kubectl** , follow , or choose a package manager based on your operating system.

wget && jq

You also need wget and jq, follow , or choose a package manager based on your operating system.

Deploy Kubernetes Cluster

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

CONFIGURE

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.

Memo Format

For Symmetric Adds: ADD:POOL:PAIREDADDR

For Asymmetric Adds: ADD:POOL

Procedure

Through a MAYAChain UI (using MsgDeposit, eg. El Dorado)

Symmetric Add (ASSET + CACAO)

1. Connect/Create your wallet.

2. Make sure your wallets are funded with ASSET & CACAO and they have to be of equal values.

3. 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

4. In the amount field, type the ASSET amount you wish to add (make sure you have enough amount left for fees).

5. Press send.

6. Check your transaction/Maya Address on MayaScan.

7. 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

8. In the amount field, type the CACAO amount you wish to add (make sure you have enough amount left for fees).

9. Press send.

10. Check your transaction/Maya Address on MayaScan.

Asymmetric Add

1. Connect/Create your wallet.

2. Make sure your wallets are funded.

3. 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

1. In the amount field, type the amount you wish to add (make sure you have enough amount left for fees).

2. Press send.

3. Check your transaction/Maya Address on MayaScan.

Through a Non-CACAO UI (using Normal Send tx + MsgDeposit, eg. Asgardex)

Symmetric Add (ASSET + CACAO)

1. Connect/Create your wallet.

2. 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

3. In the amount field, type the ASSET amount you wish to add (make sure you have enough amount left for fees).

4. In the address field paste ASSET Inbound Address on MAYAChain.

1. Press send.

2. Check your transaction/Maya Address on MayaScan.

1. 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

2. In the amount field, type the CACAO amount you wish to add (make sure you have enough amount left for fees).

3. Press send.

4. Check your transaction/Maya Address on MayaScan.

Asymmetric Add

1. Connect/Create your wallet.

2. 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

1. In the amount field, type the amount you wish to add (make sure you have enough amount left for fees).

2. In the address field paste ASSET Inbound Address on MAYAChain.

1. Press send.

2. Check your transaction/Maya Address on MayaScan.

Getting the Asgard Vault

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.

[
  {
		"address": "bc1qqtemwlu9ju3ts3da5l82qejnzdl3xfs3lcl4wg",
		"chain": "BTC",
		"chain_lp_actions_paused": false,
		"chain_trading_paused": false,
		"gas_rate": "390",
		"gas_rate_units": "satsperbyte",
		"global_trading_paused": false,
		"halted": false,
		"outbound_fee": "390000",
		"outbound_tx_size": "1000",
		"pub_key": "mayapub1addwnpepqvz6vkw4nzcp5sl9ktx63kz7v0n754r99uehfnzv42eauc644yzgvmuun3k"
	},
      ...

{
		"address": "0x87a8d8abd8086173e2f15a90a1938d8077e02ecb",
		"chain": "ETH",
		"chain_lp_actions_paused": false,
		"chain_trading_paused": false,
		"gas_rate": "100",
		"gas_rate_units": "gwei",
		"global_trading_paused": false,
		"halted": false,
		"outbound_fee": "840000",
		"outbound_tx_size": "80000",
		"pub_key": "mayapub1addwnpepqvz6vkw4nzcp5sl9ktx63kz7v0n754r99uehfnzv42eauc644yzgvmuun3k",
		"router": "0xe3985E6b61b814F7Cdb188766562ba71b446B46d"
	},

• 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.

Displaying available pairs

Use the /pools endpoint of Midgard to retrieve all swappable assets on MAYAChain. The response will be an array of objects like this:

{
		"annualPercentageRate": "0.1653348126078579",
		"asset": "KUJI.KUJI",
		"assetDepth": "22781179322318",
		"assetPrice": "3.621027920713548",
		"assetPriceUSD": "3.498740619649093",
		"liquidityUnits": "5385277119677037",
		"poolAPY": "0.1653348126078579",
		"runeDepth": "8249128639289561",
		"status": "available",
		"synthSupply": "31040367",
		"synthUnits": "3668841935",
		"units": "5385280788518972",
		"volume24h": "561310885869971"
	}

Decimals and Base Units

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

Finding Chain Status

There are two ways to see if a Chain is halted.

1. Looking at the /inbound_addresses endpoint and inspecting the halted flag.

2. Looking at Mimir and inspecting the HALT[Chain]TRADING setting. See Network Halts for more details.

Deploy an umnanaged Kubernetes cluster in hcloud

Requirements

1. hcloud account

2. hcloud and hcloud credentials configured

3. kubectl

4. ansible

Steps

Firstly, clone and enter the . All commands in this section are to be run inside this repo.

Then install the :