jcarbonnell/preTrainingNEAR huggingface dataset:
---
sidebar_position: 3
---

# Imports

## npm

When importing npm packages, they are fetched in the user's browser from esm.sh, an npm package CDN.

**This means that you can import npm packages directly in your BWE component without having to install them.**

Note that not every npm package will function within the BWE environment

### Supported Packages

By default, `preact` and `react` (via `preact/compat`) are available via the container's `importmap`.

The BWE team has a tracker [here](https://bos-web-engine.vercel.app/webengine.near/NPM.Tracker) which categorizes known compatibility of packages. Expect the list to grow over time.

If you have certain packages which you would like to use within BWE, please chime in on [this thread](https://github.com/near/bos-web-engine/discussions/166)

#### Expected Incompatibility

Some packages are expected to not work within BWE due to its architecture and security model. Packages which rely on the following are expected to not work:

- direct access to the `window` or `document` objects
- usage of certain React hooks, in particular `useContext` and DOM manipulation via `useRef`
- state management across iframes
- React implementation details not in parity with Preact 

In general, external component libraries (e.g. Chakra UI) and state management libraries are not well-supported in the current version.

## BWE Components

Other BWE components can be imported and embedded within your component.

### Dedicated Import Syntax

Any BWE Component can be imported using the following syntax

```
near://<account-id>/<Component>
```

e.g.
```tsx
import Message from 'near://bwe-web.near/Message'

// ...

// in use
<Message />
```

Since components use default exports, you can import them using any name you like. Note the difference between the imported name and the component path:

```tsx
import Foo from 'near://bwe-web.near/Bar'
```

### Relative Imports

Components published by the same NEAR account and in the same directory can be imported using relative paths.

```tsx
import Foo from './Foo'
```

This only works for `./` paths. Other relative imports such as `../Foo` are not implemented.

:::tip
Directory support is a work in progress. If you place `/` separators in your component name when working in the sandbox, it will be treated as a directory separator.

From a component named `Foo/Bar.tsx`, relative imports will only be resolvable for other components starting with `Foo/`.
:::
---
id: get-started
title: "Getting Started"
---

# Getting Started

:::tip Using the JS SDK on Windows
You can develop smart contracts on Windows using Windows Subsystem for Linux (WSL2).
:::

In order to use WSL2, follow the next steps:

- Run `PowerShell` as Administrator
- Execute `wsl --install` to install Ubuntu and do additional setup automatically. Check more details [here](https://learn.microsoft.com/en-us/windows/wsl/install)
- Restart your machine
- `WSL2` will continue setup process on start. Setup your username and password when prompted.
- Check [this](https://learn.microsoft.com/en-us/windows/dev-environment/javascript/nodejs-on-wsl) guide to setup `npm`, `node`, `npx`, `VSCode` and other tools of your choice in order to start developing.

In case of any issues of setting up WSL2 make sure that:

- Your Windows OS is up to date
- Virtualisation is turned on in BIOS
- `Windows Subsystem for Linux` and `Virtual Machine Platform` are turned on in `Windows Features` (Start -> Search -> Turn Windows Feature On or Off)

## Install Node

To install Node, follow the instructions on the [Node.js website](https://nodejs.org/en/download/).

## Create a new project

The best way to create a new NEAR app connected with a frontend is through [create-near-app](https://github.com/near/create-near-app). When initializing the project, be sure to select creating a project in TypeScript with a frontend option of your choice.

```bash
npx create-near-app
```

If you only wish to develop and deploy a JS contract, the [`hello-near-ts`](https://github.com/near-examples/hello-near-examples/tree/main/contract-ts) repository is great to use as a template or one of the [examples in the SDK repository](https://github.com/near/near-sdk-js/tree/develop/examples/src).

If you would like to generate a new project manually with `npm init`, make sure you include the following configuration in the generated `package.json`:

```json
  "dependencies": {
    "near-sdk-js": "*"
  }
```
```rust
// Validator interface, for cross-contract calls
#[ext_contract(ext_nft_contract)]
trait ExternalNftContract {
  fn nft_mint(&self, token_series_id: String, receiver_id: AccountId) -> Promise;
}

// Implement the contract structure
#[near_bindgen]
impl Contract {
  #[payable]
  pub fn nft_mint(&mut self, token_series_id: String, receiver_id: AccountId) -> Promise {
    let promise = ext_nft_contract::ext(self.nft_contract.clone())
      .with_static_gas(Gas(30*TGAS))
      .with_attached_deposit(env::attached_deposit())
      .nft_mint(token_series_id, receiver_id);

    return promise.then( // Create a promise to callback query_greeting_callback
      Self::ext(env::current_account_id())
      .with_static_gas(Gas(30*TGAS))
      .nft_mint_callback()
    )
  }

  #[private] // Public - but only callable by env::current_account_id()
  pub fn nft_mint_callback(&self, #[callback_result] call_result: Result<TokenId, PromiseError>) -> Option<TokenId> {
    // Check if the promise succeeded
    if call_result.is_err() {
      log!("There was an error contacting NFT contract");
      return None;
    }

    // Return the token data
    let token_id: TokenId = call_result.unwrap();
    return Some(token_id);
  }
}
---
id: state-sync
title: State Sync
sidebar_label: State Sync Configuration
sidebar_position: 4
description: State Sync Configuration
---

# Overview

See [State Sync from External Storage](https://github.com/near/nearcore/blob/master/docs/misc/state_sync_from_external_storage.md)
for a description of how to configure your node to sync State from an arbitrary
external location.

Pagoda provides state dumps for every shard of every epoch since the release of
`1.36.0-rc.1` for testnet and `1.36.0` for mainnet.

## Enable State Sync

The main option you need is `state_sync_enabled`, and then specify how to get
the state parts provided by Pagoda in the option `state_sync`.

The following snippet is included in the reference `config.json` file and
provides access to the state of every shard every epoch:

```json
"state_sync_enabled": true,
"state_sync": {
  "sync": {
    "ExternalStorage": {
      "location": {
        "GCS": {
          "bucket": "state-parts",
        }
      },
      "num_concurrent_requests": 4,
      "num_concurrent_requests_during_catchup": 4,
    }
  }
}
```

## Reference `config.json` file

Run the following command to download the reference `config.json` file:

```shell
./neard --home /tmp/ init --download-genesis --download-config --chain-id <testnet or mainnet>
```

The file will be available at `/tmp/config.json`.

## Troubleshooting

If you notice that your node runs state sync and it hasn't completed after 3 hours, please check the following:

1. Config options related to the state sync in your `config.json` file:
* `state_sync_enabled`
* `state_sync`
* `consensus.state_sync_timeout`
* `tracked_shards`
* `tracked_accounts`
* `tracked_shard_schedule`
* `archive`
* `block_fetch_horizon`

The best way to see the exact config values used is to visit a debug page of your node: `http://127.0.0.1:3030/debug/client_config`

Check whether state sync is enabled, and check whether it's configured to get state parts from the right location mentioned above.

2. Has your node ran out of available disk space?

If all seems to be configured fine, then disable state sync (set `"state_sync_enabled": false` in `config.json`) and try again.
If that doesn't help, then restart from a backup data snapshot.

## Running a Chunk-Only Producer that tracks a single shard

Enable State Sync as explained above.

And then configure the node to track no shards:

```json
"tracked_shards": [],
"tracked_accounts": [],
"tracked_shard_schedule": [],
```

It is counter-intuitive but it works. If a node stakes and is accepted as a
validator, then it will track the shard that it needs to track to fulfill its
validator role. The assignment of validators to shards is done by the consensus
of validators.

Note that in different epochs a validator may be assigned to different shards. A
node switches tracked shards by using the State Sync mechanism for a single
shard. See [catchup](https://github.com/near/nearcore/blob/master/docs/architecture/how/sync.md#catchup).
---
title: DApps
description: DApps are unique to blockchain.
---

# dApps

Decentralized Applications (dApps) are applications developed for blockchains.
They combine smart contracts with a user-friendly frontend to make it easier to interact with smart contracts.
dApps are decentralized, so, typically, they aren't under the authority of a single authority.

There are a wide variety of dApps for different purposes including: gaming, social media, and finance among other categories.

To find dApps on NEAR, take a look at [Awesome NEAR](https://awesomenear.com/), a community owned resource that lists dApps available on NEAR.

If you're interested in building dApps on NEAR, have a look at [our tutorial](https://learnnear.club/how-to-build-on-near-starting-guide/) or dive right into our [developer documentation](https://docs.near.org/).
```js
const result = Near.view(
  "nearweek-news-contribution.sputnik-dao.near",
  "get_proposals",
  { from_index: 9262, limit: 2 }
);
```

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

```js
[
  {
    id: 9262,
    proposer: 'pasternag.near',
    description: 'NEAR, a top non-EVM blockchain, has gone live on Router’s Testnet Mandara. With Router Nitro, our flagship dApp, users in the NEAR ecosystem can now transfer test tokens to and from NEAR onto other supported chains. $$$$https://twitter.com/routerprotocol/status/1727732303491961232',
    kind: {
      Transfer: {
        token_id: '',
        receiver_id: 'pasternag.near',
        amount: '500000000000000000000000',
        msg: null
      }
    },
    status: 'Approved',
    vote_counts: { council: [ 1, 0, 0 ] },
    votes: { 'brzk-93444.near': 'Approve' },
    submission_time: '1700828277659425683'
  },
  {
    id: 9263,
    proposer: 'fittedn.near',
    description: 'How to deploy BOS component$$$$https://twitter.com/BitkubAcademy/status/1728003163318563025?t=PiN6pwS380T1N4JuQXSONA&s=19',
    kind: {
      Transfer: {
        token_id: '',
        receiver_id: 'fittedn.near',
        amount: '500000000000000000000000',
        msg: null
      }
    },
    status: 'InProgress',
    vote_counts: { 'Whitelisted Members': [ 1, 0, 0 ] },
    votes: { 'trendheo.near': 'Approve' },
    submission_time: '1700832601849419123'
  }
]
```

</p>

</details>
---
sidebar_position: 4
---

# Versioning

:::warning Not Yet Available
Versioning is currently being worked on by the BWE team and is not yet available for use. **Current behavior is that the latest version of a component is always used.**
:::

BWE Components will support versioning based on blockheight at which changes were published. This resembles commits in a git repository.

Default behavior will be to use the latest version of a component **at the time of publish of the parent component**. It will be possible to specify that the current latest version of an embedded component should be loaded instead.

<details>
  <summary>Why change the default behavior from BOS components?</summary>
  <p>Locking embedded components to their state at time of publish will lead to more predictable frontend behavior across the ecosystem. We have often seen broken UI as a result of component authors not locking their embeds to a specific version and the embedded component changing in functionality or presentation.</p>
</details>
NEAR Opens the Door to More Wallets
COMMUNITY
July 29, 2022
Part of the NEAR’s mission has been to foster an ecosystem that can build and maintain the core components of a rich and vibrant Web3 ecosystem.

One of those key functions is a wallet provider. So far, to help onboard users quickly and easily to the NEAR ecosystem, the Foundation built and maintained a wallet on wallet.nearpages.wpengine.com

As NEAR continues to decentralize, it’s transitioning wallet.nearpages.wpengine.com to be a landing page for all compatible wallets operating in the ecosystem. 

The move is designed to give users more choice as they move around the Web3 space. NEAR has always believed in a multichain world, and with wallets, it takes a similar approach. 

Allowing a user from a different ecosystem to interact with the NEAR blockchain using a wallet they already know and love, is an essential part of making Web3 as easy to use as Web2. 

What happens to Wallet.NEAR.org?
As part of the transition, wallet holders on Wallet.NEAR.org will be encouraged to migrate their wallet to a new provider. The Foundation will be publishing a range of tutorials and guides for how to do that over the coming weeks.

Developers on NEAR should start the process of implementing Wallet Selector. This new modal provides a list of supported wallets, and allows dapp users to select their preferred choice of wallet.  

For developers who are currently hardcoding wallet URLs, consider implementing Wallet Selector, a link to the Github repository for implementation can be found here. 

For wallet creators, this migration presents an opportunity to onboard new users. Wallet creators will have to implement a functionality  to import an account using a private key.

Additionally, the core developer team are hosting twice a day Dev office hours if you run into any issues with Wallet-Selector integration. A link can be found here. 

As NEAR aims to have a thriving ecosystem with multiple wallets, providing a single point of integration for developers building on NEAR is vital. NEAR’s Wallet Selector fosters a rich ecosystem of wallets to thrive on NEAR Protocol and creates a simple integration experience to enable multiple wallets for DApp developers. 

What other Wallet Options are Available for NEAR? 
If you’re interested in exploring what other wallets are available in the ecosystem, there are plenty of options. In fact, there are more than 30 wallet providers compatible with NEAR. 

Check out AwesomeNEAR for a list of wallets compatible with the NEAR ecosystem. 

Stay tuned for more updates on the transition.
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

<Tabs groupId="nft-contract-tabs" className="file-tabs">
<TabItem value="Paras" label="Paras">

```bash
near call marketplace.paras.near storage_deposit '{"receiver_id": "bob.near"}' --accountId bob.near --deposit 0.00939

near call nft.primitives.near nft_approve '{"token_id": "1e95238d266e5497d735eb30", "account_id": "marketplace.paras.near", "msg": {"price": "200000000000000000000000", "market_type": "sale", "ft_token_id": "near"}}' --accountId bob.near
```

Method `nft_approve` of a NFT contract also calls the `nft_on_approve` method in `marketplace.paras.near` as a callback.

</TabItem>

<TabItem value="Mintbase" label="Mintbase">

```bash
near call simple.market.mintbase1.near deposit_storage '{"autotransfer": "true"}' --accountId bob.near --deposit 0.00939

near call nft.primitives.near nft_approve '{"token_id": "3c46b76cbd48e65f2fc88473", "account_id": "simple.market.mintbase1.near", "msg": {"price": "200000000000000000000000"}}' --accountId bob.near
```

Method `nft_approve` of a NFT contract also calls the `nft_on_approve` method in `simple.market.mintbase1.near` as a callback.

</TabItem>

</Tabs>
---
id: lock
title: Locking Accounts
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

Removing all [full access keys](../../../4.tools/cli.md#near-delete-key-near-delete-key) from an account will effectively **lock it**.

When an account is locked nobody can perform transactions in the account's name (e.g. update the code or transfer money).

#### How to Lock an Account
<Tabs className="language-tabs" groupId="code-tabs">
  <TabItem value="near-cli">

```bash
near keys <dev-account>
# result: [access_key: {"nonce": ..., "public_key": '<key>'}]

near delete-key <dev-account> '<key>'
```

</TabItem>

<TabItem value="near-cli-rs">

```bash
near account list-keys <dev-account> network-config testnet now
# result:

+---+------------+-------+-------------+
| # | Public Key | Nonce | Permissions |
+---+------------+-------+-------------+
..    '<key>'      ...        ...
+---+------------+-------+-------------+

near account delete-key <dev-account> '<key>' network-config testnet sign-with-keychain send
```

</TabItem>

</Tabs>

#### Why Locking an Account

Locking an account brings more reassurance to end-users, since they know no external actor will be able to manipulate the account's
contract or balance.

:::tip Upgrading Locked Contracts

Please do note that, while no external actor can update the contract, the contract **can still upgrade itself**. See [this article](upgrade.md#programmatic-update) for details.

:::
---
id: exchange-integration
title: Exchange Integration
sidebar_label: Exchange Integration
---

## Integration Reference {#integration-reference}

- [Balance Changes](/integrations/balance-changes)
- [Accounts](/integrations/accounts)
- [Fungible Tokens](/integrations/fungible-tokens)
- [Implicit Accounts](/integrations/implicit-accounts)

### Transaction Reference Links {#transaction-reference-links}

 - [Basics](/concepts/protocol/transactions)
 - [Specifications](https://nomicon.io/RuntimeSpec/Transactions)
 - [Constructing Transactions](/integrations/create-transactions)

## Blocks and Finality {#blocks-and-finality}

Some important pieces of information regarding blocks and finality include:

- Expected block time is around 1s and expected time to finality is around 2s. The last final block can be queried by
  specifying `{"finality": "final"}` in the block query. For example, to get the latest final block on mainnet, one can run

```bash
http post https://rpc.mainnet.near.org method=block params:='{"finality":"final"}' id=123 jsonrpc=2.0
```

- Block height are not necessarily continuous and certain heights may be skipped if, for example, a block producer for that height is offline. For example, after a block at height 100 is produced, the block at height 101 may be skipped. When block at height 102 is produced, its previous block is the block at height 100.

- Some blocks may not include new chunks if, for example, the previous chunk producer is offline. Even though in the RPC
  return result every block will have non-empty `chunks` field, it does not imply that there is a new chunk included in the block.
  The way to tell whether the chunk is included in the block is to check whether `height_included` in the chunk is the same
  as the height of the block.

## Running an Archival Node {#running-an-archival-node}
Please refer to configuration changes required in `config.json` for archival node by referring to the documentation on [Run an Archival Node](https://near-nodes.io/archival/run-archival-node-with-nearup).

## Staking and Delegation {#staking-and-delegation}

- [https://github.com/nearprotocol/stakewars](https://github.com/nearprotocol/stakewars)
- [https://github.com/near/core-contracts](https://github.com/near/core-contracts)

:::tip Got a question?
<a href="https://stackoverflow.com/questions/tagged/nearprotocol"> Ask it on StackOverflow! </a>
:::
---
id: run-archival-node-with-nearup
title: Run an Archival Node (with nearup)
sidebar_label: Run a Node (with nearup)
sidebar_position: 3
description: How to run an Archival Node with nearup
---

*We encourage you to set up your node with Neard instead of Nearup as Nearup is not used on Mainnet. Please head to [Run a Node](/archival/run-archival-node-without-nearup) for instructions on how to setup an archival node with Neard.*

<blockquote class="info">
<strong>Heads up</strong><br /><br />

Running an archival node is very similar to running a [validator node](/validator/running-a-node) as both types of node use the same `nearcore` release. The main difference for running an archival node is a modification to the `config.json` by changing `archive` to `true`. See below for more details.

</blockquote>


## Prerequisites {#prerequisites}

- [Git](https://git-scm.com/)
- [Nearup](https://github.com/near-guildnet/nearup): Make sure [`nearup`](https://github.com/near-guildnet/nearup) is installed. You can install `nearup` by following the instructions at https://github.com/near-guildnet/nearup.

---

### Steps to Run an Archival Node using `nearup` {#steps-to-run-an-archival-node-using-nearup}

First, retrieve a copy of the latest archival snapshot from S3:
```bash
$ aws s3 --no-sign-request cp s3://near-protocol-public/backups/testnet/archive/latest .
$ LATEST=$(cat latest)
$ aws s3 --no-sign-request cp --no-sign-request --recursive s3://near-protocol-public/backups/testnet/archive/$LATEST ~/.near/data
```


### Configuration Update {#configuration-update}

Running an archival node is the same as a [validator node](/validator/running-a-node) as both types of node use the same `nearcore` release. The main difference for running an archival node is a modification to the `config.json` by changing `archive` to `true`.

The `config.json` should contain the following fields. Currently, NEAR testnet and mainnet have only 1 (indexed [0]) shard and that shard is tracked. In the future, there will be the possibility to track different or multiple shards.

```
{
  ...
  "archive": true,
  "tracked_shards": [0],
  ...
}
```

Please make sure that the node is stopped while changing the `config.json`.

Once the config has been changed, you can restart the node and the node will start syncing new archival data. In the case where you want the full archival history, you can delete the data dir and start the node from scratch syncing full history or use one of the latest backups containing the data directory snapshot which can be copied under the near home dir (default: ~/.near/data).



Then run:
```bash
  $ nearup run testnet
```
Wait until initialization finishes, use the following command to follow logs:
```bash
  $ nearup logs --follow
```
Then run:
```bash
  $ nearup stop
```
Finally, run the following command and the node should start syncing headers at ~97%:
```bash
  $ nearup run testnet
```

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

|NEP #   | Title  | Author  | Status  |
|---|---|---|---|
|[0001](https://github.com/near/NEPs/blob/master/neps/nep-0001.md)   | FIP Purpose and Guidelines  | @jlogelin  | Active  |
|[0021](https://github.com/near/NEPs/blob/master/neps/nep-0021.md)   | Fungible Token Standard (Deprecated) | @aevgenykuzyakov | Final |
|[0141](https://github.com/near/NEPs/blob/master/neps/nep-0141.md)   | Fungible Token Standard | @aevgenykuzyakov @oysterpack | Final |
|[0145](https://github.com/near/NEPs/blob/master/neps/nep-0145.md)   | Storage Management | @aevgenykuzyakov | Final |
|[0148](https://github.com/near/NEPs/blob/master/neps/nep-0148.md)   | Fungible Token Metadata | @robert-zaremba @aevgenykuzyakov @oysterpack | Final |
|[0171](https://github.com/near/NEPs/blob/master/neps/nep-0171.md)   | Non Fungible Token Standard | @mikedotexe @aevgenykuzyakov @oysterpack | Final |
|[0177](https://github.com/near/NEPs/blob/master/neps/nep-0177.md)   | Non Fungible Token Metadata | @chadoh @mikedotexe | Final |
|[0178](https://github.com/near/NEPs/blob/master/neps/nep-0178.md)   | Non Fungible Token Approval Management | @chadoh @thor314 | Final |
|[0181](https://github.com/near/NEPs/blob/master/neps/nep-0181.md)   | Non Fungible Token Enumeration | @chadoh @thor314 | Final |
|[0199](https://github.com/near/NEPs/blob/master/neps/nep-0199.md)   | Non Fungible Token Royalties and Payouts | @thor314 @mattlockyer | Final |
|[0297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md)   | Non Fungible Token Royalties and Payouts | @telezhnaya | Final |