In this article, we will discuss how to bridge liquidity to Aurora in the most convenient way. We will focus on stablecoins, explain why we have four types of these on Aurora, and take a look at how to bridge them in different ways. Note that this whole bridging process also applies to the ERC-20 tokens.
Recently, we became aware of this issue and the lack of a way to do it in the Bastion UI, so we decided to create a tutorial for everyone to use independently. Big thanks to the people in the community who helped me create and test this tutorial and provided invaluable insights and feedback!
To formulate the problem more precisely, a user has some cUSDCcUSDTLP tokens and wants to convert these back to stables. The Bastion project's UI doesn't allow this today, so the only way is to call smart contracts directly.
We will go through the next steps:
cUSDC and cUSDT into regular stables?We will use the most convenient way for users to interact with smart contracts—the Explorer. However, devs can always write a script to perform the steps described in this article with Ethers or Web3.js.
Let's go!
In this article, we will discuss how to manage your staking on the Aurora Validator. To recap quickly, Aurora is an EVM-compatible blockchain running as an L2 on the Near Protocol. In the heart of it is an Aurora Engine smart contract. That is why every transaction on Aurora is relayed to the Near and has the corresponding Near transaction. You can read more about this here. That is why Aurora doesn’t have its own validators – we’re just re-using the Near ones.
Some common functionality is required for many smart contracts. Examples are temporarily pausing certain features, staging and deploying a new version of the contract, and restricting access to contract methods. While such functionality is out of scope for an SDK like near-sdk-rs, ideally it is not implemented anew for every smart contract.
The most obvious benefits of an open-source library are reusability and the value it adds to the ecosystem. The smart contract features mentioned above can be tricky to implement and cumbersome to test. Without a library, developers might gloss over functionality that does not add business value but still is critical for security. As near-plugins is open-source and used by many developers, there are more engineering hours and eyeballs dedicated to it compared to a solution specific to a single smart contract.
In previous posts, we have written about the cross-contract calls (XCC) feature on Aurora. These include an overview, an application, and a deep dive into writing tests.
In this post, we continue with the XCC technical deep dive by discussing in more detail handling XCC results using callbacks. In particular, we focus on the concrete example of needing to refund tokens to a user in the event of an error. Along the way, this example will reveal a bit of a “gotcha” which developers new to the XCC feature may come across, and we’ll discuss how to overcome it.
Token burning is the act of permanently removing a certain number of tokens from circulation. This article delves into its intricacies and offers guidance based on my real-world experiences at Aurora
In this article, we will learn how to write local tests for the Aurora contracts, which use XCC calls to Near ecosystem. I will use a simple example to demonstrate it, step by step, we will write:
sandbox.git action for running this test automatically.The example described in this article: https://github.com/olga24912/AuroraToNearXCCExample
Recently, Michael Birch gave a talk at a virtual Rust conference about some work we have done here at Aurora to enable our technology. In case you missed it, this blog post is a written version of the talk.
That talk was aimed at a more general audience, giving background about Aurora, Near, and blockchain technology in general. However, this post assumes you are already familiar with most of the Aurora/Near/blockchain background (you are here on our website, after all) and instead focuses more on the Rust side of things.
When you develop a contract, quite often you need ERC-20 tokens for testing. If your contract is rather small and doesn't use cross-contract calls, most likely, you don't need official USDC tokens or any other specific tokens. In that case, the best solution is just to take the standard ERC-20 contract, deploy it, and mint as many test tokens as you wish.
However, sometimes the easier solution for testing can be to get official testing tokens. For example, if your contract is use difficult cross-contract calls and dependencies contracts are already deployed on testnet and support only limited numbers of tokens. When I am testing RainbowBridge during development I use the USDC tokens on testnet.
In this article, I will explain how to get official native Ethereum ERC-20 tokens on your Aurora testnet account in the example of USDC tokens. This method will work with other popular native Ethereum ERC-20 as well, and it will be clear how to get these tokens also in Goerli Ethereum and in Near testnet.
A core piece of Aurora’s technology is the Aurora Engine smart contract, which is an Ethereum Virtual Machine (EVM) implementation deployed as a smart contract on Near. Therefore, Aurora sits at the intersection of both EVM and Near runtimes. It naturally draws us to think about comparisons between EVM and Near.
For example, the concept of “gas” exists in both the EVM and Near’s runtime. The reason is because of the famous halting problem, which says we cannot know in advance if an arbitrary computer program will finish in a finite time. In the context of a smart contract platform, this means we must measure (and limit) the computation the contract does at runtime. In both the EVM and Near, “gas” is the unit that is used to measure the computational work done by a smart contract.
Even though EVM gas and Near gas both measure the same thing, they are not identical. One analogy is miles and kilometers; both measure distance, but the numerical value of the same physical distance will be different depending on which unit is used. Computation is a more abstract concept than distance, but this analogy leads us to expect some kind of approximately linear relationship between EVM gas and Near gas, similar to how 1 mile equals 1.61 kilometers.
In this blog post, we explore this question and discuss the implications for developers building on Aurora.
Since its inception, the Aurora Protocol has continued to break boundaries in the blockchain world. Its latest innovation is a service known as Borealis Business, aimed at solving one of the most significant challenges for users of Web3 products – the concept of transaction fees.
This article is a practical guide for beginners who want to learn how to work with the Aurora blockchain. It covers various aspects such as the connection of Aurora with Ethereum and Near blockchains, setting up an account on the Aurora's testnet using MetaMask, writing a small smart contract, and interacting with it using the Hardhat. Additionally, it includes writing a simple test and exploring different explorers to view transaction details.
The article assumes no prior knowledge of Ethereum or experience working with it. However, it does expect basic programming skills, familiarity with the command line, and a general understanding of blockchain and smart contracts. All commands provided in the article will be specific to the Linux operating system.
At Aurora Labs, we encourage everyone to use mainnet.aurora.dev or testnet.aurora.dev to build and deploy their apps. Those endpoints are scalable and reliable. When registering at https://aurora.plus you can even get a bunch of free transactions (soon through the Aurora Pass wallet).
That said, many dapps that are deployed on Aurora rely on running their own JSON-RPC Etherium-compatible server. Here we call this server – a relayer. You've probably already read the details about our new version of it in How the Aurora Relayer 2.0 works?
The main goal of this article is to understand the Aurora Chain code. In a future post, we will discuss how it embellishes the Aurora Engine and how the advantages of an Aurora Chain correspond to different parts of code and Aurora architecture.
In this blog post, we explore building a simple Tic Tac Toe game using the Near ecosystem’s tech stack. This includes using Aurora for a seamless onboarding experience (free transactions), Near for complex smart contract logic, and BOS for the front end. The final result is a free-to-use, fully decentralized application that anyone can pick up and play.
Aurora Chains are dedicated blockchains that go beyond mere Ethereum compatibility through a set of industry-first innovations like:
Every Aurora Chain is based upon the Aurora smart contract. 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.
If you feel your business could benefit from its own blockchain, please do not hesitate to contact us at hello@auroracloud.dev.
Let's do a walkthrough demo of Aurora Innovation Chain to see how it benefits your users.
Aurora’s infrastructure is built upon an innovative combination—our Ethereum Virtual Machine (EVM) operates as a smart contract running atop the powerful NEAR protocol. Harnessing NEAR's innate ability for smart contracts to communicate with one another, we seamlessly route EVM-compatible transactions to any smart contract deployed within NEAR. By doing so, developers are granted unparalleled access to the best of both ecosystems - from a rich collection of sound and robust Solidity libraries to the groundbreaking NEAR accounts model and an ever-growing, expansive user base.
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 for the Aurora EngineIt 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.
In this Tips & Tricks article, we will learn how to get a NEAR transaction hash by having the Aurora transaction's one.
In this blog post, I want to discuss transaction failures on the Aurora blockchain and guide developers in understanding what exactly has happened with your transaction.
tl;dr: just use Aurora Helpers dApp and get the Near transaction error code there