An Introduction to NEAR
Alternative smart contract blockchains continue to gain traction. Whereas Ethereum used to command >95% of market share in total locked value (TVL) at the beginning of last year, it now holds only ~65% market share today.
TVL by Chain — Share of Total
The emergence of other L1s was mostly driven by Ethereum’s scaling issues. And the crux of Ethereum’s low throughput is that every node in the network needs to process every transaction, which maximizes security and decentralization, but at the expense of scalability.
Several popular alternative L1 blockchains have focused on solving blockchain scalability by scaling vertically — increasing the hardware requirements to run nodes. This improves performance but often at the cost of some degree of decentralization. Furthermore, while it creates an initial increase in throughput, future improvements are limited by Moore’s Law (the rate of improvement in computing hardware performance). Ultimately, the network’s performance is bounded by what a single, albeit powerful, computer can do. L1s that fall into this category include Solana, Binance Smart Chain, and ThunderCore.
Another approach is horizontal scaling — adding more hardware to the blockchain network, and having each node in the network perform only a subset of the overall work. This includes blockchains that have a multi-chain design, such as Cosmos, in which different applications create their own blockchain. It also includes sharding, which separates the blockchain into multiple smaller ones, all sharing the same block structure and consensus. This is how L1s like Ethereum, NEAR, and Harmony plan to improve scalability going forward.
Recently, Amber Group participated in NEAR’s latest fundraising to accelerate mass adoption of Web3. In addition to NEAR’s innovative sharding design, we are drawn to the team’s commitment to user and developer experience, the organic community that sprung up over the last few years, and ultimately, the platform’s vision of enabling an open web.
In this report, we outline some of the key innovations and design features of NEAR protocol, its current state and future roadmap, and key projects within the ecosystem that readers may be interested in.
Introduction to NEAR
NEAR protocol is an open-source, proof-of-stake blockchain founded in 2018 aiming to accelerate the transition to an open web world — “a world where people control their assets, data, and power of governance.” It is guided by four general principles: usability, scalability, simplicity, and sustainable decentralization. Below, we highlight some of the most salient features of the network.
Smooth Onboarding Experience for Users
The process of onboarding onto NEAR is significantly simpler than that of Ethereum or other L1 chains. NEAR provides an in-browser, web-based wallet, so users do not have to download (yet another) browser extension for another wallet. Accounts are name-based (i.e. “ambergroup.near”), which reduces the complexity of hexadecimal or similar formats in other L1 networks. In addition, the wallet provides a wide range of security options, from integrating with hardware wallets (most secure) to using an email backup (least secure). Permissions for applications are clearly shown too. Finally, the wallet also easily enables holders to participate in staking.
NEAR’s Native Wallet Provides Smooth User Experience
Overall, these features create a seamless and user-friendly experience for managing assets and navigating apps.
Exceptional Developer Support
NEAR supports smart contracts written in Rust and AssemblyScript (a language similar to JavaScript), although support for the latter is still relatively lacking compared to support for Rust. NEAR nodes run Web Assembly (WASM), which can be compiled from a wide range of programming languages.
“The way that NEAR had done their contracts is quite beautiful. It is incredibly seamless than other blockchains that also do WASM contracts, and that’s speaking from experience.” — Joshua Bouw, Aurora Engine Team Lead
The platform also provides a robust development suite, including an online IDE using Gitpod, integrated unit testing, and a rich library of lessons and programs for developers to get started building on NEAR’s platform.
In addition, NEAR provides rewards to developers who contribute to the ecosystem. A portion of fees generated by a transaction is given back to the contracts that the transaction uses. For example, if Alice interacts with smart contract A with a fee of 0.0001 $NEAR token, that contract will receive a reward of 0.00003 $NEAR (30% of the transaction fee). However, if smart contract A is using smart contract B for 50% of its functionality (as measured by gas usage) both contracts will split the reward. These proceeds can be directed to an account controlled by the developers, investors, a DAO, etc. Thus, developers are economically incentivized to build DeFi primitives that others can leverage.
These features have helped attract developers to NEAR’s platform. Electric Capital’s 2021 Developer Report suggests that NEAR’s developer community grew ~4x throughout 2021 and is one of the fastest growing communities among emerging L1s.
NEAR is One of the Fastest Growing Alternative L1s
One of the Strongest Full-Time Developer Growth Since Launch Amongst Alternative L1s
Continued Developer Momentum in January 2022
Low Transaction Fees, Fast Confirmation Times
Currently, NEAR offers an average block time of ~1 second with transaction fees often below $0.1. This is primarily because the network is still nascent — the network is still using only a fraction of total capacity.
But NEAR aims to offer a similar experience even as millions of users onboard the platform through sharding. In fact, the NEAR team originally aimed for a completely sharded blockchain at mainnet launch, before pivoting to focus on onboarding users first by prioritizing stability, usability, and user experience.
Late last year, the team launched Phase 0 of its fully sharded blockchain that it calls Nightshade. Below, we provide a basic overview of sharding, some challenges in sharded blockchain architectures, and how NEAR’s protocol design addresses these challenges.
An Introduction to Sharding
The core idea in sharding is splitting up one blockchain into multiple ones and calling each one a “shard.” In a simple design, total validators on the blockchain network are also separated evenly to validate each shard. For instance, if we split a non-sharded blockchain with 100 validators into 10 shards, each shard would have 10 validators.
This basic design already presents a couple of initial challenges. First, the security for each shard is 10x lower than the non-sharded blockchain. An attacker would only need to control ~6 validators (5.1% of total nodes) to corrupt a shard, whereas it would have to corrupt ~51 validators in the non-sharded version.
Naively Sharding the Blockchain Significantly Weakens Security
To solve this, virtually all sharding designs use some form of randomness to assign validators to shards. And because generating random numbers, assigning validators to shards, receiving updates from shards, processing stakes, and other coordinating activities all require additional computation, there is often a main “chain” to manage all of these tasks. This chain is known as the Beacon Chain in NEAR and Ethereum, Relay Chain in Polkadot, and Cosmos Hub in Cosmos.
The above design also demonstrates another scaling property of sharded blockchains — quadratic scaling. If every node in the network becomes four times more powerful, then each shard will be able to process four times more transactions. In addition, the Beacon chain will be able to coordinate among four times more shards. Thus, performance improvement of the entire network increases by 16x (4 x 4, hence the name quadratic). A quadratic improvement in hardware results in an exponential improvement for the network.
State Sharding vs. Transaction Sharding
Nodes in a blockchain have three primary responsibilities: 1) processing transactions, 2) relaying completed transactions to other nodes, and 3) storing the history of the entire network. Different blockchain networks define which of these responsibilities are and are not separated when the network is sharded.
One type is transaction sharding. In this design, transactions are processed in separate shards in parallel, without sharding the global state of the blockchain. Transaction sharding is easier to implement because each shard can refer to the global state of the network, including other smart contracts and data. Cross-shard communication is less of an issue. However, as transaction throughput increases, the bottleneck will eventually shift to storage.
Another type is state sharding, dealing with the storage of the blockchain ledger. With this design, the entire state of the network is split across shards, and every node holds only the state of the shard that it is currently in. Transaction processing is not necessarily sharded when dealing with state sharding.
But sharding only one aspect merely shifts the bottleneck around. Furthermore, compute power is currently the more pressing bottleneck. Thus, state sharding generally also involves transaction sharding — it does not make sense to improve a network’s storage capacity without an accompanying improvement in throughput.
Under both state and transaction sharding, each shard is essentially building its own blockchain that contains transactions that affect only the local part of the global state that is assigned to the shard. Nodes need only to deal with responsibilities handling their own shard, such as processing transactions, relaying blocks, and storing data. As such, sharding linearly reduces compute power, storage, and bandwidth requirements, but presents a whole host of new challenges to tackle.
Challenges with Sharding
Cross-Shard Communication. One of the primary challenges in sharded blockchains is providing effective, secure, and user-friendly cross-shard communication. This is often analogized with the “train-and-hotel” problem: Suppose someone wants to buy a train ticket and book a hotel for a trip. That person would like the transaction to be atomic — either both transactions succeed, otherwise neither do. In a single blockchain or shard, this task is trivial. However, if the two requests are sent to different shards, it becomes more complicated.
One approach is to have synchronous cross-shard transactions. Whenever a cross-shard transaction needs to be performed, relevant blocks that contain the state transition all occur at the same time, and nodes on each shard collaborate on performing the transaction. The most well-known design for this model is called Merge Blocks, but implementing this in practice is complex.
The other approach — one adopted by NEAR, Ethereum, Cosmos, Kadena, and others — is asynchronous cross-shard transactions. This approach is easier to implement and coordinate but one major challenge is ensuring atomicity.
Cross-Shard Communication
To illustrate the atomocity issue with the train-and-hotel problem, suppose the train purchase is sent to Shard #1 and hotel reservation is sent to Shard #2, and both shards encounter a fork (as in the figure above). The train ticket purchase successfully executes on block A and is sent to block X’, which completes the hotel reservation.
If chains A-B and V’-X’-Y’-Z’ end up being canonical, the transaction is fully finalized — the desired outcome. If A’-B’-C’-D’ and V-X become canonical, then the transaction is rejected, an acceptable (but frustrating) result. But if A-B and V-X become canonical, then only the train ticket purchase is completed while the hotel reservation is incomplete, resulting in atomicity failure.
State Validity. Attackers may attempt to create invalid blocks, and because no nodes can validate all transactions among all shards, the network needs some way to confirm that no invalid block was created in any shard. Fortunately, we already have methods for scalable state validation: fraud proofs and validity proofs. Fraud proofs trust all written transactions to be valid by default and reward users to constantly hunt for invalid blocks (and punish the producer that created the invalid computation). Validity proofs use cryptographic proofs to verify computation.
Data Availability. In most blockchain protocols, nodes can be separated into two groups: full nodes that sync up an entire block and verify all state transactions, and light nodes that download only block headers and use Merkle proofs for parts transactions that are relevant to them.
If a majority of full nodes collude, they can produce an invalid block, and send its hash to light nodes but not disclose the full content of the block. Then, the blockchain could stall in creating the next node as honest validators cannot retrieve the block produced by malicious validators. Even if users are confident that blocks produced by full nodes are valid (e.g., via validity proofs), if they cannot retrieve all the data, they cannot update the data that they need to verify that any future block is valid.
And fraud proofs cannot be used to solve data availability. A malicious entity could publish a block with missing data and only post the full data if challenged by another party. In this case, an honest challenger would look like it is raising a false alarm.
This problem is particularly salient for sharded blockchains. In sharding, validators for each shard are effectively full nodes for the shard, and other participants in the system are light nodes. Thus, sharded blockchains need a robust mechanism for participants to verify data availability.
NEAR’s Sharding Design
Nightshade
NEAR’s sharding technology — named “Nightshade” — models the network as a single blockchain and shards blocks instead. All the block producers and validators are building a single blockchain, referred to as the main chain. The state of the main chain is split into shards, and each block producer and validator only handles a subset of the state and transactions that affect those parts of the state. These shards are called “chunks” in NEAR’s terminology.
Beacon Chain Sharding Design (e.g., Ethereum Serenity) Vs. Nightshade Sharding Design (NEAR)
To produce blocks, validators stake some amount of tokens. The amount of shards they get assigned depends on the amount of $NEAR staked. Before each epoch, block producers download the state of the shards that they are assigned to, and through the epoch, collect and process transactions relevant to those shards.
To deal with cross-shard communication, a transaction needs to be consecutively executed in each shard separately. The transaction is first processed in a shard, and once the shard is included in the block, it generates a receipt transaction, which is routed to the next shard on which the transaction needs to be executed. This process keeps going until the transaction is completed. Nightshade provides a challenge period, in which outside observers identify invalid blocks, to ensure valid cross-shard transactions.
Nightshade’s design provides atomicity with good user experience. Cross-shard transactions are near-instantaneous — the destination shard does not need to wait until the challenge period is over and can apply the receipt transaction immediately. And because Nightshade’s shard chunks are all published together in the same main chain block, if any chunk was found to be invalid, the main chain simply rolls back. This is in contrast to a typical sharded blockchain design, where one challenge could impact another shard, which impacts another shard, and so on. Although an invalid transaction that rolls back the main chain is inconvenient, it would be a rare event and outweighed by the benefits of fast cross-shard transactions.
Additional Security
Fishermen. To ensure state validity, any node can permissionlessly participate as a “fisherman” that verifies chunks. If a chunk is invalid, fishermen can contest the chunk and provide a fraud proof. If the chunk is indeed fraudulent, the fisherman earns a reward, and the full stake of the validator that proposed the incorrect block gets slashed.
NEAR’s whitepaper also envisions hidden validators — a group of validators randomly assigned to verify chunks — but they are not anticipated to be needed in the foreseeable future as there are sufficient incentives for entities to run fishermen in practice.
Solving the Data Availability Problem
NEAR ensures data availability by using erasure codes, which essentially extend the size of the block of data. NEAR’s design allows a chunk producer to reconstruct the entire chunk from just 16% of other chunk producers. Nodes on other chunks probabilistically check that the majority of the extended data is available, which they can use to ensure that chunks are valid. If erasure-coded data is not provided by one party, then other chunk producers will not attest or build on top of that block which they don’t have parts for.
Decentralized Scalability with Resharding and Dynamic Sharding
NEAR prioritizes the balance of network resources across shards and does not treat shards differently. But the growth of some shards may naturally outpace that of other shards. Hence, NEAR plans to periodically rebalancing shards by moving contracts across shards based on their usage — a process termed resharding.
NEAR’s long-term vision for decentralized scalability (i.e., high throughput, low latency, and low transaction fees without forcing every node to store terabytes of data or forcing every validator to be a supercomputer) is dynamic sharding. Dynamic sharding involves splitting the network into more shards as usage grows and fewer shards as activity contracts. The architecture has yet to be proven, but if executed correctly, it would allow NEAR to be virtually infinitely scalable with robust censorship resistance.
Tokenomics
NEAR’s genesis block was created on July 21, 2020 with a total supply of 1 billion $NEAR. $NEAR tokens are used similarly to $ETH: 1) to provide security of the NEAR network through staking, 2) to pay for transaction and storage fees, and 3) as a medium of exchange between applications and accounts. $NEAR has a fixed inflation rate of 5% of the total supply. With current token burns, this brings net inflation down to ~3–4%.
Staking
NEAR’s validation is permissionless and determined based on the amount staked by validators. The network is progressively decentralizing. After a change in the validator selection algorithm in November 2021, the threshold for becoming a validator was reduced from 3.6 million NEAR to roughly 61,000 NEAR. Consequently, the number of validators grew from 60 to 100 in just two months.
90% of NEAR’s inflation goes to validators proportional to their participation. At the current network participation rate (~36%), the total APY for staking is roughly 12.7%.
If users do not want to run their own nodes, they can still provide security to the network by delegating their $NEAR tokens to validators.
In addition, NEAR offers smart contract based delegation instead of protocol-level delegation seen in most other PoS blockchains. This means that NEAR can enable unique proof-of-stake mechanisms. For instance, NEAR recently announced a unique staking mechanism that allows delegators to provide rewards in other projects’ tokens. In the future, validators can create staking contracts with additional features and modifications.
Transaction and Storage Fees
NEAR has two types of fees on its network: transaction fees and storage fees.
Transaction fees are charged based on the bandwidth and computation required for the transaction, as well as the gas price. The gas price changes based on gas usage for the prior block. If the prior block used more than half of the gas limit, the gas price is increased by a small margin.
As mentioned above, 30% of transaction fees go to the contract rewards and the remainder gets burned. As such, like Ethereum, it is possible for $NEAR to be a deflationary asset with enough network usage. Assuming that all transactions cost the minimum transaction fee of 0.0001 $NEAR, $NEAR becomes deflationary at around 1.5 billion transactions a day.
Annual Inflation Rate Given Different Activity Levels
Different from most other L1 blockchains, NEAR also charges collateral for storage. An account or contract’s $NEAR balance determines the amount of its storage capacity. This design aims to address the long-term cost that storage imposes on the network, as future validators will need to continue storing prior data to maintain the ledger. By requiring $NEAR to be locked up, validators get an indirect form of compensation by taking tokens out of circulation.
Treasury
The remaining 10% of NEAR’s inflation is provided to NEAR’s Protocol Treasury, used to fund protocol and ecosystem development. The Treasury is currently in the custody of the NEAR Foundation as the platform continues to bootstrap its network. But the long-term plan is for the Treasury to be managed by a decentralized governance process.
Team and Foundation
NEAR was founded by Alex Skidahov, the first engineer at distributed database system MemSQL, and Illia Polosukhin, a former Googler and Tensorflow contributor. The team includes several ex-MemSQL and ex-Googlers with experience building distributed and sharded systems. The NEAR Foundation also recently announced a new CEO, Marieke Flament, to spearhead growth and accelerate NEAR’s growing adoption in Web3.
The Foundation is active in bootstrapping the network. In October 2021, NEAR Foundation announced funding initiatives of over $800 million to expand NEAR’s ecosystem. This includes a $350+ million fund to invest in DeFi applications on NEAR and Aurora, $250 million of grants and incentives, and over $200 million to regional and startup funding.
[Note: Funding was allocated in $NEAR tokens, so the total amount of funds are reflexive in that successful ecosystem development should (ideally) push $NEAR’s price higher, which provides more dry powder for the funds to further develop the ecosystem.]
State of the Ecosystem
Due to the protocol’s emphasis on usability, exceptional user experience, and ecosystem funding support, the community has grown significantly since mainnet launch.
Overview of NEAR’s Ecosystem
But frankly, given that the network went live only in 2020, the ecosystem is still immature compared to other L1s. For instance, while there are some DeFi primitives such as Ref Finance’s DEX and Meta Pool’s liquid staking token, NEAR’s native L1 network still lacks borrow/lending protocols and more complex DeFi primitives. That is expected to change with several projects slated to launch soon; we expect users will find significantly more options and use cases this year. Furthermore, the development of Aurora, an Ethereum Virtual Machine implemented as a smart contract on NEAR, has helped spur activity on NEAR’s network (we dive deeper into Aurora and other projects in a later section).
TVL for NEAR and Aurora
Several metrics from NEAR’s block explorer confirm growing adoption. Daily number of transactions has grown steadily to a range of roughly 400k to 600k daily transactions, and a peak of ~1.8 million transactions, in January 2022.
NEAR Daily Number of Transactions
Wallet usage is growing steadily on NEAR’s native L1 as well. However, WAU and DAU growth are relatively weaker compared to MAU growth, suggesting that a greater proportion of users are not interacting with NEAR applications on a frequent basis.
NEAR Wallet Usage by Month, Weekly, and Daily Active Users
New account creation also spiked recently, reaching a daily peak of ~570k on January 16. This is likely due to both various growth initiatives by several teams and NEAR co-founder Illia Polosukhin’s suggestion that NEAR accounts could be turned into NFTs and resold on secondary markets.
Daily Number of New Accounts Spiked in January
NEAR Accounts Could be Resold on Secondary Marketplaces such as Near Bet and NEAR Names
Future Roadmap
The main focus for NEAR’s roadmap is the realization of Nightshade as described in its 2019 whitepaper. Sharding will be implemented in phases. Last November, NEAR launched “Simple Nightshade” (Phase 0) in which it transitioned from a non-sharded blockchain to a sharded one. Currently, only the state is sharded into four shards; processing is not sharded yet to guarantee the security of the network.
Later this year, Phase 1 will start, introducing chunks-only producers that validate one shard. This is expected to grow the number of validator slots to 400+ and will continue scaling with the number of shards.
Simple Nightshade is expected to be fully implemented with the implementation of challenges (for state validity and cross-shard transactions) in Phase 2. Both state and shard will be fully sharded, and validators will not need to track all the shards. Protocol development roadmap suggests that Simple Nightshade with 8 shards will be completed by Q3 2022, with Aurora in its own shard.
Finally, full Nightshade with dynamic sharding is expected to be delivered in Q4 2022.
Aside from sharding, the NEAR team also plans to deliver other improvements and changes, including:
Single-shard performance optimizations of storage and WASM with significant gas cost reductions
Introducing zero-knowledge (ZK) light clients and more ZK across the protocol
Possibly redesigning how transaction fees are charged by introducing gas price auctions to better deal with network congestion
Active research into multi-shard synchronous execution (see: synchronous vs. asynchronous cross-shard communication above) to improve composability for DeFi applications
Select Project Highlights
Aurora
Aurora, a NEAR spin-off, creates a 1:1 EVM implementation on NEAR. This means that developers on Ethereum can essentially copy and paste their Solidity code onto Aurora, taking advantage of NEAR’s low transaction fees, fast finality, and eventually, horizontal scaling. MetaMask, Truffle, and Hardhat are all available on Aurora. Etherscan, member of AuroraDAO, is also working on an integration. Gas on Aurora is paid in $ETH to fully replicate the Ethereum experience, although for now, the Aurora team is subsidizing transaction fees on the network (read: gasless transactions).
The Aurora Architecture
Source: Aurora
But even though the community tends to brand Aurora as an “Ethereum Layer 2,” it does not inherit its security from the Ethereum network. Instead, Aurora runs as a smart contract on top of NEAR and leverages NEAR’s validators. Hence, Aurora is more comparable to Ethereum-compatible environments on other L1s, such as Avalanche’s C-Chain and Polkadot’s Moonbeam.
The Aurora team also built and currently maintains the Rainbow Bridge, a fully trustless bridge for transferring tokens between Ethereum, NEAR, and Aurora. Other bridge options, including Allbridge, Multichain, and Synapse, exist. But Rainbow provides the lowest possible trust level and a sleek user experience, lowering the barrier to moving funds from Ethereum or NEAR. The Rainbow Bridge currently ranks #6 among Ethereum TVL bridges with nearly $1billion in TVL. The team is working on enabling NFT transfers and connecting with BSC, Polygon, and Cosmos.
Total Assets Bridge Through Rainbow Bridge
Aurora has catalyzed a step-change in adoption for the NEAR platform. Well-known DeFi primitives, including Curve and 1inch, as well as modified forks of existing projects, such as Aurigami (Compound) and Vaporwave Finance (Beefy Finance), have all been launched or are expected to launch within the next few months.
Aurora Ecosystem Map
Source: @aurories__
Aurora is also the first project to use NEAR’s “stake farming” mechanism. $NEAR rewards earned by Aurora’s validator will go towards maintaining the Rainbow Bridge and subsidizing transactions on the Aurora network. Simultaneously, delegators receive $AURORA tokens and earn double-digit APYs (depending on the amount of $NEAR staked with Aurora’s validator and the $AURORA price).
In sum, the Aurora network is the closest replication to Ethereum’s consensus layer (colloquially “ETH 2.0”) — with low gas prices (paid in $ETH), faster confirmation, more capacity, same toolset, and same EVM.
Octopus
Octopus has a similar multichain vision as Polkadot and Cosmos. It aims to build an infrastructure layer to enable application-specific blockchains (called “appchains”) built on Substrate. An Octopus appchain is a blockchain with independent consensus, but it entrusts PoS security to the Octopus Network using Octopus tokens ($OCT) as the staking asset. And unlike Cosmos or Polkadot, Octopus’ cross-chain hub that coordinates activity among its appchains is not an L1 blockchain but rather a set of NEAR smart contracts.
Octopus also operates an incubator model, in which it periodically helps the appchain with the most community support to help raise funds through an Initial DAO Offering (IDO) on a community launchpad and airdrop $OCT tokens to IDO investors.
Octopus’ Relationship with the NEAR Protocol
Octopus launched in October 2021 and has only a handful of appchains. One intriguing appchain to look out for is Fusotao, a verification protocol for order-book based matching engines that powers other DEXes.
Other Projects
NEAR — Projects on Near’s native L1 include:
Fixed Income: Burrow — Incubated by Proximity Labs, a DeFi research firm focused on the NEAR ecosystem, Burrow is an interest rate protocol that allows users to borrow and lend interest-bearing assets, including liquid staking tokens such as staked NEAR ($stNEAR) and staked ETH ($stETH). It borrows Alchemix’s framework of “self-repaying loans” by using the interest paid from deposited collateral to gradually pay down debt. Burrow is currently in testnet and is anticipated to launch soon.
Order-Book DEX: Orderly — Formed in collaboration with Woo Network, Orderly is an on-chain orderbook DEX that aims to provide spot trading, margin trading, perpetual swaps, and lending & borrowing. The open beta is slated to launch by Q2 and full public release by Q3 2022.
Creator Economy: Capsule Social — Capsule Social is a Web3 publishing platform that empowers writers, leveraging IPFS, OrbitDB, and the NEAR protocol to enable censorship-resistant content.
Aurora — On Aurora, where users can leverage existing Ethereum infrastructure such as a MetaMask wallet, notable projects include:
DEX: Trisolaris — A Sushi fork, Trisolaris is an AMM currently providing liquidity incentives in both $TRI tokens and select project tokens (such as $AURORA, $atLUNA, and $FLX). The protocol’s native $TRI tokens can be staked for $xTRI, which earns 0.05% fee on every trade on the DEX. The team is also exploring a vote-escrow structure, similar to Curve’s, and the addition of stablecoin swaps.
Money Market: Aurigami — Aurigami is a Compound fork with unique token mechanics, in which issued tokens are progressively unlocked over 54 weeks. The earlier users claim their tokens, the more tokens are locked for vesting. This disincentives mercenary capital, preventing the typical “farm and dump” game, and aligns users with Aurigami’s long-term success. Although Aurigami will initially start as a fork, the team is planning to branch out by incorporating yield hedging and rate swapping features in the future.
Yield Optimizer: Vaporwave Finance — Vaporwave Finance is a Beefy Finance fork audited by Paladin Finance. It offers users a platform to optimize yield by auto-compounding rewards from other Aurora farms. The platform will launch $VWAVE tokens on NearPad, an Aurora launchpad, soon. Staked $VWAVE earns a portion of $WETH revenues earned by the platform.
Creator Economy: Endemic — Endemic is an NFT platform that connects real-world artists to the NFT space. The team has curated 50 artists so far and aims to expand to collectibles and merchandise after its full mainnet launch. They also plan on launching on NEAR and Polygon.
Additional Resources
Awesome NEAR: Curated list of all projects building on NEAR’s platform
The Aurora Community: List of all projects in the Aurora ecosystem
NEAR Community Forum, which includes weekly community and engineering updates
Disclaimer
The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.