jcarbonnell/preTrainingNEAR huggingface dataset:
---
id: relayers
title: Relayers
---

A relayer is a simple web service that receives signed transactions from NEAR users, and relays them to the network while attaching tokens to sponsor their GAS expenses. This can be useful to create applications in which the users are not required to purchase NEAR in order to be able to transact. In this document we present a high-level overview on how relayers work. Please check the [build a relayer](../../2.build/welcome.md) page if you want to learn how to build your own relayer.

---

## How it works

![relayer-overview](/docs/assets/welcome-pages/relayer-overview.png)

Relayers are a natural consequence of [Meta Transactions](meta-tx.md) ([NEP-366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md)), a special type of transaction that can be best understood as an intent.

The user expresses: _"I want to do a specific action on chain"_ and signs this intent **off-chain**, but does not send it to the network. Instead, they send the intent to a `Relayer`, which wraps the message into an actual transaction, attaches the necessary funds, and sends it to the network.

<details>
<summary> Technical Details </summary>

Technically, the end user (client) creates a `SignedDelegateAction` that contains the data necessary to construct a `Transaction`, signs the `SignedDelegateAction` using their key, and send it to  the relayer service.

When the request is received, the relayer uses its own key to sign a `Transaction` using the fields in the `SignedDelegateAction` as input to create a `SignedTransaction`.

The `SignedTransaction` is then sent to the network via RPC call, and the result is sent back to the client. The `Transaction` is executed in such a way that the relayer pays the GAS fees, but all actions are executed as if the user had sent the transaction.
</details>

---

## Why use a Relayer?
There are multiple reasons to use a relayer:
1. Your users are new to NEAR and don't have any gas to cover transactions
2. Your users have an account on NEAR, but only have a Fungible Token Balance. They can now use the FT to pay for gas
3. As an enterprise or a large startup you want to seamlessly onboard your existing users onto NEAR without needing them to worry about gas costs and seed phrases
4. As an enterprise or large startup you have a user base that can generate large spikes of user activity that would congest the network. In this case, the relayer acts as a queue for low urgency transactions
5. In exchange for covering the gas fee costs, relayer operators can limit where users spend their assets while allowing users to have custody and ownership of their assets
6. Capital Efficiency: Without relayer if your business has 1M users they would have to be allocated 0.25 NEAR to cover their gas costs totalling 250k NEAR. However, only ~10% of the users would actually use the full allowance and a large amount of the 250k NEAR is just sitting there unused. So using the relayer, you can allocate 50k NEAR as a global pool of capital for your users, which can refilled on an as needed basis.
---
sidebar_position: 1
---

# The NEAR Protocol Specification

Near Protocol is the scalable blockchain protocol.

For the overview of the NEAR Protocol, read the following documents in numerical order.
1. [Terminology](Terminology.md)
2. [Data structures](DataStructures/)
3. [Architecture](Architecture.md)
4. [Chain specification](ChainSpec/)
5. [Runtime specification](RuntimeSpec/)
6. [Network specification](NetworkSpec/NetworkSpec.md)  
7. [Economics](Economics/Economic.md)

## Standards

Standards such as Fungible Token Standard can be found in [Standards](Standards/README.md) page.
# Runtime

Runtime layer is used to execute smart contracts and other actions created by the users and preserve the state between the executions.
It can be described from three different angles: going step-by-step through various scenarios, describing the components
of the runtime, and describing the functions that the runtime performs.

## Scenarios

- Financial transaction -- we examine what happens when the runtime needs to process a simple financial transaction;
- Cross-contract call -- the scenario when the user calls a contract that in turn calls another contract.

## Components

The components of the runtime can be described through the crates:

- `near-vm-logic` -- describes the interface that smart contract uses to interact with the blockchain.
  Encapsulates the behavior of the blockchain visible to the smart contract, e.g. fee rules, storage access rules, promise rules;
- `near-vm-runner` crate -- a wrapper around Wasmer that does the actual execution of the smart contract code. It exposes the
  interface provided by `near-vm-logic` to the smart contract;
- `runtime` crate -- encapsulates the logic of how transactions and receipts should be handled. If it encounters
  a smart contract call within a transaction or a receipt it calls `near-vm-runner`, for all other actions, like account
  creation, it processes them in-place.

The utility crates are:

- `near-runtime-fees` -- a convenience crate that encapsulates configuration of fees. We might get rid ot it later;
- `near-vm-errors` -- contains the hierarchy of errors that can be occurred during transaction or receipt processing;
- `near-vm-runner-standalone` -- a runnable tool that allows running the runtime without the blockchain, e.g. for
  integration testing of L2 projects;
- `runtime-params-estimator` -- benchmarks the runtime and generates the config with the fees.

Separately, from the components we describe [the Bindings Specification](Components/BindingsSpec/BindingsSpec.md) which is an
important part of the runtime that specifies the functions that the smart contract can call from its host -- the runtime.
The specification is defined in `near-vm-logic`, but it is exposed to the smart contract in `near-vm-runner`.

## Functions

- Receipt consumption and production
- Fees
- Virtual machine
- Verification
```js
import { Wallet } from './near-wallet';

const TOKEN_CONTRACT_ADDRESS = "token.v2.ref-finance.near";
const wallet = new Wallet({ createAccessKeyFor: TOKEN_CONTRACT_ADDRESS });
 
await wallet.callMethod({
  method: 'ft_transfer_call',
  args: {
    receiver_id: "v2.ref-finance.near",
    amount: "100000000000000000",
    msg: "",
  },
  contractId: TOKEN_CONTRACT_ADDRESS,
  gas: 300000000000000,
  deposit: 1
});
```

<details>
<summary>Example response</summary>
<p>

```json
'100000000000000000'
```

</p>

</details>

_The `Wallet` object comes from our [quickstart template](https://github.com/near-examples/hello-near-examples/blob/main/frontend/near-wallet.js)_
NEAR Lunch & Learn Ep. 03: Light clients in Proof-of-Stake systems
COMMUNITY
November 14, 2019
In this video we discuss the challenges of implementing light clients in Proof-of-Stake systems that either do not use BFT consensus at all, or use some sort of BFT finality gadget, but allow a large sequence of blocks to be created without any of them being finalized.

We start by covering light clients in Proof of Work systems. In a Proof of Work system for as long as the client can verify proofs of work in the headers, it is extremely complex for an adversary to convince a light client that a particular chain is canonical without executing an Eclipse attack, or carrying out a several hours long 51% attack.

We then cover light clients in BFT systems, in which each block is finalized. In such a system the light client can just confirm that each block has the signature of a super majority of validators, and confirm locally that the validator set transitions were executed properly. Unless the adversary at some point controlled a super majority of validators, or executed a long-range attack, they cannot trick a light client into believing that an adversarial chain is canonical.

Finally, we cover a major challenge of designing a light client in a proof of stake system that doesn’t use BFT finality, or allows epochs without finalized blocks. We argue that to support the clients a Proof-of-Stake system either needs to require each epoch to have at least one block finalized, or to use some scarce resource (such as work or space) in addition to Proof-of-Stake.
NEAR and Alibaba Cloud Team Up to Grow the Open Web
NEAR FOUNDATION
June 26, 2023
NEAR Foundation is excited to announce a major new partnership with Alibaba Cloud, the digital technology and intelligence backbone of Alibaba Group. 

In this new partnership, NEAR Foundation will collaborate with Alibaba Cloud to offer Remote Procedure Calls (RPC) as a service to developers and users in the NEAR ecosystem, as well as multi-chain data indexing to provide data query API to developers. The partnership will also find the companies collaborating on tools to help developers build decentralized applications more easily. 

“Our partnership with Alibaba Cloud is a major milestone for the NEAR Foundation as it proves that NEAR protocol’s technology has the capabilities to truly lift the restrictions surrounding Web3 development to allow more creators to build exciting applications while also helping to onboard billions of Web2 users to the possibility of Web3.,” said Marieke Flament, CEO of the NEAR Foundation. “We look forward to supporting Alibaba Cloud as it leverages the scalability of NEAR Blockchain and the BOS to expand its Web3 offerings to a global market.”

Alibaba Cloud infrastructure to help power the BOS
App developers building on the NEAR Blockchain Operating System (BOS) — a common layer for browsing and discovering open web experiences, compatible with any blockchain — will now also enjoy Alibaba Cloud’s infrastructure. 

With BOS, now accessible directly on Near.org through a browser, developers can easily fork components and create new experiences, while end users can explore open web experiences, social, and news all in one place. FastAuth, a new standout BOS feature, allows app developers to onboard new users with only an email — no crypto required. 

Alibaba Cloud’s plug-and-play infrastructure will empower NEAR developers
Commenting on the partnership, Raymond Xiao, Head of International Web3 Solutions, Alibaba Cloud Intelligence, said: “The NEAR Foundation and Alibaba Cloud partnership is an important one as we continue to support Web3 developers to explore opportunities.”

“It is also significant for developers and validators in the Asian markets, as they can leverage Alibaba Cloud’s comprehensive infrastructure in Asia,” Xioa added. “Together with NEAR’s Node-as-a-Service initiative and BOS, we supports the Web3 community create exciting applications that will benefit a wide consumer audience. We are looking forward to what we can achieve with this partnership.”

NEAR Foundation and Alibaba Cloud will continue to expand its partnership together through collaborations at a variety of global Web3 conferences and events.
# Enumeration

## [NEP-181](https://github.com/near/NEPs/blob/master/neps/nep-0181.md)

Version `1.0.0`

## Summary

Standard interfaces for counting & fetching tokens, for an entire NFT contract or for a given owner.

## Motivation

Apps such as marketplaces and wallets need a way to show all tokens owned by a given account and to show statistics about all tokens for a given contract. This extension provides a standard way to do so.

While some NFT contracts may forego this extension to save [storage] costs, this requires apps to have custom off-chain indexing layers. This makes it harder for apps to integrate with such NFTs. Apps which integrate only with NFTs that use the Enumeration extension do not even need a server-side component at all, since they can retrieve all information they need directly from the blockchain.

Prior art:

- [ERC-721]'s enumeration extension

## Interface

The contract must implement the following view methods:

```ts
// Returns the total supply of non-fungible tokens as a string representing an
// unsigned 128-bit integer to avoid JSON number limit of 2^53; and "0" if there are no tokens.
function nft_total_supply(): string {}

// Get a list of all tokens
//
// Arguments:
// * `from_index`: a string representing an unsigned 128-bit integer,
//    representing the starting index of tokens to return
// * `limit`: the maximum number of tokens to return
//
// Returns an array of Token objects, as described in Core standard, and an empty array if there are no tokens
function nft_tokens(
  from_index: string|null, // default: "0"
  limit: number|null, // default: unlimited (could fail due to gas limit)
): Token[] {}

// Get number of tokens owned by a given account
//
// Arguments:
// * `account_id`: a valid NEAR account
//
// Returns the number of non-fungible tokens owned by given `account_id` as
// a string representing the value as an unsigned 128-bit integer to avoid JSON
// number limit of 2^53; and "0" if there are no tokens.
function nft_supply_for_owner(
  account_id: string,
): string {}

// Get list of all tokens owned by a given account
//
// Arguments:
// * `account_id`: a valid NEAR account
// * `from_index`: a string representing an unsigned 128-bit integer,
//    representing the starting index of tokens to return
// * `limit`: the maximum number of tokens to return
//
// Returns a paginated list of all tokens owned by this account, and an empty array if there are no tokens
function nft_tokens_for_owner(
  account_id: string,
  from_index: string|null, // default: 0
  limit: number|null, // default: unlimited (could fail due to gas limit)
): Token[] {}
```

## Notes

At the time of this writing, the specialized collections in the `near-sdk` Rust crate are iterable, but not all of them have implemented an `iter_from` solution. There may be efficiency gains for large collections and contract developers are encouraged to test their data structures with a large amount of entries. 

  [ERC-721]: https://eips.ethereum.org/EIPS/eip-721
  [storage]: https://docs.near.org/concepts/storage/storage-staking
Check Out the Pagoda Product Roadmap
DEVELOPERS
October 19, 2023
Over the past year, Pagoda has been working hard to build out the B.O.S, evolve near.org, and continue developing the NEAR protocol. While Pagoda has built and launched proprietary services in the past, almost all of our work so far in 2023 and planned for the future is free open-source software,  which we intend to become vital parts of the NEAR ecosystem. We want the community to be aware of, excited by, and engaged in this work. 

So I’m excited to announce that Pagoda is making its product roadmap public this week via GitHub. It’s honestly a bit overdue. Given our values of transparency and collaboration, we hope to involve more members of the community in the development process. We also hope this lets teams across the NEAR ecosystem plan ahead a bit better, build in parallel to Pagoda, and even get ideas for what to build based on what you feel is missing or should be prioritized. 

Right now this roadmap covers the rest of 2023 and we are committing to update the roadmap at least quarterly. The roadmap on GitHub is arranged into several views covering both the company objectives (OKRs) as well as larger workstreams (initiatives). We’ve further organized our roadmap views by product vertical and priority level, along with status and expected delivery date (which the product leads will update in real time). You may see some roadmap items displayed as “private”; this is because certain partnerships and enterprise workstreams must remain under NDA or embargo until launch. The Pagoda team will continue to iterate on this roadmap tool to make it an even richer resource for ecosystem partners and the NEAR community.

Delivering on the Open Web vision will take contributions far beyond Pagoda and we look forward to working alongside those who are as passionate about NEAR as we are. Please explore and leave comments or questions on the NEAR Social post – or on the roadmap itself – if you have feedback.
---
title: What is the NEAR Governance Forum?
description: Your go-to place to discuss everything NEAR
---

## What is the NEAR Governance Forum?

The [NEAR Governance Forum](https://gov.near.org/) is the living hub of NEAR Ecosystem. Here, NEAR Community members, developers, and the NEAR Foundation team come together to enable ecosystem participants to build something great and expand the NEAR ecosystem.

Much like the NEAR blockchain itself, the forum is completely open, accessible, and transparent. We'd love to have you on board \(if you're not already\) to help build the NEARverse.

The forum is a great place to meet creative members of the community, and find out more about how they integrate NEAR into their projects.
There are active discussions about NEAR marketing, development, the various aspects of the NEAR ecosystem, and how to teach and/or learn about NEAR.
The form is also a great place to connect to the different regional hubs for NEAR, you can connect with the community in your region, and find NEAR community members from all over the world.

One last thing before you run off to [sign up](https://gov.near.org/), do check out the next page for the Forum Guidelines.
---
sidebar_position: 2
---

# BWE Overview

BOS Web Engine (BWE) is the next-gen decentralized frontend execution environment.

BWE brings decentralized frontend development significantly closer to standard React development and provides enhanced, browser-backed security.

Key Features:
- Upgrades developer experience (TypeScript, improved debugging)
- Access to more powerful components (npm packages, true hooks, standard JS environment)
- Performance optimization & tuning (configurable trust model)
- Increased security guarantees using iframe sandboxing, removing the burden of code-level security rules

:::note
"BOS Web Engine" is a working title and will change before launch
:::

## Example Component
`Foo.tsx`
```tsx
// import CSS module
import s from './Foo.module.css';

// import another BWE component
import Account from 'near://webengine.near/Account'

// import a BWE component from the same account using a relative path
import Post from './Post'

type Props = {
  message?: string;
};

function Foo({ message = "Hello!" }: Props) {
  return (
    <div className={s.wrapper}>
      <Account props={{accountId: 'bwe-demos.near'}} />
      <Post props={{content: 'Hello World'}} />
      <p>{message}</p>
    </div>
  );
}

export default Foo as BWEComponent<Props>;
```

`Foo.module.css`
```css
.wrapper {
  display: flex;
  flex-direction: column;
  gap: 1rem;
}
```

## How it Works

1. Component code is executed with Preact in hidden iframes with sandboxing features enabled
2. When the component in the iframe has performed a render, it emits an event with the DOM produced
3. The outer window application (OWA) listens for render events from all iframes and stitches their DOM outputs together onto the visible page

Javascript runs in sandboxes, HTML/CSS is returned

![Container to Outer Window Application](/img/container-owa.png)
---
id: networks
title: NEAR Networks
sidebar_label: Networks
---

NEAR Protocol operates on several networks each operating with their own independent validators and unique state. These networks are as follows:

- [`mainnet`](/concepts/basics/networks#mainnet)
- [`testnet`](/concepts/basics/networks#testnet)
- [`localnet`](/concepts/basics/networks#localnet)

## Mainnet {#mainnet}

`mainnet` is for production ready smart contracts and live token transfers. Contracts ready for `mainnet` should have gone through rigorous testing and independent security reviews if necessary. `mainnet` is the only network where state is guaranteed to persist over time _(subject to the typical security guarantees of the network's validation process)_.

- Status: `https://rpc.mainnet.near.org/status`
- [ [NearBlocks Explorer](https://nearblocks.io) ]
- [ [Wallet](https://wallet.near.org) ]
- [ [Data Snapshots](https://near-nodes.io/intro/node-data-snapshots) ]

## Testnet {#testnet}

`testnet` is a public network and the final testing network for `nearcore` changes before deployment to `mainnet`. `testnet` is intended for testing all aspects of the NEAR platform prior to `mainnet` deployment. From account creation, mock token transfers, development tooling, and smart contract development, the `testnet` environment closely resembles `mainnet` behavior. All `nearcore` changes are deployed as release candidates on first testnet, before the changes are released on `mainnet`. A number of `testnet` validators validate transactions and create new blocks. dApp developers deploy their applications on `testnet` before deploying on `mainnet`. It is important to note that `testnet` has its own transactions and states.

- Status: `https://rpc.testnet.near.org/status`
- [ [Explorer](https://testnet.nearblocks.io) ]
- [ [Wallet](https://testnet.mynearwallet.com/) ]
- [ [Data Snapshots](https://near-nodes.io/intro/node-data-snapshots) ]

## Localnet {#localnet}

`localnet` is intended for developers who want to work with the NEAR platform independent of the public blockchain. You will need to generate nodes yourself. `localnet` gives you the total control over accounts, economics, and other factors for more advanced use cases (including making changes to `nearcore`). For developers, `localnet` is the right choice if you prefer to avoid leaking information about your work during the development process.

More on local development [here](https://near-nodes.io/validator/running-a-node)

`near-cli` [network selection](/tools/near-cli#network-selection) variable is `local`

---

:::tip Got a question?
<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
<h8>Ask it on StackOverflow!</h8>
</a>
:::