Add GitBook docs

docs/aurora-cloud/01-welcome/01-introduction.md

@@ -0,0 +1,51 @@
+# 💡 Welcome to Aurora
+
+**What is Aurora?**
+
+Aurora is an **EVM** (Ethereum Virtual Machine) compatible blockchain layer 2 on top of **Near protocol**, combining the compatibility with the Ethereum ecosystem and the performance and scalability of Near.
+
+
+
+**How is Aurora different from other Ethereum layer 2s?**
+
+Aurora is not a rollup or a side chain. It is implemented as a **smart contract** on the NEAR Protocol. This means that Aurora inherits most of the features from Near protocol such as:
+
+* **1s block time**
+* **220+** Near validators 
+* Scalability through **sharding** technology
+
+While providing ethereum compatibility:
+
+* ETH is the base token of Aurora
+* Transaction fees (gas fees) in Aurora are paid in ETH and are constant ([gas price](https://dev.aurora.dev/posts/evm-gas-near-gas-on-aurora) is 0.07 GWei, which is around **$0.003 per transaction**).
+* Aurora supports all the Ethereum ecosystem tools — [MetaMask](https://metamask.io/), [Foundry](https://github.com/foundry-rs), [Truffle](https://www.trufflesuite.com/truffle), [Hardhat](https://hardhat.org/), [Remix](https://remix.ethereum.org/), etc...
+
+
+
+**What are the TPS on Aurora?**
+
+Transactions Per Second is a common measure of performance for blockchains. Since Aurora inherits its characteristics from Near Protocol, the TPS are the same as on Near which are around **1k TPS.**
+
+Note that the TPS number depends a lot on the size of transactions (a simple transfer will be smaller than a swap for instance) so numbers can vary greatly.
+
+* During peaks, TPS on Aurora could be around **10k**
+* Thanks to the sharding technology of Near, TPS could go up to **100k** with the current shards
+* And theoretically it actually has **no limit** since sharding offers horizontal scaling
+
+
+
+**What programming language do I need to know to deploy on Aurora?**
+
+As an EVM compatible chain, smart contracts on Aurora are written in Solidity, exactly how it is done on Ethereum, Polygon, Arbitrum or any other EVM chain.  
+
+
+
+**I already have a dapp on Polygon, can I migrate to Aurora?**
+
+Absolutely, since both chains are EVM compatible, you can simply redeploy your smart contracts on Aurora without additional development, and you will instantly benefit from the **high throughput** and **low transaction costs**.
+
+
+
+**What are Virtual Chains?**
+
+Virtual Chains are dedicated instances of the Aurora Engine, customised to a specific application. Read more about Virtual Chains in the next section.

docs/aurora-cloud/01-welcome/about-virtual-chains.md

@@ -0,0 +1,36 @@
+# 📄 About Virtual Chains
+
+#### **What are Virtual Chains?**
+
+Virtual Chains are a unique innovation from Aurora providing a **dedicated** and **customised** chain, or **appchain**. 
+
+Each Virtual Chain is a copy of the **Aurora Engine** (the Aurora smart contract) and deployed on **Near**. This means that they inherit most of the performance and security features from Near:
+
+* 1s block time
+* 220+ validators from Near
+* \~$0.003 per transaction
+
+<figure><img src="/img/.gitbook/assets/image (5).png" alt=""></img><figcaption></figcaption></figure>
+
+#### **How are Virtual Chains different from other appchains (Arbitrum, Avalanche, Polygon) ?**
+
+Usually, appchains are side chains or rollups, which are completely separate blockchains from the main settlement chain. This has several consequences:
+
+* Each appchain needs to have its own **validators set**, which can be expensive to set up and run, and affects the decentralisation and security of the network. Typically, an appchain requires a minimum of 5 validators (which already comes at a cost)&#x20;
+* Appchains come empty, meaning the team will need to redevelop all the tools they might have wanted to use, such as onramps, oracles, indexers, etc... This involves third parties and can be extremely costly and time consuming.
+
+
+
+* **Instead, each Virtual Chain automatically gets all the 220 validators from Near**
+* Because Virtual Chains are smart contracts on Near, this allowed us to build tools and services that automatically support all new Virtual Chain, such as **onramp, centralised exchange support, Oracle**, etc... so that you don't have to start from scratch.
+
+
+
+**How do I get my own Virtual Chain?**
+
+Aurora has built a platform for this purpose:  [**Aurora Cloud**](https://auroracloud.dev/).
+
+Aurora Cloud proposes different plans to get your own chain, including **free transactions**, custom **professional services** and much more... in order to let you focus on **building your application**, not setting up infrastructure!
+
+
+

docs/aurora-cloud/02-run-your-own-virtual-chain/01-overview-of-aurora-cloud.md

@@ -0,0 +1,22 @@
+# Overview of Aurora Cloud
+
+[Aurora Cloud](https://auroracloud.dev/) is the platform facilitating the management of your Virtual Chains.
+
+:::info
+_To learn more about Aurora, start with_ [_this introductory article._](/aurora-cloud/welcome/introduction)
+:::
+
+On Aurora Cloud you can monitor your chain, access its parameters, explore, enable and configure add-ons, all from one simple interface.
+
+<figure><img src="/img/.gitbook/assets/Frame 827 (2).png" alt="" width="375"></img><figcaption></figcaption></figure>
+
+There are 8 major components to Aurora Cloud, all supported by default by all virtual chains:
+
+1. **Chain customisation**
+2. **Permissions management**
+3. **Gas abstraction**
+4. **On/offramp**
+5. **Oracle**
+6. **Integration with Centralised Exchanges**
+7. **Bridge support**
+8. **Access to global liquidity through Defuse**

docs/aurora-cloud/02-run-your-own-virtual-chain/02-customise-your-chain/README.md

@@ -0,0 +1,19 @@
+# Customise your Chain
+
+Virtual Chains are EVM chains deployed as smart contracts on Near Protocol and as such are fully customisable.
+
+You can select:
+
+* The unique **chainID**
+* The **base token** used for paying gas: Any ERC-20 token can be used as base token. Select existing ones such as AURORA, USDC, USDT, ETH, .... or use your own token.
+* **Permissions**: Chains can be defined as Public, Permissioned, or Private and permissions can be granted at the individual wallet address level.
+* **Gas Mechanics**: Define how gas is collected. It can be usage based or a fixed fee. 
+  * Alternatively gas can be removed for end users. The Virtual Chain owner will still need to settle transaction costs in NEAR but end users will not be required to pay gas fees.
+  * [The Gas Abstraction](../enable-gas-abstraction) feature enables more advanced logic around free transactions, allowing you to define limits and whitelists.
+
+
+
+Examples:
+
+* I create a virtual chain with USDT as the base token, and decide that each transaction will cost 0.01 $USDT. This will be defined at the chain level and all users interacting with the chain will get this transaction cost.
+* I create a virtual chain for gamin

docs/aurora-cloud/02-run-your-own-virtual-chain/02-customise-your-chain/block-explorer.md

@@ -0,0 +1,7 @@
+# Block Explorer
+
+Each Virtual Chain comes with its own Block Explorer.
+
+<figure><img src="/img/.gitbook/assets/Frame 828.png" alt="" width="375"></img><figcaption></figcaption></figure>
+
+The Block Explorer is powered by Blockscout.

docs/aurora-cloud/02-run-your-own-virtual-chain/03-manage-permissions/README.md

@@ -0,0 +1,11 @@
+# Manage permissions
+
+Aurora Chains have three different profiles of permissions:
+
+* **Public Chain**: Anyone can freely interact and deploy contracts on this chain.
+* **Public Permissioned Chain:** The chain owner decides who can interact and deploy contracts on the chain. The transactions are still public and available on the Chain Explorer.
+* **Private Chain**: A permissioned chain with fully private data. No one can see the transaction details on this chain. A private chain can be exported as a public one if requested.
+
+Permissioned Chains use whitelists of wallet addresses or user IDs to determine who can interact with it and who’s authorised to deploy contracts. These lists are fully configurable via APIs and can be linked to any third party application. A common use case is to couple them with KYC/KYB to ensure only verified users interact with the chain.
+
+The advantage of chain-level permission over contract-level permission is that once users are verified, they can freely interact with any services deployed on this chain, enabling the creation of fully compliant ecosystems.

docs/aurora-cloud/02-run-your-own-virtual-chain/03-manage-permissions/kyc-kyb.md

@@ -0,0 +1,16 @@
+# KYC/KYB
+
+Permissionned chains can be combined with any KYC/KYB provider to ensure that any user interacting with the chain has verified their identity.
+
+This is particularly useful for businesses operating in a compliant environment.
+
+
+
+**How to set up KYC for your virtual chain?**
+
+1. Create a permissioned Virtual Chain
+2. Retrieve the API endpoint for the chain interaction whitelist (Only whitelisted wallet addresses will be able to interact with the chain)
+3. Set up your KYC provider as per your preferences.
+4. During the KYC process, collect the wallet address of the user
+5. After the user passes KYC, call the whitelist API endpoint and pass the wallet address
+6. This user will now be able to interact with your Virtual Chain

docs/aurora-cloud/02-run-your-own-virtual-chain/03-manage-permissions/permissions-api.md

@@ -0,0 +1,14 @@
+# Permissions API
+
+Each Aurora Chain has two types of whitelists defining the level of permissions for end users:
+
+1. _Transaction Access Whitelist:_ to enable user accounts (EOAs) to execute transactions on your chain.
+2. _Deployment Access Whitelist:_ to enable EOAs to deploy contracts to your chain.
+
+Both of them are optional. So, if you want to allow the usage and development for everyone, both of them will be disabled. If not, you will need to manage them.
+
+:::info
+Read the full API specification at
+
+[https://doc.aurora.dev/launch-chain/reference/whitelists-api](https://doc.aurora.dev/launch-chain/reference/whitelists-api)
+:::

docs/aurora-cloud/02-run-your-own-virtual-chain/04-enable-gas-abstraction.md

@@ -0,0 +1,36 @@
+# Enable gas abstraction
+
+Aurora Virtual Chains have gas abstraction enabled by default. This allows you to control how gas fees are charged to users on the network, and to remove them completely if wanted.
+
+:::info
+The Aurora Engine is paying gas in NEAR on the Near protocol, but inside the Virtual Chain, any token can be defined as the base token and hence be used as gas fee
+:::
+
+<figure><img src="/img/.gitbook/assets/Frame 827 (3).png" alt="" width="375"></img><figcaption></figcaption></figure>
+
+**Defining the gas mechanics**
+
+Gas can be collected in different ways on a Virtual Chain:
+
+* Usage based: This is the most common method. Gas is calculated based on the transaction size and charged in the base token of the network
+* Fixed fee: To simplify user interactions, gas could be charged as a fixed fee on the Virtual Chain. For instance, the base token could be $USDT and each transaction could cost 0.01 $USDT
+
+**Advanced logic around free transactions**
+
+Free transactions are a great way to simplify onboarding of new users or to incentivise certain behaviours. But this should not be a on or off setting, and Aurora Cloud lets you define advanced ways of attributing free transactions, so that you can use it at your advantage.
+
+Aurora's infrastructure includes a rule engine that lets you define **campaigns with rules** to determine whether a transaction gets free gas or not. You are able to use and combine the following parameters:
+
+* The whitelist of wallet addresses
+* The whitelist of target contract addresses
+* A maximum number of free transactions one wallet can have
+* The timeframe for this maximum number allowed
+* An overall timeframe for this specific campaign
+
+Examples:
+
+1. **Promotional Offer**: I want that all users who interact with contract A will get 10 free transactions per month and per user. This will last until 10,000 transactions were subsidised or after 2 months after the beginning of the campaign.
+2. **User tiers**: I want that all my premium users (who are paying a subscription fee for instance) will get 50 free transactions per month when they interact with my set of 5 contracts as long as they are subscribed.
+3. **Black Friday offer**: I want that during the black friday weekend, users interacting with my DEX contracts will get 50,000 free transactions. There are no limits per user but the offer ends once the 50,000 limit is reached.
+
+&#x20;

docs/aurora-cloud/02-run-your-own-virtual-chain/05-on-offramp-to-your-chain.md

@@ -0,0 +1,58 @@
+---
+description: >-
+  The universal onramp solution on Aurora Cloud, enabling direct deposit of
+  assets on your Aurora Chain.
+---
+
+# On/offramp to your chain
+
+Enabling the purchase of assets directly on your chain by your customers is crucial for their onboarding and for the best user experience.
+
+But onramp services can be expensive, with steep setup costs (sometimes up to $100,000) and lengthy procedures.
+
+**Aurora Cloud solves this problem by providing a universal on/offramp solution, compatible with any Aurora Virtual Chain, enabling the deposit of assets from day 1 on your chain.**
+
+<figure><img src="/img/.gitbook/assets/Frame 827.jpg" alt="" width="375"></img><figcaption></figcaption></figure>
+
+**How does it work?**
+
+Since each Aurora Chain is a smart contract deployed on Near, they can seamlessly communicate with each other through the cross contract call technology (XCC).
+
+This means that assets deposited on one chain can be transferred to another chain with a simple cross contract call.
+
+In that context, when a user wants to onramp, assets are deposited first on Aurora Mainnet and then transferred to the relevant Virtual Chain.
+
+The result is an onramp solution that does not require technical development on that particular Virtual Chain, can be deployed from day 1 and enables onramp of assets in seconds.
+
+_Aurora partnered with Münzen to develop this solution._ [_Read more about Münzen_](https://munzen.io/ramp)
+
+**Adding an onramp widget to your application**
+
+Aurora Cloud Onramp provides you with a widget that can be embedded in any application for the best user experience. The widget will open a popup powered by Münzen, and the customer will be required to go through the steps and abide by any regulatory requirements (such as passing KYC if needed).
+
+**Main Benefits**
+
+* KYC-free transaction up to 100 EUR
+* 16 fiat currencies supported
+* Buy crypto in just two minutes
+
+**What countries are supported?**
+
+* Aurora Cloud Onramp supports 115 countries. The full list, including restricted countries, can be found [here](https://docs.google.com/spreadsheets/d/15geR5hByqh8XFhX6bHwq9C1g8LxH1Q1Ck0tfQEmoSzo/edit?usp=sharing). ([https://docs.google.com/spreadsheets/d/15geR5hByqh8XFhX6bHwq9C1g8LxH1Q1Ck0tfQEmoSzo/edit?usp=sharing](https://docs.google.com/spreadsheets/d/15geR5hByqh8XFhX6bHwq9C1g8LxH1Q1Ck0tfQEmoSzo/edit?usp=sharing))
+
+**What payment methods are available?**
+
+* Debit/Credit card payment (Visa and Mastercard)
+* Bank Transfer
+
+**What assets are supported?**
+
+* At the moment, stablecoins USDT and USDC are supported by default and do not require any additional setup to enable.
+
+**Can I list my own token?**
+
+* Yes, this will be subject to Münzen’s listing process and will incur a fee. Raise your interest to your Aurora Cloud Account Manager and they will introduce you to the Münzen team.
+
+**Commercials**
+
+* An additional fee can be added on top of the base rate. Please get in touch with your account manager to set it up.

docs/aurora-cloud/02-run-your-own-virtual-chain/06-pyth-oracle.md

@@ -0,0 +1,41 @@
+---
+description: Access Pyth Oracle from any Virtual Chain
+---
+
+# Pyth Oracle
+
+Aurora Cloud partnered with Pyth to propose an access to its Oracle from all Virtual Chains.
+
+**How does it work?**
+
+Thanks to the communication between Virtual Chains, your Virtual Chain can call the Pyth Oracle deployed on Aurora Mainnet to retrieve price feeds required for your on-chain logic.
+
+Pyth proposes more than x price feeds.
+
+<figure><img src="/img/.gitbook/assets/Frame 827 (4).png" alt="" width="375"></img><figcaption></figcaption></figure>
+
+**Technical Overview**
+
+Each Virtual Chain comes with the Cloud Oracle deployed on it. The Cloud Oracle proposes the same interface as the Pyth Oracle but leverages the cross contract call technology between your Virtual Chain and Aurora Mainnet to retrieve the price feed you need.
+
+
+
+**Why is this important?**
+
+The Pyth Oracle strives for decentralisation where prices are collaboratively fed by the different actors in the network.
+
+Since all Virtual Chains are communicating with the Pyth Oracle instance on Aurora Mainnet, the more chains and participants there are, the more complete, robust and decentralised its Oracle becomes.
+
+Besides, you get access from your Virtual Chain to all the other price feeds from the ecosystem, which means less development and better reliability.
+
+<figure><img src="/img/.gitbook/assets/image (3).png" alt=""></img><figcaption></figcaption></figure>
+
+
+
+**Aurora Cloud addon**
+
+The Cloud Oracle is configurable from the Aurora Cloud Console and also supports price feeds from CoinGecko, to offer an easy and instant solution to your Oracle needs.
+
+<figure><img src="/img/.gitbook/assets/image (4).png" alt="" width="563"></img><figcaption></figcaption></figure>
+
+\-> [Read about the Oracle release](https://aurora.dev/blog/aurora-cloud-data-oracle-powering-your-virtual-chain-with-reliable-data)

docs/aurora-cloud/02-run-your-own-virtual-chain/07-connect-cexes-to-your-chain.md

@@ -0,0 +1,63 @@
+# Connect CEXes to your chain
+
+<summary>Enable transfers from centralised exchanges to your Virtual Chain</summary>
+
+**The forwarder proposes another onramp solution to your users by enabling withdrawals from centralised exchanges directly onto your Virtual Chain.**
+
+<figure><img src="/img/.gitbook/assets/Frame 827 (5).png" alt="" width="375"></img><figcaption></figcaption></figure>
+
+:::info[Supported Exchanges include]
+
+**Binance, Coinbase, OKX, Bybit, Kraken, Gate.io, HTX, BItfinex, Kucoin,** and many more...
+:::
+
+The tool is currently available at [https://aurora.plus/forwarder](https://aurora.plus/forwarder) and supports all centralised exchanges that allow withdrawals to the _Near network_.
+
+<figure><img src="/img/.gitbook/assets/image (1).png" alt="" width="375"></img><figcaption></figcaption></figure>
+
+**How does it work?**
+
+The forwarder, as its name suggests, forwards any assets sent to its Near deposit address to the recipient Aurora address.&#x20;
+
+* Each user gets their own deposit address on Near.
+* When a user withdraws assets from Binance to this Near deposit address, a backend service automatically triggers a transfer from this Near deposit address to the target Virtual Chain.&#x20;
+* This process is invisible for the user who simply receives their assets on their address on your Virtual Chain.
+
+
+
+**Technical overview**
+
+The forwarder leverages the chain abstraction ability from Aurora and Near by routing assets to the target virtual chain.
+
+In technical terms, the forwarder is a smart contract deployed on Near, and has the capacity to generate a unique Near address based on an Aurora address (one per Aurora network). When the contract receives tokens that are part of the curated token list, it will automatically send these assets to the address on the Aurora network selected.
+
+
+
+<figure><img src="/img/.gitbook/assets/image (2).png" alt="" width="563"></img><figcaption></figcaption></figure>
+
+**Supported assets**
+
+These assets will be automatically forwarded to the destination address.
+
+* USDT
+* USDC
+* NEAR
+
+Any other assets sent to the deposit address will not be automatically be forwarded but **won't be lost** either.
+
+
+
+\-> [_Read more about the Forwarder release_](https://aurora.dev/blog/aurora-forwarder-is-live)_._
+
+
+
+
+
+
+
+
+
+
+
+
+