---
title: 2.3 NEAR Protocol
description: Introduction to NEAR Protocol and its features
---

# 2.3 NEAR Protocol

NEAR Protocol is a community operated L1 using Proof of Stake (POS) launched on mainnet in 2020, and it has been called the ‘San Francisco’ of Blockchain’s by the well known Haseeb Qureshi of DragonFly Capital. 

| | ETH 1.0 | NEAR |
| --- | --- | --- |
| Block Time | 15s | 1s |
| Tx Finality | 3 min | 2-3s |
| TPS | 15 | Up to 100k |
| Avg Tx Fee | ~$21 | < $0.01 |
| Languages | Solidity | Rust, Assembly Script |
| Number of Validators | 6.8k | 60 |



While we will cover the specific design mechanics of NEAR and why it is well positioned to succeed in the future, we are going to be specifically drilling down on two key features of NEAR that make it a standout protocol: Asynchronous Sharding, and Usability. The first is quite technical, but relates closely to the discussion we had recently on Ethereum and its future. The second is novel, and has a precedent in economic history as a key component of making innovation widespread among consumers. 

Before this a little history - what is NEAR and why are we even talking about it? 

## History and Launch

NEAR is the product of two Web2 engineers, realizing that their AI startup needed to pivot into blockchain - and that blockchain itself was a nascent and undeveloped technology ripe for disruption. In 2018 NEAR morphed into a silicon valley incubated L1, which took a fresh look at the design choices of L1 ecosystems to date. 

What co-founders Illia Polosohukin and Alex Skidanov did differently, was they looked at the design of blockchains to date with fresh eyes, and tried to bring scaling solutions from Web2 into Web3, as a way of building a more scalable and durable blockchain in the future - this innovation is known as asynchronous sharding. 

The second thing they did, was try to understand what needed to be improved in crypto, in order for mainstream adoption to take place - that is to say, how to move from highly technical and clunky infrastructure to smooth, user-friendly experiences, such that devs could build dApps easier and even a boomer could participate in the Web3 economy. This feature is known as usability - and it remains the single most important competitive advantage that NEAR holds over any other L1. 

NEAR launched in August of 2020, with a total token supply of 1 billion tokens, and a 5% annual inflation rate split between 4.5% rewards for validators, and 0.5% for an ecosystem treasury. 

## Special Features

### _Feature 1: Nightshade:_

_“In Nightshade we model the system as a single blockchain, in which each block logically contains all the transactions for all the shards, and changes the whole state of all the shards. Physically however, no participant downloads the full state or the full logical block. Instead, each participant of the network only maintains the state that corresponds to the shards that they validate transactions for, and the list of all the transactions in the block is split into physical chunks, one chunk per shard. (21)”_

NEAR Protocol handles transaction loads via both synchronous and asynchronous sharding on its network. The nightshade consensus mechanism is designed to scale a single blockchain known as the _Mainchain_ through consecutively adding shards in proportion to increased transaction loads. This model - known as dynamic sharding - is _one_ approach proposed to creating a robust and scalable blockchain infrastructure, that is capable of handling a high throughput of transactions at a low cost (less than 1 cent per transaction). 

While the NEAR development team at Pagoda remains in their infancy in rolling out dynamic sharding, there are a number of benefits from such a scalability design: 


* **Composability in Security, Contract, and Validation Design:** This means that unlike multiple rollups, or side-chains, Parachains, or Cosmos chains, NEAR is one uniform platform abiding by the same economic, security, and programming logic. This means that while different shards may handle different transactions asynchronously, the user experience is composable, as is the way value is able to flow between dApps and services. 

_“In a sharded blockchain, however, all the shard chains are the same, while in the global blockchains ecosystem there are lots of different blockchains, with different target use-cases, decentralization and privacy guarantees. (7)”_


* **Inter-Shard Communication:** At scale, NEAR will be comprised of multiple shards, that not only run the same security and economic logic, but which are also able to communicate with one another such that users’ can communicate across shards, without worrying about manually using bridges and other infrastructure usually characteristic of rollups and sidechains (i.e. Polygon Multisig). 

_“If a transaction needs to affect more than one shard, it needs to be consecutively executed in each shard separately. The full transaction is sent to the first shard affected, and once the transaction is included in the chunk for such shard, and is applied after the chunk is included in a block, it generates a so called receipt transaction, that is routed to the next shard in which the transaction need to be executed. If more steps are required, the execution of the receipt transaction generates a new receipt transaction and so on. (26)”_

### _Feature 2: Usability:_

NEAR’s focused on usability is built around the _Account Model, _which essentially inverts how access keys have been managed to date: Prior to NEAR, access keys on Ethereum for example, were designed around a public address, 



* **_Account Model:_** NEAR puts usability first. This is manifested in a number of ways, but the most notable pertain to[ the account model structure as well as built-in advanced permissions](https://nearguilds.com/2020/09/29/hack-the-rainbow-session-7-near-accounts-and-key-registration/) that allow users to call contracts directly. Unlike other blockchain protocols, accounts on NEAR are denominated in names as opposed to hashes of alphanumeric characters. Sub-accounts can be created by master accounts, while standard Single Sign-On login options make handling an account more natural to existing Web2 users.


![](@site/static/img/bootcamp/mod-em-2.3.1.png)




* **_Access Keys:_** NEAR is designed with two types of access keys: Full-Access Keys, and Function-Call Limited Access Keys. [Function-Call Limited Permissions](https://docs.near.org/concepts/basics/accounts/access-keys) allow developers to call contracts on sub-accounts, such that gas can be automatically pre-paid from dApps ahead of time. 

The following overview is the extent of what a ‘full access’ key is able to manage on Accounts: 


![](@site/static/img/bootcamp/mod-em-2.3.2.png)


Meanwhile, function-call limited access keys, allow for the following: 


![](@site/static/img/bootcamp/mod-em-2.3.3.png)


Note that the logic behind such keys is to ease the process by which an account is able to interact with a dApp, without manually asking the user over and over again. This is a key user-benefit that can be leveraged to pre-pay gas costs in games, simplify purchasing of assets, and streamline user-experience such that they do not have to worry about maneuvering around the protocol itself. 

With the ‘account’ and ‘access key’ design of NEAR, a number of innovative products can be created to even further facilitate user engagement with the protocol in a manner that abstracts away the complexity and makes it a seamless user experience. Two such products include: 

  * **_Keypom:_** Keypom is short for ‘programmable keys’. It aspires to be an onboarding toolkit for builders and dApp creators such that they are able to customize user permissions to allow users to participate in a product without necessarily having an account or having to worry about gas costs for the account. 

Examples [provided by Illia included](https://twitter.com/ilblackdragon/status/1595136580137947136?s=20&t=JXEkNQLZqr5aADZH_nrX7g):

_“Example 1: send an on-chain ticket to a user via email. They can check into the event and later convert their keypom into a POAP that simultaneously creates an account.”_

_“Example 2: Send an invite link to join your DAO with a keypom, your friend joins up and submits their first proposal before having to create an account.”_



* **_Spaceport:_** Spaceport is a custodial platform and on-ramp for users. The key value proposition behind spaceport is key management on NEAR such that users can interact with the NEAR Ecosystem without needing to worry about their keys - but at the same time - retain the ability to undock an account from spaceport, such that they can manage keys themselves once more. Spaceport aspires to provide the necessary safeguards and on-ramps into the NEAR ecosystem in order for users to easily access the value proposition of Web3 without needing to worry about being responsible for their keys. 
* **Low Transaction Fees / No Overpaying:** Transaction fees on NEAR are priced in a predictable manner, that does not inflate with increased usage. The protocol has also been designed such that it is not possible to overpay a gas fee: anything paid beyond the required amount is returned to the account of the payer. Such a model for transaction fees makes NEAR optimal for usage and attractive to developers. This is especially the case for the nascent yet fast growing NFT market as well as other core Web3 verticals including gaming and DeFi. 
* **Developers Take 30% From Their Contracts:** The NEAR website explains [this feature most clearly:](https://pages.near.org/developers/) “Contracts are rewarded with 30% of the gas fees they generate, giving developers an immediate business model for apps and infrastructure.” This is a unique feature from all other existing layer 1 protocols: Developers, Entrepreneurs, and new projects that migrate to NEAR have a direct incentive to build on the protocol - built into the core design - due to the fact that they will be rewarded 30% of the fees that cross their contracts. 
* **Program in Rust and AssemblyScript:** Making it easy to build blockchain-dApps is a key emphasis of NEAR Protocol. Developers from Web2 can quickly and easily code in Rust or AssemblyScript as opposed to a separate blockchain-specific language such as Solidity. In context of the macro transition discussed above, this is another key factor that makes NEAR _usable_ for developers looking to easily transition from Web2 to Web3. [The JavaScript SDK has also been released ](https://near.org/blog/near-releases-javascript-sdk-bringing-web3-to-20-million-developers/)expanding access to building dApps on NEAR to the millions of Javascript developers. 

### _Feature 3: Doomslug_ 
Refers to NEAR’s block production mechanism. Alex Skidanov[ has outlined how it works](https://near.org/blog/doomslug-comparison/) specifically in reference to Tendermint and HotStuff. While this is technical, and not easily understood, what is important to understand is that the DoomSlug Algorithm sets the conditions and parameters for block production, slashing, and consensus on NEAR. 

_“A construction that allows a set of block producers in a blockchain protocol to create blocks with a single round of communication per block such that each block is irreversible unless at least one block producer gets their stake slashed. (1)”_

## Pillars of the NEAR Ecosystem

For full and clear visibility into ‘what’ NEAR consists of today, it is relevant to dive slightly into the different Pillars of the NEAR Ecosystem. These Pillars include:

_Aurora –_ An EVM based shard, running on NEAR but with the user-experience and compatibility of ETH to the extent that it could be considered a ‘roll-up’ on ETH in its own right. 

_Octopus –_ An App-Chain factory on NEAR native, allowing for hundreds of appchains to source shared security from Octopus validators. 

_Rainbow Bridge –_ A fully decentralized NEAR - ETH Bridge from which tokens between platforms can be independently moved by developers, users, and projects. This bridge is significant insofar as it: 1) Provides a pathway for projects (NFT’s, DeFi, etc.) to migrate value from Ethereum onto NEAR in the event of unreasonable gas fees on the former and 2) Pioneers one of the industry’s first fully decentralized bridges from which interoperability between platforms can be established and scaled into the future. 

_Calimero -_ The enterprise shard on NEAR, with data safeguards and private shard infrastructure. 

_Open Forest Protocol -_ A fully on-chain carbon economy for nature based solutions. 

## The Roadmap for NEAR Into The Future

If we take Hasseeb’s analogy seriously about NEAR operating as the ‘San Francisco’ of blockchain cities, then like San Francisco, NEAR has a very bright future predominantly led by tech. Innovation in Web3. 

The following picture is a roadmap released by Pagoda, and focused on core protocol upgrades in the coming years: 


![](@site/static/img/bootcamp/mod-em-2.3.4.png)


#### Beyond Meta-Transactions (discussed above) other notable points include:



* **_MetaTransactions:_** MetaTransactions seek to improve user-experience by covering transaction costs for interacting with dApps on NEAR. In short, a Web2 experience for Web3 products. 

_“Meta transactions allow a third party to pay for the transaction cost of any account, which means that users can be onboarded to NEAR apps without having to get NEAR tokens first.”_



* **Global Storage:** Work-arounds for builders to not have to pay storage staking costs for data in their contracts / for the deployment of certain contracts. 

_“In the current paradigm, if a commonly used smart contract is deployed many times, the same amount of storage staking cost has to be paid every time it is deployed. As an example, every account that deploys a multisig contract today has to pay ~3N for storage cost even though the contract is exactly the same across all those accounts and isn’t consuming more physical storage on the implementation level. Global storage addresses the problem by allowing builders to burn tokens to deploy a contract once and then every account can use it without having to pay for the storage staking cost.”_



* **Zero-Balance Accounts:** Avoids ‘top-up’ needs from new accounts, such that dApps and builders can onboard users easier. 
* **WASM in WASM:** Synchronous contract interaction on NEAR Native by allowing “dynamically loading and executing another smart contract within the execution of a smart contract.” 
* **NEAR Social / NEAR Operating System:** Building out the social infrastructure around dApps on NEAR, such that messaging, user account interface, one-click integration with dApps, and easy spin-up tooling for builders can be leveraged to ease the onboarding process for both users and founders. 
* **High Level Naming Auction:** Currently, the majority of high level names (ozy.usa, ozy.lyrik, ozy.america) have not been auctioned and are owned / managed by Pagoda. At some point in the medium future it is likely that a high level name’s auction will take place on NEAR similar to the launch of Google Domains. 

## Why NEAR?

The thesis of Why NEAR centers on usability and scalability: Summarizing from above - NEAR’s future claim to market share in Crypto is based on these two facets. (1) That NEAR will be able to scale, to an extent that it can sustain a high constant throughput of transactions, and (2) That NEAR will be able to onboard new users to Web3 in a way that hides seed phrases, transaction fees, and constant permissioning with dApps. Together, NEAR is positioned over the next 10 years to grow in the emergent Web3 market similar to how ‘San Francisco’ has succeeded in the United States over time.