Bison Trails Supports NEAR

Our comprehensive guide to NEAR includes details of NEAR's innovations, its focus on developers and usability, and what you need to know about how the protocol works.

Bison Trails Supports NEAR

Jun 8 2020 By Bison Trails


  • Bison Trails has been working with the NEAR team since March 2019. As active participants in their first incentivized testnet (Stake Wars), we provided feedback and recommendations for improvements to the network.
  • NEAR’s developer-friendly approach is focused on usability and the creation of familiar web experiences powered by a sharded Proof-of-Stake blockchain
  • Fees are thoughtfully designed: a percentage of smart contract usage is automatically allocated to developers, senders only pay for gas they use, and developers can prepay gas for first-time users
  • Each epoch on NEAR has its own active set requirement. The active set is made up of a number of available seats, currently 100. Validators with large stakes can occupy more than one seat in the active set.
  • Users maintain a fraction of the NEAR token, Ⓝ, (the right to store data) as an existential balance to participate in the network. Contracts lockup Ⓝ proportionally to the amount of data they are securing, which will impact dApps and large smart contracts.
  • NEAR allocates 30% of transaction fees to the contracts these transactions touched. Popular libraries can receive funds from all client applications that are using them.
  • NEAR is planning to transition from Proof-of-Authority to Restricted Mainnet sometime in Summer, 2020. There is no inflation during the Restricted stage, but NEAR will award stipends to those who participate by running nodes.
  • To start, only validators can participate in NEAR governance. But NEAR’s governance is built on smart contracts, so it can be augmented in the future. Token holders inherit the vote of the validator to which they are delegating. In order to move from the Restricted Mainnet stage to full Mainnet, validators must vote to make the switch, so token holders have good reason to also run validators.
  • Contract-Based Delegation: On NEAR, staking is done at the protocol level but delegation to validators is done via smart contracts deployed to the platform, providing flexibility to offer advanced financial products related to staking.

    A Guide to NEAR by Bison Trails • Navigate to a Section:

  1. Goal of NEAR
  2. Innovations on NEAR
  3. How NEAR Works
  4. Why Run a Node
  5. Why Bison Trails

The Goal of NEAR

NEAR, a sharded Proof-of-Stake blockchain with a focus on being developer- and user-friendly, is a smart contract platform. "Sharding allows the work of validating transactions to be broken up amongst many ‘shards’, each of which is validated by different nodes." ( Often compared to Ethereum because of a shared vision for the future of smart contract platforms and a utilization of sharding, there are key differences that distinguish NEAR.

Despite the complex technology underlying the network, NEAR intends to be accessible to a wide audience by emphasizing intuitive user experiences and focusing on scalability. As a decentralized community-run cloud computing and storage platform, NEAR is designed to foster the growth of the open web of the future.

NEAR is Focused on Usability

NEAR’s “progressive security” provides developers the flexibility to specify exactly what permissions are granted to another user or contract. This means developers can create apps that don’t require users to have advanced knowledge, a model that fosters the creation of experiences similar to those familiar to most people from the web:

  • Simple Onboarding: Developers on NEAR can execute some actions for their users; applications can onboard users without requiring a wallet or the need to interact with tokens immediately. “Single Sign On” (SSO) functionality is also possible (e.g. “Login with Facebook/Google/Github/etc”) given that accounts (public/private key pairs) keep track of application-specific keys.
  • Easy Subscriptions: Subscriptions and custom permissioning are easy to create on NEAR’s contract-based accounts.
  • Familiar Usage Styles: Developers can hide the costs of infrastructure from users by paying for their usage, similar to many web paradigms.
  • Predictable Pricing: Transactions on the protocol are priced simply and predictably in order to avoid the hassle of unpredictable transaction fees.

NEAR’s Developer-Friendly Approach

A number of usability improvements support developers of the platform:

  • Familiar Languages: NEAR nodes run Web Assembly (WASM) virtual machine, a standard developed by W3C, Mozilla, Microsoft, Google and Apple that runs inside all modern browsers. Ethereum’s virtual machine (EVM), by contrast, is nascent to Ethereum developers. At first, NEAR smart contracts can be built using Rust. Contracts can also be written in AssemblyScript, a language similar to TypeScript, a widely used modification of JavaScript developed by Microsoft. Eventually, in order for more developers to be able to participate on the network, other common programming languages will be supported.
  • Robust Tooling: NEAR created its development suite to offer developers an experience similar to one they would find when developing traditional web apps. This unified set of tools, and the available APIs, include one-click deploy, integrated unit testing, easy front-end integration, zero-cost onboarding, and debugging from the web browser’s developer console.
  • Developer Business Models: Developers can monetize the open components they create for the ecosystem through natively rewards with rebates based on the usage of their components.

Innovations on NEAR

NEAR is innovating on a number of fronts.


A minimum percentage of Smart Contract usage fees as developer rewards: When a contract is called, a portion of the transaction fees generated by the network are automatically allocated to the contract; the contract’s developer can decide how funds are allocated (to themselves, to the community via the token accruing value, etc.). This “reward'' effectively incentivizes early application development that increases network use.

In NEAR, the percentage of fees allocated to this reward is set to a minimum value as a system-level parameter. Developers may choose any value equal to or above this minimum value. By design, the NEAR protocol protects developers from a “race to the bottom” zero rewards competition.

Balancing inflation vs transaction fees for long-term sustainability: Many blockchains aim to maintain validator participation through transaction fees alone, rather than continuing to incentivize validators with rewards. NEAR’s model strives to achieve this by keeping inflation constant while transaction fees get burnt; if there are enough transaction fees, the network’s real rate of inflation is actually lower and can even be negative! The more transactions on NEAR, the scarcer NEAR tokens become.This is a benefit for everyone holding NEAR tokens, with a different impact on stock-to-flow ratio compared to other similar currencies.

Senders only pay for the gas they use: On NEAR, a sender specifies a max limit of how much gas can be spent to execute that transaction. When the transaction reaches the network and begins processing, it automatically buys enough gas to finish processing at the current gas prices. Once the transaction is processed, the sender’s account is only "charged" for the gas used. Any leftover gas is converted back to NEAR tokens. This process prevents accidentally inputting a significantly higher gas amount than necessary to complete a transaction.

Developers can prepay gas for first-time users: On other networks, users typically need a small amount of tokens in their account set aside to interact with the network. On NEAR, developers can design applications so that first-time users draw funds for purchasing gas directly from an account maintained by the developer. Later, users can transition to pay for their platform usage. This design decision addresses a friction point in the UX that could otherwise hinder the protocol’s ease of use.

Contract-based delegation: On NEAR, staking is done at the protocol level but delegation to validators is done via smart contracts deployed to the platform. This gives validators significantly more flexibility to offer advanced financial products related to staking which specifically target the needs of their audiences. For example, a validator can offer better rewards based on amounts staked, duration of commitment, or even loyalty over time. This also enables automated delegation via smart contracts, which can dynamically provide users with the best available return via lending, staking or any other financial instrument, opening up a wide range of new DeFi use cases.

User Experience:

Human-readable account ID’s: NEAR’s human-readable account names replace a hash of a public key. Account names are similar to domain names. A top level account (TLA) without separators can be created by anyone, for example near. Only near can create jane.near. And only jane.near can create app.jane.near and so on. near can not create app.jane.near directly. TLAs will be auctioned off, with a fair process, and all proceeds burned.

Function-call limited permission allows non-monetary transactions from non-owners: Access Keys grant permission to act on behalf of an account. NEAR currently has two types of permissions: full-permission and function-call limited permission. The latter type is a key usability feature of NEAR. This type of permission allows non-monetary function-call transactions to be sent from an owner's account to a receiver with the receiver ID restricted by the access key.

Allowing this interaction enables several critical use-cases:

  • Front-end web applications can be authorized without trusting the contract code or the web app itself. A new access key is created on a user’s account through a web wallet and pointed towards the web-app contract. Because the specified access is extremely limited, it is difficult for the web applications to act maliciously.
  • A new user without an account can use a dApp and/or a contract on-chain. A new access key is made for the user on the contract's account and pointed towards the contract itself; the user does not need a wallet to immediately use the web app. A specific example of this, is the ability to send money and assets to new users who don’t have yet a NEAR account, by giving them a private key from the access key added to a contract holding the assets.
  • A secondary account can be provided with specific parameters by a user account so that they can be a proxy for the main account. This secondary account can be given permissions for whatever functionality the owner wants.

Independent Verifiability:

Token Balance-Based Storage - Storage poses a problem for many blockchains. It is important to store all transaction data forever to ensure individual entities can verify the truth of the whole chain. However, as the chain gets larger, syncing takes longer and it becomes increasingly expensive for new nodes to join the network. Token balance-based storage on NEAR means that the more data you want to store, the more tokens you need to have on your account. The user is not paying for storage per-se, but is essentially putting up a bond to continue having that data on-chain. The intent is to align incentives between users and validators.


Dynamic re-sharding* - Sharding is the partitioning of a large database into smaller components, or shards; shards parallelize computation and distribute storage. Shards aim to increase speed on the blockchain, allowing more transactions per second and the ability to dramatically scale up a network.

NEAR intends to use dynamic re-sharding on-chain, which means the number of shards changes in response to usage demands, scaling up and down. Dynamic re-sharding allows the network to only pay for infrastructure and scale it needs, rather than overpaying for unneeded throughput or underpaying and running into bottlenecks. Developers don’t need to think of shards or deploy their app to a specific shard. In the future, the protocol will continuously reevaluate usage and storage and move smart contracts between shards accordingly. NEAR will automatically load balance smart contracts, maintaining that no shard is more heavily trafficked.

* This feature will not be live at launch.

“We are excited to support the NEAR team as they launch the protocol. I've been following the team at NEAR for some time now and am blown away by their focus on the developer experience. NEAR's incredible technical team understands building a strong developer ecosystem will help drive success.” —Joe Lallouz, CEO of Bison Trails

How NEAR Works

NEAR is a sharded Proof-of-Stake (PoS) blockchain, but only one shard will exist at launch. That number can increase through hard forks of the protocol. Initially, validators will be rewarded for their participation on the chain in proportion to their stake. As the number of shards increases, validators with large stakes will need to validate multiple shards in parallel, which would require them to have more powerful hardware or split their stake between multiple machines. Long term, the number of shards will be dynamic.

In order to elect validators, the protocol issues an auction for each epoch (approximately every 12 hours). New validators are elected if they bid a higher stake per seat than existing active validators; funds from accounts that don’t provide a sufficient amount of stake will be returned at the end of the next epoch.

Consensus and Block Production

Each epoch on NEAR has its own active set requirement. The active set is made up of a number of available seats, currently 100. The seats do not have a one-to-one correlation with the number of validators in the set. Validators with large stakes can occupy more than one seat in the active set.

A seat price is determined to elect validators to the active set. This price is calculated by dividing the total stake by the number of available seats. A validator cannot join the active set if it’s stake is less than the seat price, even if there are “open” seats available (e.g. there are 100 seats, but only 50 validators take all 100). Those validators then become a “fisherman,” an observation node that detects and reports bad behavior.

Validators in the active set are responsible for validating blocks and are assigned to produce blocks on a fixed schedule. The validator responsible for producing a block at height h is called block proposer at h. If the validator fails to produce a block when it is their turn, the protocol stalls briefly until the next block producer’s turn. A single missed block does not result in a penalty.

At launch, all active validators will be on a single shard; eventually they will be randomly assigned to shards. Validators on a particular shard are considered “chunk” producers in addition to block producers. A “chunk” is a group of transactions from a single shard; they are aggregated with chunks from other shards into a block by block producers. Because all active validators are currently on a single shard, they are both chunk and block producers.


In NEAR, Ⓝ represents the right to store data on the chain. As an example, Jane maintains a balance of 1 Ⓝ in her account she can store roughly 10 kilobytes. Therefore, users need to maintain a minimum balance on their account (a fraction of Ⓝ) in order to participate in the network.

This payment system means contracts must lockup Ⓝ in proportion to the amount of data they secure. A contract that maintains balances for millions of users would need to have a balance that covers the necessary storage.

Because most users have very low storage rates, they won’t need to be concerned with tracking their Ⓝ balance. However, dApps and large smart contracts will need to be conscious of their balance.

Contract rewards

NEAR apportions 30% of transaction fees to the contracts involved in those transactions.

For example, a transaction sent to smart contract X with a 0.0001 Ⓝ fee, and without calls to any other contracts, will net smart contract X reward of 0.00003 Ⓝ (30% of 0.0001 Ⓝ). If contract X uses contract Y for 50% of its functionality (measured by gas usage), the reward is split between X and Y. This process allows frequently-used libraries to earn rewards from all the client applications that use them.

Account Name Auction

NEAR Protocol uses human-readable account names. These accounts are a user’s digital identity and can be connected to finances, data ownership, and cryptography.

There are two lengths possible for these names: shorter than 32 characters and longer than 32 characters. As shorter names are expected to have more value for users, a naming auction will take place shortly after MainNet launch. Longer names can be registered on a first-come first-serve basis.

Why Run a Node?

NEAR’s Mainnet is currently running as a Proof-of-Authority network but is planning to transition to a Restricted Mainnet sometime in July or August, 2020. If you are a NEAR token holder, you can begin running a validator at that time. Although there is no inflation during the Restricted stage, the NEAR team will be awarding stipends of 10,000 Ⓝ tokens per month for those who participate.

During the Restricted stage, validators will vote to progress to the next, community-governed stage. Only validators will be able to vote at that time; the validator will vote on behalf of their own stake as well as those who delegate to them. The voting power of the validator continues to be magnified in the community stage by having the additional delegated tokens on the validator.

As NEAR develops and introduces new shards, the network will become more reliant on high-quality validators, as they are distributed among the different shards. Having too few validators in the network will create performance vulnerabilities.

"It’s been great working with the Bison Trails team, learning from their hands on experience with other PoS networks to improve our own staking experience and protocol design. Bison Trails has been on the forefront of what is now considered the professional validator industry, making participation in blockchain networks more accessible and helping to provide more high quality operators to the network." —Illia Polosukhin, NEAR Co-founder

Why Run NEAR Nodes with Bison Trails?

  • Bison Trails has been working with the NEAR team since March 2019. As active participants in their first incentivized testnet (Stake Wars), we provided feedback and recommendations for improvements to the network.
  • In preparation for a reboot of their incentivized testnet, we worked with the NEAR team to improve their internal processes and system designs. In particular, we connected them with other experienced protocol teams to learn and adapt their methodologies.
  • Our engineering team also consulted with NEAR about network upgrade processes and our experience with other protocols: what has worked well, what methods we’ve seen, how we test upgrades, how we roll them out, and so on.
  • In addition, we are one of the six founding members of the NEAR Validator Advisory Board (NVAB). This group of professional validators is engaged in group discussions, product advice and feedback, testing beta releases, and suggesting features on NEAR Protocol.
"The formation of the NEAR's Validator Advisory Board reflects the team's commitment to engaging the community to rethink how blockchains should work. NEAR's approach is both ambitious and pragmatic—I admire how the team has driven the protocol development forward while questioning assumptions and pushing the boundaries of user and developer experience. I'm thrilled to be included in the Validator Advisory Board and I look forward to further collaboration.” —Viktor Bunin, Protocol Specialist at Bison Trails

Bison Trails: Pioneering Blockchain Infrastructure™

Bison Trails is an Infrastructure-as-a-Service company, based in New York City, specifically focused on blockchain participation. We’ve built a platform for anyone who wants to participate in new chains effortlessly (e.g. by running Cosmos Validators, Tezos Bakers, and Libra Validators, etc.)—without having to invest time and resources into developing any of the engineering, protocol, dev ops, or security competencies in-house. Our goal is for the entire blockchain ecosystem to flourish by providing robust infrastructure for the pioneers of tomorrow.