Fix .__ -> ._

blog/aurora-cloud-borealis-business.md

@@ -74,14 +74,14 @@ Borealis Business’ user journey is seamless. Once a user signs into a dApp wit
 
 ### User Journey
 
-1.  A user signs into a Decentralized App (dApp).
-2.  This dApp has a Borealis deal.
-3.  The dApp checks whether this address was added to the whitelist.
-4.  If not, the dApp decides whether to send the address for whitelisting. This depends entirely on the business logic. For example, when requesting a transaction’s signature from a whitelisted wallet, the dApp must set gasPrice to 0 because regular wallets will use the default gas price.
-5.  The user makes a transaction within the app.
-6.  The user signs the transaction.
-7.  The transaction goes through Aurora’s infrastructure, and the Borealis rule engine checks for deal matches.
-8.  It finds a match with the business deal here, so it will report the gas fees to the business, leaving the transaction gas free for the user, and will let the transaction go through and be submitted to Aurora’s internal mempool.
+1. A user signs into a Decentralized App (dApp).
+2. This dApp has a Borealis deal.
+3. The dApp checks whether this address was added to the whitelist.
+4. If not, the dApp decides whether to send the address for whitelisting. This depends entirely on the business logic. For example, when requesting a transaction’s signature from a whitelisted wallet, the dApp must set gasPrice to 0 because regular wallets will use the default gas price.
+5. The user makes a transaction within the app.
+6. The user signs the transaction.
+7. The transaction goes through Aurora’s infrastructure, and the Borealis rule engine checks for deal matches.
+8. It finds a match with the business deal here, so it will report the gas fees to the business, leaving the transaction gas free for the user, and will let the transaction go through and be submitted to Aurora’s internal mempool.
 
 Here is a scheme describing the User Journey above:
 

blog/building-a-game-using-near-aurora-and-bos.md

@@ -19,9 +19,9 @@ This post shows some code snippets to be self-contained pieces; however, not all
 
 This project consists of three components:
 
-1.  A stateless smart contract written in Rust and deployed to Near, which takes a Tic Tac Toe board state and input and returns an updated state as output.
-2.  A Solidity contract deployed to Aurora, which users interact with to start Tic Tac Toe games and make their moves. This contract uses the Near one to make a computer opponent, and it persists the users’ games in storage.
-3.  A front-end written in JavaScript that is powered by [*BOS*](https://near.org/blog/near-announces-the-blockchain-operating-system/). This is what the user interacts with directly, and it sends the transactions to the Solidity smart contract on Aurora.
+1. A stateless smart contract written in Rust and deployed to Near, which takes a Tic Tac Toe board state and input and returns an updated state as output.
+2. A Solidity contract deployed to Aurora, which users interact with to start Tic Tac Toe games and make their moves. This contract uses the Near one to make a computer opponent, and it persists the users’ games in storage.
+3. A front-end written in JavaScript that is powered by [*BOS*](https://near.org/blog/near-announces-the-blockchain-operating-system/). This is what the user interacts with directly, and it sends the transactions to the Solidity smart contract on Aurora.
 
 All of these components run on top of a blockchain platform; I did not need to acquire any hardware resources to deploy this dApp, and yet anyone can interact with it.
 

blog/communication-from-aurora-to-near-local-testing.md

@@ -8,10 +8,10 @@ image: https://www.datocms-assets.com/95026/1694085970-article-cover.png
 ---
 In this article, we will learn how to write local tests for the Aurora contracts, which use [XCC calls](/blog/cross-ecosystem-communication) to Near ecosystem. I will use a simple example to demonstrate it, step by step, we will write:
 
-1.  A simple counter contract for Near blockchain.
-2.  Contract on Aurora, which calls the contract on Near by using the XCC.
-3.  One integration test in the `sandbox`.
-4.  Setup the `git action` for running this test automatically.
+1. A simple counter contract for Near blockchain.
+2. Contract on Aurora, which calls the contract on Near by using the XCC.
+3. One integration test in the `sandbox`.
+4. Setup the `git action` for running this test automatically.
 
 The example described in this article: [https://github.com/olga24912/AuroraToNearXCCExample](https://github.com/olga24912/AuroraToNearXCCExample)
 

blog/hot-to-get-your-tokens-from-bastion-contract.md

@@ -30,9 +30,9 @@ The main actor of this article will be [`SwapFlashLoan` contract](https://explor
 
 The plan is:
 
-1.  Approve [cUSDCcUSDTLP token](https://explorer.aurora.dev/address/0x0039f0641156cac478b0DebAb086D78B66a69a01?tab=write_proxy) to be used by the `SwapFlashLoan` contract.
-2.  Get cUSDC and cUSDT from `SwapFlashLoan`.
-3.  Redeem [cUSDC](https://explorer.aurora.dev/token/0xe5308dc623101508952948b141fD9eaBd3337D99) and [cUSDT](https://explorer.mainnet.aurora.dev/address/0x845E15A441CFC1871B7AC610b0E922019BaD9826) from their contracts to get stables.
+1. Approve [cUSDCcUSDTLP token](https://explorer.aurora.dev/address/0x0039f0641156cac478b0DebAb086D78B66a69a01?tab=write_proxy) to be used by the `SwapFlashLoan` contract.
+2. Get cUSDC and cUSDT from `SwapFlashLoan`.
+3. Redeem [cUSDC](https://explorer.aurora.dev/token/0xe5308dc623101508952948b141fD9eaBd3337D99) and [cUSDT](https://explorer.mainnet.aurora.dev/address/0x845E15A441CFC1871B7AC610b0E922019BaD9826) from their contracts to get stables.
 
 ## Approve cUSDCcUSDTLP
 
@@ -75,9 +75,9 @@ Now, let's scroll down a bit and click on "View details" link at the left bottom
 
 We can conclude by looking at the both screenshots above that:
 
-1.  `amount` argument is equal to your `cUSDCcUSDTLP` tokens amount with 18 decimals added. E.g. in this case, the user has 2021.941835489438, so the correct value should be 2021294184354893800000. You can use [this tool](https://www.eth-to-wei.com/) to convert your values.
-2.  `deadline` is your time now, with 20 minutes added to it in a timestamp format. You can use [the EpochConverter](https://www.epochconverter.com/) tool to get the correct value. Just add 20 minutes to the datetime there and copy-paste the timestamp value.
-3.  The first value in `minAmounts` corresponds to the `cUSDT` token amount transferred back, and the second one is for the `cUSDC`. They have 8 decimals, and if you sum them up, you will get your amount of `cUSDCcUSDTLP` tokens. So you can just enter any values which in sum give you a value smaller or equal to the `amount`.
+1. `amount` argument is equal to your `cUSDCcUSDTLP` tokens amount with 18 decimals added. E.g. in this case, the user has 2021.941835489438, so the correct value should be 2021294184354893800000. You can use [this tool](https://www.eth-to-wei.com/) to convert your values.
+2. `deadline` is your time now, with 20 minutes added to it in a timestamp format. You can use [the EpochConverter](https://www.epochconverter.com/) tool to get the correct value. Just add 20 minutes to the datetime there and copy-paste the timestamp value.
+3. The first value in `minAmounts` corresponds to the `cUSDT` token amount transferred back, and the second one is for the `cUSDC`. They have 8 decimals, and if you sum them up, you will get your amount of `cUSDCcUSDTLP` tokens. So you can just enter any values which in sum give you a value smaller or equal to the `amount`.
 
 We're ready to execute the method now. Just enter the correct arguments to your Explorer tab, it should look like this:
 

blog/how-to-get-usdc-tokens-on-aurora-testnet.md

@@ -18,10 +18,10 @@ In this article, I will explain how to get official native Ethereum ERC-20 token
 
 For getting USDC tokens, we're going to use the following plan:
 
-1.  Create an account in MetaMask for the Ethereum Goerli network and Aurora testnet
-2.  Mint Ether for your Ethereum account
-3.  Swap Ether to the USDC tokens in the Ethereum network
-4.  Transfer USDC tokens from Ethereum to Aurora by using Rainbow Bridge
+1. Create an account in MetaMask for the Ethereum Goerli network and Aurora testnet
+2. Mint Ether for your Ethereum account
+3. Swap Ether to the USDC tokens in the Ethereum network
+4. Transfer USDC tokens from Ethereum to Aurora by using Rainbow Bridge
 
 The instructions for steps 1 and 2 you can find in article ["Getting started with Aurora"](/blog/getting-started-with-aurora), so I will not describe them here. For the 1 step see section "Creating an account on the Aurora testnet using MetaMask", for the 2 step see section "Obtaining AuroraEth on the testnet" -> "The second method: transfer from Ethereum".
 

blog/spinning-up-your-own-aurora-node.md

@@ -37,11 +37,11 @@ This installation script is called [standalone-rpc](https://github.com/aurora-is
 
 First, we can split the whole process into a set of steps:
 
-1.  Generate NEAR account and signing key.
-2.  Generating configuration files for relayer, refiner, and nginx.
-3.  Download the latest database snapshot for relayer (optional, but recommended).
-4.  Download the latest NEAR Node Data Snapshot and configuration, that is required to correctly run the refiner in `nearcore` mode.
-5.  Set up AWS credentials if instead of `nearcore` mode you decided to run the refiner in `nearlake` mode.
+1. Generate NEAR account and signing key.
+2. Generating configuration files for relayer, refiner, and nginx.
+3. Download the latest database snapshot for relayer (optional, but recommended).
+4. Download the latest NEAR Node Data Snapshot and configuration, that is required to correctly run the refiner in `nearcore` mode.
+5. Set up AWS credentials if instead of `nearcore` mode you decided to run the refiner in `nearlake` mode.
 
 Download and start four docker containers: `relayer`, `refiner`, `watchtower`, and `nginx`.
 
@@ -55,8 +55,8 @@ When running your own relayer, if you intend to send a transaction via `eth_send
 
 Before diving into the configuration, let's discuss what are the different options to run the Relayer. It's pretty straightforward.
 
-1.  You can run `relayer` in mainnet or testnet mode.
-2.  You can use `nearlake` or `nearcore` as a source of data for the `refiner`.
+1. You can run `relayer` in mainnet or testnet mode.
+2. You can use `nearlake` or `nearcore` as a source of data for the `refiner`.
 
 Choosing to run the mainnet or testnet is quite self-explanatory. But the second option is not.
 
@@ -76,10 +76,10 @@ The `refiner` can also be run in `nearlake` mode. This mode does not require you
 
 The final step of the whole process is to download docker containers and start them. It will be done for you. The containers that will be running are:
 
-1.  `nearaurora/srpc2-relayer` – JSON RPC server and indexer.
-2.  `nearaurora/srpc2-refiner` – [Aurora Refiner](https://github.com/aurora-is-near/borealis-engine-lib) .
-3.  `nearaurora/reverseproxy` – Nginx (used to isolate backend server from the outer world, redirects requests to the relayer container).
-4.  `containerrr/watchtower` – service that will check on any updates, and will update images accordingly.
+1. `nearaurora/srpc2-relayer` – JSON RPC server and indexer.
+2. `nearaurora/srpc2-refiner` – [Aurora Refiner](https://github.com/aurora-is-near/borealis-engine-lib) .
+3. `nearaurora/reverseproxy` – Nginx (used to isolate backend server from the outer world, redirects requests to the relayer container).
+4. `containerrr/watchtower` – service that will check on any updates, and will update images accordingly.
 
 ### Conclusions
 

docs/dev-tools/basics/truffle.md

@@ -11,11 +11,11 @@ This example is originally forked from the [OpenZeppelin examples](https://docs
 
 ![](https://www.datocms-assets.com/95026/1679442341-truffle_nft_example-a9d17b3f4f30477f3f6d67c4336f20e5.png)
 
-1.  The minter address (which is managed by the vaccination program manager) can distribute (mint) the vaccine tickets (NFT tokens 💊💊💊) to the people who are part of the vaccination program.
-2.  When participants receive the tokens 💊, they can get access to the vaccine by spending the NFT token.
-3.  This means either burning the NFT token or sending it back to the minter address.
-4.  If the participant chooses to send it back then the minter can redistribute that token 🎫 to another participant in the line.
-5.  Then the new participant will have access to the same vaccine token that has been used by the previous participant.
+1. The minter address (which is managed by the vaccination program manager) can distribute (mint) the vaccine tickets (NFT tokens 💊💊💊) to the people who are part of the vaccination program.
+2. When participants receive the tokens 💊, they can get access to the vaccine by spending the NFT token.
+3. This means either burning the NFT token or sending it back to the minter address.
+4. If the participant chooses to send it back then the minter can redistribute that token 🎫 to another participant in the line.
+5. Then the new participant will have access to the same vaccine token that has been used by the previous participant.
 
 ## Installing Prerequisites[​](https://doc.aurora.dev/interact/truffle#installing-prerequisites "Direct link to heading")
 

docs/dev-tools/cloud/aurora-pass.md

@@ -57,7 +57,7 @@ The Ethereum tooling is constantly evolving and improving so it is recommended t
 
 ### **A simple Web3Modal example to get started.**
 
-1.  Add packages:
+1. Add packages:
 
 ```shell
 yarn add @web3modal/ethereum @web3modal/react wagmi ethers@^5

docs/dev-tools/cloud/borealis-business.md

@@ -67,14 +67,14 @@ Borealis Business’ user journey is seamless. Once a user signs into a dApp wit
 
 ### User Journey
 
-1.  A user signs into a Decentralized App (dApp).
-2.  This dApp has a Borealis deal.
-3.  The dApp checks whether this address was added to the whitelist.
-4.  If not, the dApp decides whether to send the address for whitelisting. This depends entirely on the business logic. For example, when requesting a transaction’s signature from a whitelisted wallet, the dApp must set gasPrice to 0 because regular wallets will use the default gas price.
-5.  The user makes a transaction within the app.
-6.  The user signs the transaction.
-7.  The transaction goes through Aurora’s infrastructure, and the Borealis rule engine checks for deal matches.
-8.  It finds a match with the business deal here, so it will report the gas fees to the business, leaving the transaction gas free for the user, and will let the transaction go through and be submitted to Aurora’s internal mempool.
+1. A user signs into a Decentralized App (dApp).
+2. This dApp has a Borealis deal.
+3. The dApp checks whether this address was added to the whitelist.
+4. If not, the dApp decides whether to send the address for whitelisting. This depends entirely on the business logic. For example, when requesting a transaction’s signature from a whitelisted wallet, the dApp must set gasPrice to 0 because regular wallets will use the default gas price.
+5. The user makes a transaction within the app.
+6. The user signs the transaction.
+7. The transaction goes through Aurora’s infrastructure, and the Borealis rule engine checks for deal matches.
+8. It finds a match with the business deal here, so it will report the gas fees to the business, leaving the transaction gas free for the user, and will let the transaction go through and be submitted to Aurora’s internal mempool.
 
 Here is a scheme describing the User Journey above:
 

docs/dev-tools/indexers/covalent.md

@@ -5,8 +5,8 @@ title: Covalent
 
 Covalent maintains a full archival copy of every supported blockchain, meaning every balance, transaction, log event, and NFT asset data is available from the genesis block. This data is available via:
 
-1.  [Unified API](https://dillinger.io/#unified-api) - Incorporate blockchain data into your app with a familiar REST API
-2.  [Increment](https://dillinger.io/#increment) - Create and embed custom charts with no-code analytics
+1. [Unified API](https://dillinger.io/#unified-api) - Incorporate blockchain data into your app with a familiar REST API
+2. [Increment](https://dillinger.io/#increment) - Create and embed custom charts with no-code analytics
 
 **Use Covalent if you need:**
 

docs/dev-tools/oracles/dia.md

@@ -1,7 +1,11 @@
 ---
 title: DIA
 ---
-DIA is an ecosystem for open financial data in a financial smart contract ecosystem. The target of DIA is to bring together data analysts, data providers and data users. In general, DIA provides a reliable and verifiable bridge between off-chain data from various sources and on-chain smart contracts that can be used to build a variety of financial dApps. DApp developers who want to leverage DIA oracles can access the published data on Aurora. DIA offers data about traditional financial assets and cryptocurrencies. [Read our documentation](https://docs.diadata.org/) to learn about our methodologies, API, oracles, and how to contribute.
+DIA is an ecosystem for open financial data in a financial smart contract ecosystem. 
+
+The target of DIA is to bring together data analysts, data providers and data users. In general, DIA provides a reliable and verifiable bridge between off-chain data from various sources and on-chain smart contracts that can be used to build a variety of financial Dapps.
+
+Developers who want to leverage DIA oracles can access the published data on Aurora. DIA offers data about traditional financial assets and cryptocurrencies. [Read our documentation](https://docs.diadata.org/) to learn about our methodologies, API, oracles, and how to contribute.
 
 ### Supported Assets
 
@@ -61,23 +65,23 @@ contract DIAOracle {
 }
 
 contract DiaAssetBtcOracle {
-	DIAOracle oracle;
-	address owner;
+    DIAOracle oracle;
+    address owner;
     
-	constructor() public {
-		owner = msg.sender;
-	}
+    constructor() public {
+        owner = msg.sender;
+    }
     
-	function setOracleAddress(address _address) public {
-		require(msg.sender == owner);
-		oracle = DIAOracle(_address);
-	}
+    function setOracleAddress(address _address) public {
+        require(msg.sender == owner);
+        oracle = DIAOracle(_address);
+    }
     
-	function getAssetBtcRate(string asset) constant public returns (uint256) {
-		(uint assetPrice,) = oracle.getValue(asset);
-		(uint btcPrice,) = oracle.getValue("BTC/USD");
-		return (assetPrice / btcPrice);
-	}
+    function getAssetBtcRate(string asset) constant public returns (uint256) {
+        (uint assetPrice,) = oracle.getValue(asset);
+        (uint btcPrice,) = oracle.getValue("BTC/USD");
+        return (assetPrice / btcPrice);
+    }
     
 }
 ```

docs/dev-tools/oracles/redstone.md

@@ -37,8 +37,8 @@ RedStone Oracles can be integrated with EVM-compatible chains out of the box tha
 
 If you want to test your chain there is an example contract and script [here](https://github.com/redstone-finance/redstone-showroom/tree/main/example). You need to follow two steps:
 
-1.  Deploy integration example contract to your chain
-2.  Fill in missing parameters and run an example Typescript script that does the following things:
+1. Deploy integration example contract to your chain
+2. Fill in missing parameters and run an example Typescript script that does the following things:
 
 * fetches data from the decentralized cache layer,
 * adds signed price data to transaction data,

docs/dev-tools/quickstart.md

@@ -4,4 +4,4 @@ title: Choose a category
 
 import DocCardList from '@theme/DocCardList';
 
-<DocCardList />
+<DocCardList />