Fix blog linter errors

Author: Karkunow

blog/aurora-chains-demo.md

@@ -11,7 +11,7 @@ Aurora Chains are dedicated blockchains that go beyond mere Ethereum compatibili
 * *custom token & fee mechanics* (e.g., gasless transactions; paying for gas with a custom token; some percentage of any transaction value to be stored in Aurora Chain Treasury, etc.);
 * *custom access control* (public vs private chain, who can transact, who can deploy contracts? e.g., NFT-based access to the blockchain, private chain can be built by using a private NEAR shard – [Calimero](https://www.calimero.network/));
 * *seamless interoperability* with Aurora, NEAR, and any other Aurora Chains: you can freely move your assets using Rainbow Bridge, call contracts via cross-contract calls, etc.; This is the main difference between Chains and other solutions (like Avalanche or Cosmos). There is no disjointness in between. You can call any smart contract in any other Chain or Near and interact with it freely.
-* *tremendous transaction throughput – *we can provide you with dozens of millions of transactions daily for your ecosystem.
+* *tremendous transaction throughput* – we can provide you with dozens of millions of transactions daily for your ecosystem.
 
 Every Aurora Chain is based upon the [Aurora smart contract.](https://github.com/aurora-is-near/aurora-engine/) Aurora Chain is just another instance of it that can be configured in way that will work in the best way possible to be aligned with your business model and goals. The Aurora Labs team will gladly help you maintain and support your chain.
 
@@ -112,7 +112,7 @@ We now notice that your Aurora Innovation balance has been topped up in the top-
 ![](https://www.datocms-assets.com/95026/1682519404-screenshot-2023-04-26-at-15-28-37.png)
 
 We will see there our bridge transfer which has been done using a call to the NEP-141 token:\
-*aaaaaa20d9e0e2461697782ef11675f668207961.factory.bridge.near *which represent AURORA token on NEAR. And that balance of the [aurora-silo-dev.near](https://nearblocks.io/address/aurora-silo-dev.near) has been topped up, which is our Aurora Chain contract on NEAR, the little brother of the [aurora.near,](https://nearblocks.io/address/aurora.near) but with the same capabilities in a nutshell.
+*aaaaaa20d9e0e2461697782ef11675f668207961.factory.bridge.near* which represent AURORA token on NEAR. And that balance of the [aurora-silo-dev.near](https://nearblocks.io/address/aurora-silo-dev.near) has been topped up, which is our Aurora Chain contract on NEAR, the little brother of the [aurora.near,](https://nearblocks.io/address/aurora.near) but with the same capabilities in a nutshell.
 
 ### Contract Deployment Rights
 

blog/aurora-cloud-borealis-business.md

@@ -16,7 +16,9 @@ Borealis Business is a transaction processing and accounting service that allows
 
 Aurora has a relaying architecture mapping Aurora to NEAR transactions, separating the origination and payment. At the core of the Borealis Business is the Rule Engine (BBRE), which oversees this transaction relaying to fulfill its cost management goals. It allows the transfer of transaction costs to a third party–typically a decentralized app (dApp)–that seeks to cover its users' fees. This way, businesses can make their users' experience friction-free by shouldering transaction fees.
 
-Companies can establish Customer Deals through the Rule Engine by setting specific rules determining who should pay for a transaction and under what conditions. E.g., incoming transactions to the Aurora+ staking contract are now made free in this way. The strategies which Rule Engine allows are particularly advantageous for companies seeking to offer region-specific or time-bound promotions. For instance, businesses can provide free transactions exclusively to their European customers around the clock while extending this offer to customers from other regions only on weekends. This level of customization empowers companies to accommodate diverse business models and opens up possibilities for novel concepts, including cross-business interactions.
+Companies can establish Customer Deals through the Rule Engine by setting specific rules determining who should pay for a transaction and under what conditions. E.g., incoming transactions to the Aurora+ staking contract are now made free in this way. The strategies which Rule Engine allows are particularly advantageous for companies seeking to offer region-specific or time-bound promotions.
+
+For instance, businesses can provide free transactions exclusively to their European customers around the clock while extending this offer to customers from other regions only on weekends. This level of customization empowers companies to accommodate diverse business models and opens up possibilities for novel concepts, including cross-business interactions.
 
 ## Setting Up a Deal
 

blog/aurora-relayer-2-0.md

@@ -8,7 +8,7 @@ image: https://www.datocms-assets.com/95026/1682082014-relayer-article-cover.png
 ---
 In the blockchain world, relayers are off-chain facilitators of data exchange and transactions between blockchain networks and/or layers. They are used primarily in decentralized finance applications, cross-chain communication, and Layer 2 solutions, like sidechains or state channels. In general, relayers listen for events and transactions from one point and then submit the corresponding data or transactions to another. For that, they can charge fees for their services, incentivizing them to operate and maintain their infrastructure.
 
-Initially developed in-house at NEAR, the Aurora EVM is the official EVM for the NEAR ecosystem. Powered by the SputnikVM, it accomplishes a 1:1 experience with the Ethereum protocol. This compatibility between Aurora and Ethereum is achieved by the **Aurora Relayer, **a** **JSON-RPC compatible server with Ethereum's [Web3 API](https://eth.wiki/json-rpc/API) for the [Aurora Engine. ](https://github.com/aurora-is-near/aurora-engine)It has its own internal database to serve multiple read methods and an indexer that is constantly following the head and indexing blocks, transactions and logs to that internal database
+Initially developed in-house at NEAR, the Aurora EVM is the official EVM for the NEAR ecosystem. Powered by the SputnikVM, it accomplishes a 1:1 experience with the Ethereum protocol. This compatibility between Aurora and Ethereum is achieved by the **Aurora Relayer**, a JSON-RPC compatible server with Ethereum's [Web3 API](https://eth.wiki/json-rpc/API) for the [Aurora Engine](https://github.com/aurora-is-near/aurora-engine)It has its own internal database to serve multiple read methods and an indexer that is constantly following the head and indexing blocks, transactions and logs to that internal database.
 
 <!-- truncate -->
 
@@ -20,7 +20,9 @@ The Relayer had [its first version](https://github.com/aurora-is-near/aurora-rel
 
 ![](https://www.datocms-assets.com/95026/1680267251-relayer-10.png)
 
-Relayer 2.0 was motivated by the necessity of migrating from JavaScript to a more reliable language like golang that is designed for concurrency and is particularly good at managing multiple connections and resource-intensive tasks, making it very well-suited for the type of high-performance RPC systems required in blockchains. Additionally, it required migrating to a more efficient database system, so it was migrated from `PostgreSQL` to ` badger-db  `an embedded key-value database. As a result, there is now a relayer with faster execution speed,  lower machine resource usage, and lower data latency that is easier to code, debug, optimize, and deploy. Now, let’s have a general overview of some of the internals of the Relayer.
+Relayer 2.0 was motivated by the necessity of migrating from JavaScript to a more reliable language like golang that is designed for concurrency and is particularly good at managing multiple connections and resource-intensive tasks, making it very well-suited for the type of high-performance RPC systems required in blockchains.
+
+Additionally, it required migrating to a more efficient database system, so it was migrated from `PostgreSQL` to `badger-db` an embedded key-value database. As a result, there is now a relayer with faster execution speed,  lower machine resource usage, and lower data latency that is easier to code, debug, optimize, and deploy. Now, let’s have a general overview of some of the internals of the Relayer.
 
 #### **The JSON-RPC**
 
@@ -36,14 +38,20 @@ BadgerDB—our database of choice—is an embeddable, persistent, fast key-value
 
 #### **The Indexer**
 
-The new embedded indexer continuously reads JSON files generated by the [Aurora Refiner](https://github.com/aurora-is-near/borealis-engine-lib) that populate a local database. The refiner allows users to download all NEAR Blocks and get all information relevant to Aurora. NEAR Blocks data can be consumed from two different sources: the [NEAR data lake](https://docs.near.org/concepts/advanced/near-lake-framework)— a repository of blocks and events from the NEAR network as JSON files on AWS — and an archival instance, [the NEARCore](https://github.com/near/nearcore). In general, Aurora Relayer infrastructure implements an indexer of NEAR blocks, an indexer of blocks from `tar` backups and an indexer of pre-history blocks (height < 34 mln). An open-source repository for the Aurora Refiner can be found [*here*](https://github.com/aurora-is-near/borealis-engine-lib).
+The new embedded indexer continuously reads JSON files generated by the [Aurora Refiner](https://github.com/aurora-is-near/borealis-engine-lib) that populate a local database. The refiner allows users to download all NEAR Blocks and get all information relevant to Aurora.
+
+NEAR Blocks data can be consumed from two different sources: the [NEAR data lake](https://docs.near.org/concepts/advanced/near-lake-framework)— a repository of blocks and events from the NEAR network as JSON files on AWS — and an archival instance, [the NEARCore](https://github.com/near/nearcore). In general, Aurora Relayer infrastructure implements an indexer of NEAR blocks, an indexer of blocks from `tar` backups and an indexer of pre-history blocks (height < 34 mln). An open-source repository for the Aurora Refiner can be found [*here*](https://github.com/aurora-is-near/borealis-engine-lib).
 
 #### **And more…**
 
-In addition, and due to the nature of Aurora’s relayer infrastructure and its interactions with the NEAR network, it was possible to upgrade our internal infrastructure to use our relayer with additions that allow the implementation–among other things–of complex multi-tenant, rule-based accounting systems that support virtually any possible way to account for transactions, to enforce gas prices, pre- or post-run transactions, etc. So it is possible to have users with prepaid fees, prepaid gas, no gas, and many other configurations for distributing gas and fees between relayers, users, and owners of smart contracts. This means that anyone willing to spin a relayer will have access to more sophisticated economic mechanisms for its users or on behalf of others, thus acting the same way ERC-4337 bundlers do, i.e., as validators who earn incentives for completing transactions.
+In addition, and due to the nature of Aurora’s relayer infrastructure and its interactions with the NEAR network, it was possible to upgrade our internal infrastructure to use our relayer with additions that allow the implementation–among other things–of complex multi-tenant, rule-based accounting systems that support virtually any possible way to account for transactions, to enforce gas prices, pre- or post-run transactions, etc.
+
+So it is possible to have users with prepaid fees, prepaid gas, no gas, and many other configurations for distributing gas and fees between relayers, users, and owners of smart contracts. This means that anyone willing to spin a relayer will have access to more sophisticated economic mechanisms for its users or on behalf of others, thus acting the same way ERC-4337 bundlers do, i.e., as validators who earn incentives for completing transactions.
 
 ### **The Future of User Experience**
 
-By improving efficiency and reliability and by adding innovative functionality into the relayer, Aurora builders and developers can offer faster, more robust applications and significant improvements to the user’s experience where — among other things — per-transaction fees could be eliminated and accounts could be detached from keys. Therefore, the Aurora Relayer stands as a groundbreaking innovation in the world of decentralised blockchain technologies. Furthermore, as we continue to see rapid advancements and increasing adoption, the Aurora Relayer sets the stage for a more interconnected and efficient future with the potential to unlock unprecedented levels of usability, scalability, security, and cost-effectiveness, ultimately contributing to a more accessible landscape for all types of users.
+By improving efficiency and reliability and by adding innovative functionality into the relayer, Aurora builders and developers can offer faster, more robust applications and significant improvements to the user’s experience where — among other things — per-transaction fees could be eliminated and accounts could be detached from keys.
+
+Therefore, the Aurora Relayer stands as a groundbreaking innovation in the world of decentralised blockchain technologies. Furthermore, as we continue to see rapid advancements and increasing adoption, the Aurora Relayer sets the stage for a more interconnected and efficient future with the potential to unlock unprecedented levels of usability, scalability, security, and cost-effectiveness, ultimately contributing to a more accessible landscape for all types of users.
 
 If you are interested in getting to know Aurora Relayers in more depth, in our next post, we will teach you how to modify and launch a stand-alone version of the relayer that can be called by a smart contract that can execute functions without charging gas to its callers, stay tuned!

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

@@ -117,7 +117,9 @@ pub struct GetMoveResponse {
 }
 ```
 
-The nice thing about this being a stateless contract is that you can interact with it entirely using view calls (essentially using Near as a serverless computation platform). I wrote a [*front-end powered by BOS*](https://alpha.near.org/birchmd.near/widget/tic-tac-toe) to directly interact with this Near contract to illustrate this point. Since no transactions are actually sent to the chain, it’s much more responsive than the final product we’re building toward in this post. But stateless computing has limited applications, so committing transactions on-chain to access the state is still important in real-world use cases. For this, we are making use of Aurora.
+The nice thing about this being a stateless contract is that you can interact with it entirely using view calls (essentially using Near as a serverless computation platform).
+
+I wrote a [*front-end powered by BOS*](https://alpha.near.org/birchmd.near/widget/tic-tac-toe) to directly interact with this Near contract to illustrate this point. Since no transactions are actually sent to the chain, it’s much more responsive than the final product we’re building toward in this post. But stateless computing has limited applications, so committing transactions on-chain to access the state is still important in real-world use cases. For this, we are making use of Aurora.
 
 ### Aurora contract
 

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

@@ -470,7 +470,9 @@ In this section, we will write a function that calls the `incrementXCC` method i
 
 Let's write `increment` function in our test now, which will call the `incrementXCC` from the Aurora's contract. We'll provide as input: (1) aurora engine contract deployed in the sandbox, (2) the near account of the user which will sign the transaction, (3) the counter contract deployed on aurora.
 
-Notice that we're going to call the method in the aurora contract, but in this function, the user account ID on Near is provided. We can do this because it is possible to call the aurora's counter contract method by using `call` method from the Aurora Engine contract. In that case, the near user will sign a transaction, but inside the Aurora Engine, there is [an implicit mapping](https://github.com/aurora-is-near/aurora-engine/blob/71980db92a9d4b95d4e1f53954b98e0e8f002a4b/engine-sdk/src/types.rs#L28) between the near account ID and aurora addresses. And it is precisely how we will communicate with the contract in our test.
+Notice that we're going to call the method in the aurora contract, but in this function, the user account ID on Near is provided. We can do this because it is possible to call the aurora's counter contract method by using `call` method from the Aurora Engine contract.
+
+In that case, the near user will sign a transaction, but inside the Aurora Engine, there is [an implicit mapping](https://github.com/aurora-is-near/aurora-engine/blob/71980db92a9d4b95d4e1f53954b98e0e8f002a4b/engine-sdk/src/types.rs#L28) between the near account ID and aurora addresses. And it is precisely how we will communicate with the contract in our test.
 
 Now, let's first encode the arguments for the `call` method in the `AuroraEngine` contract on Near and after that – submit a transaction and check its result: