+
Backend Integration
Use NEAR in your server.
diff --git a/docs/2.develop/relevant-contracts/dao.md b/docs/2.develop/relevant-contracts/dao.md
index 0ef0880234b..045c768185c 100644
--- a/docs/2.develop/relevant-contracts/dao.md
+++ b/docs/2.develop/relevant-contracts/dao.md
@@ -52,7 +52,7 @@ When the vote policy is `RoleWeight(role)`, the vote weigh is computed as "one o
Both voting policies further include a "threshold" for passing a proposal, which can be a ratio or a fixed number. The ratio indicates that you need a proportion of people/tokens to approve the proposal (e.g. half the people need to vote, and to vote positively). A fixed number indicated that you need a specific number of votes/tokens to pass the proposal (e.g. 3 people/tokens are enough to approve the proposal).
-
+
## Adding a Proposal
By default, anyone can add a proposal to the DAO, but a minimum of 1Ⓝ needs to be attached as a bond. This however can be changed by [setting roles in the DAO](https://github.com/near-daos/sputnik-dao-contract#roles-and-permissions). The type of proposals that can be added [is predefined](https://github.com/near-daos/sputnik-dao-contract#proposal-types), and include actions such as:
@@ -77,7 +77,7 @@ Each action has its own kind of arguments. The complete list of actions can be [
-
+
## Acting on a Proposal
Once a proposal is added, **council members** can act on them calling the `act_proposal` method. The available actions are one of the following: AddProposal, RemoveProposal, VoteApprove, VoteReject, VoteRemove, Finalize, or MoveToHub.
diff --git a/docs/2.develop/relevant-contracts/ft.md b/docs/2.develop/relevant-contracts/ft.md
index 5180d407d4f..d8aecbe5f7c 100644
--- a/docs/2.develop/relevant-contracts/ft.md
+++ b/docs/2.develop/relevant-contracts/ft.md
@@ -41,7 +41,7 @@ Creating a new FT is as simple as deploying a new FT contract and initializing i
On initialization you will define an **owner**, who will own **ALL** the tokens.
:::
-
+
## Querying Metadata
You can query the FT's metadata by calling the `ft_metadata`.
@@ -56,7 +56,7 @@ You can query the FT's metadata by calling the `ft_metadata`.
-
+
## Registering a User
In order for a user to own and transfer tokens they need to first **register** in the contract. This is done by calling `storage_deposit` and attaching 0.00125Ⓝ. This method also allows to pay for other users to register them.
@@ -80,7 +80,7 @@ You can make sure a user is registered by asserting they have a `storage_balance
After you call the `storage_deposit` the FT will appear in the NEAR WALLET.
:::
-
+
## Getting Balance
To know how many coins a user has you will need to query the method `ft_balance_of`.
@@ -99,7 +99,7 @@ To know how many coins a user has you will need to query the method `ft_balance_
Keep in mind the `decimals` from the [metadata](#query-metadata). A balance of `150 FT` for a token with 2 `decimals` actually represents `1.50 FT`.
:::
-
+
## Transferring
To send FT to another account you will use the `ft_transfer` method, indicating the receiver and the amount of FT you want to send.
@@ -122,7 +122,7 @@ Implement [events](https://nomicon.io/Standards/Tokens/FungibleToken/Event) to b
In order to send a fungible token to an account, both the sender and receiver must be [registered](#register-a-user) in the FT contract.
:::
-
+
## Attaching FTs to a Call
Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a method call in your name.
@@ -154,7 +154,7 @@ From the workflow above it follows that the receiver we want to call needs to im
The `ft_on_transfer` **must** return **how many FT tokens have to be refunded**, so the FT contract gives them back to the sender.
-
+
## Events
You can track real time events (such as transfers) by implementing the [FT Event Standards](https://nomicon.io/Standards/Tokens/FungibleToken/Event).
diff --git a/docs/2.develop/relevant-contracts/nft.md b/docs/2.develop/relevant-contracts/nft.md
index 6821d1282db..dc6e5955faa 100644
--- a/docs/2.develop/relevant-contracts/nft.md
+++ b/docs/2.develop/relevant-contracts/nft.md
@@ -54,7 +54,7 @@ Implement [events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) t
:::
-
+
## Querying Metadata
You can query the NFT's metadata by calling the `nft_metadata`.
@@ -69,7 +69,7 @@ You can query the NFT's metadata by calling the `nft_metadata`.
-
+
## Approving Users
You can authorize other users to transfer an NFT you own. This is useful, for example, to enable listing your NFT in a marketplace. In such scenario, you **trust** that the marketplace will only transfer the NFT upon receiving a certain amount of money in exchange.
@@ -94,7 +94,7 @@ If the `msg` parameter is included, then a cross-contract call will be made to `
:::
-
+
## Transferring an NFT
Transferring an NFT can happen in two scenarios: (1) you ask to transfer an NFT, and (2) an authorized account asks to transfer the NFT. In both cases, it is necessary to invoke the `nft_transfer` method, indicating the token id, the receiver, and an (optionally) an [approval_id](https://nomicon.io/Standards/Tokens/NonFungibleToken/ApprovalManagement).
@@ -113,7 +113,7 @@ Transferring an NFT can happen in two scenarios: (1) you ask to transfer an NFT,
Implement [events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) to be able to [track NFT transfers in real time](../../4.tools/events.md).
:::
-
+
## Attaching NFTs to a Call
Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a method call in your name.
@@ -149,7 +149,7 @@ From the workflow above it follows that the receiver we want to call needs to im
The `nft_on_transfer` **must return true** if the NFT has to be **returned to the sender**.
-
+
## Events
You can track real time events (such as transfers) by implementing the [NFT Event Standards](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event).
diff --git a/docs/2.develop/testing/integration.md b/docs/2.develop/testing/integration.md
index 1f394229498..8a1baa206f0 100644
--- a/docs/2.develop/testing/integration.md
+++ b/docs/2.develop/testing/integration.md
@@ -1,6 +1,6 @@
---
id: integration-test
-title: Integration Test
+title: Integration Tests
#sidebar_label: 🥼 Integration Test
---
import {CodeTabs, Language, Github} from "@site/src/components/codetabs"
@@ -15,10 +15,11 @@ Moreover, when using the local `sandbox` you gain complete control of the networ
2. Simulate errors on callbacks.
3. Control the time-flow and fast-forward into the future (Rust ready, TS coming soon).
-### NEAR Workspaces
+:::tip NEAR Workspaces
In NEAR, integration tests are implemented using a framework called **Workspaces**. Workspaces comes in two flavors: [🦀 Rust](https://github.com/near/workspaces-rs) and [🌐 Typescript](https://github.com/near/workspaces-js).
-If you used one of our [examples](https://github.com/near-examples/docs-examples) as template, then integration testing using `workspaces-js` is already implemented, and you simply need to run `yarn test:integration` from the project's root folder.
+All of our [examples](https://github.com/near-examples/docs-examples) come with integration testing.
+:::
---
@@ -26,17 +27,17 @@ If you used one of our [examples](https://github.com/near-examples/docs-examples
Lets take a look at the test of our [Quickstart Project](../quickstart.md) [👋 Hello NEAR](https://github.com/near-examples/hello-near-rs), where we deploy the contract on an account and test it correctly retrieves and sets the greeting.
-
+
---
+
## Snippet II: Testing Donations
In most cases we will want to test complex methods involving multiple users and money transfers. A perfect example for this is our [Donation Example](https://github.com/near-examples/donation-js), which enables users to `donate` money to a beneficiary. Lets see its integration tests:
-
-
+
+
```ts
const refFinance = await root.importContract({
@@ -75,7 +76,7 @@ This would copy the Wasm bytes and contract state from [v2.ref-finance.near](htt
See a [TypeScript example of spooning](https://github.com/near/workspaces-js/blob/main/__tests__/05.spoon-contract-to-sandbox.ava.ts) contracts.
-
+
Specify the contract name from `testnet` you want to be pulling, and a specific block ID referencing back to a specific time. (Just in case the contract you're referencing has been changed or updated)
@@ -135,8 +136,8 @@ You can alter contract code, accounts, and access keys using normal transactions
Keep in mind that you cannot perform arbitrary mutation on contract state with transactions since transactions can only include contract calls that mutate state in a contract-programmed way. For example, with an NFT contract, you can perform some operation with NFTs you have ownership of, but you cannot manipulate NFTs that are owned by other accounts since the smart contract is coded with checks to reject that. This is the expected behavior of the NFT contract. However, you may want to change another person's NFT for a test setup. This is called "arbitrary mutation on contract state" and can be done with `patchState`:
-
-
+
+
```js
const {contract, ali} = t.context.accounts;
@@ -165,7 +166,7 @@ Keep in mind that you cannot perform arbitrary mutation on contract state with t
To see a complete example of how to do this, see the [patch-state test](https://github.com/near/workspaces-js/blob/main/__tests__/02.patch-state.ava.ts).
-
+
```rust
// Grab STATE from the testnet status_message contract. This contract contains the following data:
@@ -218,17 +219,17 @@ This approach is more complex to do and also cannot be performed without restart
### Time Traveling
-`workspaces` testing offers support for forwarding the state of the blockchain to the future. This means contracts which require time sensitive data do not need to sit and wait the same amount of time for blocks on the sandbox to be produced. We can simply just call `worker.fast_forward` to get us further in time:
+`workspaces` offers support for forwarding the state of the blockchain to the future. This means contracts which require time sensitive data do not need to sit and wait the same amount of time for blocks on the sandbox to be produced. We can simply just call `worker.fast_forward` to get us further in time:
-
-
+
+
-:::note
-Time Traveling in `workspaces-js` is currently unavailable.
-:::
+
-
+
```rust
#[tokio::test]
@@ -243,12 +244,11 @@ async fn test_contract() -> anyhow::Result<()> {
.await?;
}
```
+_[See the full example on Github](https://github.com/near/workspaces-rs/blob/main/examples/src/fast_forward.rs)._
-For a full Rust example, take a look at [examples/src/fast_forward.rs](https://github.com/near/workspaces-rs/blob/main/examples/src/fast_forward.rs).
-
---
## Using Testnet
@@ -270,8 +270,8 @@ You can switch to testnet mode in three ways.
1. When creating Worker set network to `testnet` and pass your master account:
-
-
+
+
```ts
const worker = await Worker.init({
@@ -281,7 +281,7 @@ const worker = await Worker.init({
```
-
+
```rust
#[tokio::main] // or whatever runtime we want
@@ -300,8 +300,8 @@ let worker = workspaces::testnet().await?;
2. Set the `NEAR_WORKSPACES_NETWORK` and `TESTNET_MASTER_ACCOUNT_ID` environment variables when running your tests:
-
-
+
+
```bash
NEAR_WORKSPACES_NETWORK=testnet TESTNET_MASTER_ACCOUNT_ID= node test.js
@@ -314,8 +314,8 @@ If you set this environment variables and pass `{network: 'testnet', testnetMast
3. If using `near-workspaces` with AVA, you can use a custom config file. Other test runners allow similar config files; adjust the following instructions for your situation.
-
-
+
+
Create a file in the same directory as your `package.json` called `ava.testnet.config.cjs` with the following contents:
diff --git a/docs/2.develop/testing/workspaces-migration-guide.md b/docs/2.develop/testing/workspaces-migration-guide.md
deleted file mode 100644
index d732067528a..00000000000
--- a/docs/2.develop/testing/workspaces-migration-guide.md
+++ /dev/null
@@ -1,316 +0,0 @@
----
-id: workspaces-migration
-sidebar_label: "Workspaces Migration"
-title: "Migrating from Simulation Testing to Workspaces"
----
-
-# Migrating from Simulation Testing to Workspaces
-
-### Why did we stop supporting Simulation Testing?
-
-Simulation tests were not suitable for purpose for a few reasons, namely:
-
-- `near-sdk-sim` was hooking into parts of nearcore that were not meant to be released, in the most recent version those crates aren't released so `near-sdk-sim` is currently using duplicate dependencies (maintenance nightmare).
-- Not a fully accurate simulation because it just used a subset of the runtime in a specific way - we can't rely on this. And thus couldn't measure gas burnt accurately. Also, all the intricacies of nearcore (like protocol features) wouldn't be one-to-one with the runtime since the runtime was just code built on top of VM logic. People would also need to write their own automation scripts to deploy to testnet, so we'd end up with very split workflows for testing.
-- Bulky dependencies pulled in (drastically increases compile time).
-- Unergonomic API, not specific to this strategy, but likely would have had to be re-built.
-- Can't test parallel transactions easily - current pattern would process blocks until a transaction succeeded but you can't create specific conditions, which is required for a strategy like this that isn't fully simulated.
-
-:::info
-This guide presumes that you are transitioning from near-sdk-sim `3.2.0` (the last non-deprecated release) to `workspaces-rs` `0.2.1`. Given that near-sdk-sim is deprecated, it is very unlikely that its API will ever change, but future releases of `workspaces-rs` might. Hopefully, this guide will be helpful even if you are migrating your project to a more recent workspaces version. If workspaces have changed, feel free to migrate your tests to `0.2.1` first using this guide and upgrade to the most recent workspaces-rs version later by looking at the release notes to see how public API has changed since `0.2.1`.
-:::
-
-## Async Runtime and Error Handling
-
-In this section we will be working purely with test signatures, so it applies to pretty much all NEAR contract tests regardless of what is written inside. We will walk through each change one by one. Let's start with how your tests look like right now; chances are something like this:
-
-```rust
-#[test]
-fn test_transfer() {
- ...
-}
-```
-
-First big change is that `workspaces-rs` API is asynchronous, meaning that contract function calls return values that implement `Future` trait. You will not be able to operate on the call results in a synchronous environment, thus you will have to add an async runtime (if you do not already have one). In this guide we are going to be using [`tokio`](https://tokio.rs/), but you should be able to use any other alternative (e.g. [`async-std`](https://async.rs/), [`smol`](https://github.com/smol-rs/smol)). Rewrite the test above like this:
-
-```rust
-#[tokio::test]
-async fn test_transfer() {
- ...
-}
-```
-
-:::note
-If you are using another attribute on top of the standard `#[test]`, make sure it plays nicely with the async runtime of your choosing. For example, if you are using [`test-env-log`](https://crates.io/crates/test-env-log) and `tokio`, then you need to mark your tests with `#[test_env_log::test(tokio::test)]`.
-:::
-
-The second change is that `workspaces-rs` makes an extensive use of [`anyhow::Result`](https://docs.rs/anyhow/latest/anyhow/type.Result.html). Although you can work with `Result` directly, our recommendation is to make your tests return `anyhow::Result<()>` like this:
-
-```rust
-#[tokio::test]
-async fn test_transfer() -> anyhow::Result<()> {
- ...
-}
-```
-
-This way you can use `?` anywhere inside the test to safely unpack any `anyhow::Result` type to `R` (will be very useful further down the guide). Note that the test will fail if `anyhow::Result` cannot be unpacked.
-
-## Initialization and Deploying Contracts
-
-Unlike NEAR Simulator, `workspaces-rs` uses an actual NEAR node and makes all calls through it. First, you need to decide which network you want your tests to be run on:
-
-- `sandbox` - perfect choice if you are just interested in local development and testing; `workspaces-rs` will instantiate a [sandbox](https://github.com/near/sandbox) instance on your local machine which will run an isolated NEAR node.
-- `testnet` - an environment much closer to the real world; you can test integrations with other deployed contracts on testnet without bearing any financial risk.
-- `mainnet` - a network with reduced amount of features due to how dangerous it can be to do transactions there, but can still be useful for automating deployments and pulling deployed contracts.
-
-In this guide we will be focusing on `sandbox` since it covers the same use cases NEAR Simulator did. But of course feel free to explore whether other networks can be of potential use to you when writing new tests/workflows.
-
-One of the ways to initialize simulator and deploy a contract is shown below (the other way is through `deploy!` macro which we will look at in the next section):
-
-```rust title="Deployment - near-sdk-sim"
-use near_sdk_sim::{init_simulator, to_yocto};
-
-near_sdk_sim::lazy_static_include::lazy_static_include_bytes! {
- WASM_BYTES => "res/contract.wasm",
-}
-
-const ID: &str = "contract-id";
-
-...
-
-let root = init_simulator(...);
-let contract = root.deploy(&WASM_BYTES, ID.parse().unwrap(), to_yocto("5"));
-```
-
-Although `workspaces-rs` provides a way to specify the account id for a contract to be deployed, usually it does not matter in the context of a single test. If you are fine with generating a random developer account and initializing it with 100N, then you can replace the snippet above with this:
-
-```rust title="Deployment - workspaces-rs"
-let worker = workspaces::sandbox().await?;
-let contract = worker.dev_deploy(include_bytes!("../res/contract.wasm")).await?;
-```
-
-Alternatively, use this if you care about the account id:
-
-```rust title="Deployment - workspaces-rs (with explicit account id)"
-let worker = workspaces::sandbox().await?;
-let (_, sk) = worker.dev_generate().await;
-let id: AccountId = "contract-id".parse()?;
-let contract = worker
- .create_tla_and_deploy(
- id,
- sk,
- include_bytes!("../examples/res/non_fungible_token.wasm"),
- )
- .await?
- .result;
-```
-
-:::danger
-'dev_deploy' can't supply the initial balance since testnet controls this amount in the helper contract which is what we're using to create dev accounts on testnet. So, to make it simple, we don't supply it at all (sandbox included). It is however possible to create a **subaccount** with a certain balance in sandbox, they can grab the root account and do:
-
-```rust title="Deployment - workspaces-rs (with initial balance)"
-let root = worker.root_acount();
-root.create_subaccount(...)
- .initial_balance(...)
- ...
-```
-
-:::
-
-:::caution
-You might have noticed that `init_simulator` used to accept an optional genesis config. Unfortunately, `workspaces-rs` does not support this feature yet, but we are trying to understand the need for this and properly design it. Please feel free to share your use case [here](https://github.com/near/workspaces-rs/issues/68).
-:::
-
-## Making Transactions and View Calls
-
-As always, let's take a look at how we used to make calls with NEAR Simulator:
-
-```rust title="Calls - near-sdk-sim"
-// Example 1: No Macros
-root.call(
- ft.account_id(),
- "ft_transfer",
- &json!({
- "receiver_id": alice.account_id(),
- "amount": U128::from(transfer_amount)
- })
- .to_string()
- .into_bytes(),
- 300_000_000_000_000,
- 1,
-);
-
-let root_balance: U128 = root.view(
- ft.account_id(),
- "ft_balance_of",
- &json!({
- "account_id": root.account_id()
- })
- .to_string()
- .into_bytes(),
-)
-.unwrap_json();
-
-// Example 2: With Macros
-call!(
- root,
- ft.ft_transfer(alice.account_id(), transfer_amount.into(), None),
- deposit = 1
- gas = 300_000_000_000_000
-);
-
-let root_balance: U128 = view!(ft.ft_balance_of(root.account_id())).unwrap_json();
-```
-
-Note how Example 2's `call!` and `view!` macros accept a contract function invocation as if it was just regular Rust. Unlike NEAR Simulator, `workspaces-rs` never stores metadata about the deployed contract and hence does not support high-level syntax like that. This might change in the future once our ACI implementation is ready, but for the remainder of this section we will be migrating Example 1.
-
-Workspaces have a unified way of making all types of calls via a [builder](https://doc.rust-lang.org/1.0.0/style/ownership/builders.html) pattern. Generally, calls are constructed by following these steps:
-
-1. Create a `CallBuilder` by invoking `Contract::call`
-2. Pass function call arguments via `CallBuilder::args_json` or `CallBuilder::args_borsh` depending on which serialization algorithm your contract is using
-3. Configure gas and deposit (if needed) via `CallBuilder::gas` and `CallBuilder::deposit`
-4. Finalize the call by consuming builder via `CallBuilder::transaction` or `CallBuilder::view` depending on what kind of call you want to make
-
-Reference this migration of Example 1 for migrating your own calls:
-
-```rust title="Calls - workspaces-rs"
-contract
- .call(&worker, "ft_transfer")
- .args_json((alice.id(), transfer_amount, Option::::None))?
- .gas(300_000_000_000_000)
- .deposit(ONE_YOCTO)
- .transact()
- .await?;
-
-let root_balance: U128 = contract
- .call(&worker, "ft_balance_of")
- .args_json((contract.id(),))?
- .view()
- .await?
- .json()?;
-```
-
-:::note
-Note that you have to pass arguments as any serializable type representing a sequential list. Tuples are usually the best candidate due to their heterogeneous nature (remember that you can construct a unary tuple by placing a comma before the closing bracket like this: `(el,)`). Passing in an object formatted with the `json!()` macro is also supported.
-:::
-
-### Batch Transactions
-
-There is a special builder for making batch transactions that can be instantiated by calling `Contract::batch`. Consider the following snippet making a batch transaction consisting of two calls:
-
-```rust title="Batch Transaction - near-sdk-sim"
-let res = root
- .create_transaction(contract.account_id())
- .function_call(
- "ft_transfer_call".to_string(),
- json!({
- "receiver_id": defi_contract.account_id(),
- "amount": transfer_amount.to_string(),
- "msg": "10",
- })
- .to_string()
- .into_bytes(),
- 300_000_000_000_000 / 2,
- 1,
- )
- .function_call(
- "storage_unregister".to_string(),
- json!({
- "force": true
- })
- .to_string()
- .into_bytes(),
- 300_000_000_000_000 / 2,
- 1,
- )
- .submit();
-```
-
-There are no caveats here, the snippet can be straightforwardly mapped into the following:
-
-```rust title="Batch Transaction - workspace-rs"
-let res = contract
- .batch(&worker)
- .call(
- Function::new("ft_transfer_call")
- .args_json((defi_contract.id(), transfer_amount, Option::::None, "10"))?
- .gas(300_000_000_000_000 / 2)
- .deposit(1),
- )
- .call(
- Function::new("storage_unregister")
- .args_json((Some(true),))?
- .gas(300_000_000_000_000 / 2)
- .deposit(1),
- )
- .transact()
- .await?;
-```
-
-## Inspecting Logs
-
-The API for inspecting logs is fairly close to what it was in NEAR Simulator, but there are still some things you should keep in mind when migrating. Let's take the same transaction we used in the [batch transactions](#batch-transactions) section and try to inspect its logs. This is how one would check that the transaction logged a specific message in a certain position with NEAR Simulator:
-
-```rust title="Logs - near-sdk-sim"
-assert_eq!(
- res.logs()[1],
- format!("Closed @{} with {}", contract.account_id(), initial_balance - transfer_amount)
-);
-```
-
-The `workspaces-rs` counterpart might seem almost identical at the first look:
-
-```rust title="Logs - workspaces-rs"
-assert_eq!(
- res.logs()[1],
- format!("Closed @{} with {}", contract.id(), initial_balance.0 - transfer_amount.0)
-);
-```
-
-However, it can actually behave differently depending on your use case, because while near-sdk-sim version only returns the logs from the transaction, the workspaces version returns all logs from both the transaction and receipt outcomes. If you want a literal counterpart, please use `res.outcome().logs`.
-
-Another common use case is examining receipt outcome logs like this:
-
-```rust title="Logs - nead-sdk-sim"
-let outcome = res.get_receipt_results().remove(5).unwrap();
-
-assert_eq!(outcome.logs()[0], "The account of the sender was deleted");
-assert_eq!(
- outcome.logs()[2],
- format!("Account @{} burned {}", root.account_id(), 10)
-);
-```
-
-Which is straightforwardly replaced with:
-
-```rust title="Logs - workspaces-rs"
-let outcome = &res.receipt_outcomes()[5];
-assert_eq!(outcome.logs[0], "The account of the sender was deleted");
-assert_eq!(outcome.logs[2], format!("Account @{} burned {}", contract.id(), 10));
-```
-
-## Profiling Gas
-
-NEAR Simulator never had accurate gas estimations since it only tried to mirror nearcore, but nearcore has extra functionality on top which consumes gas (like cross-contract calls are processed separately from the same transaction and that incurs gas fees). Workspaces offers the better experience here and aligns very well with what you can do on testnet and mainnet. It provides the added benefit of allowing the developer to accurately profile gas usage before deploying to `mainnet`.
-
-:::warning
-Since `workspaces-rs` is now using accurate gas measurements, some testing flows that were previously being tested with sdk-sim that would depend on gas reports might not work anymore. You should do your due diligence if you plan to deploy to `mainnet`.
-:::
-
-Let's once again return to the [batch transactions](#batch-transactions) example and see how we would estimate gas burnt by a given transaction:
-
-```rust title="Gas (transaction) - near-sdk-sim"
-println!("Burnt gas (transaction): {}", res.gas_burnt());
-```
-
-Just like with [inspecting logs](#inspecting-logs), one might mistakenly think that
-
-```rust title="Gas (all) - workspaces-rs"
-println!("Burnt gas (all): {}", res.total_gas_burnt);
-```
-
-is the corresponding `workspaces-rs` snippet, but `CallExecutionDetails::total_gas_burnt` includes all gas burnt by call execution, including by receipts. This is exposed as a surface level API since it is a much more commonly used concept, but if you do actually want gas burnt by transaction itself you can do it like this:
-
-```rust title="Gas (transaction) - workspaces-rs"
-println!("Burnt gas (transaction): {}", res.outcome().gas_burnt);
-```
diff --git a/docs/2.develop/upgrade.md b/docs/2.develop/upgrade.md
index 821a2dec4bb..3dcccac8fb3 100644
--- a/docs/2.develop/upgrade.md
+++ b/docs/2.develop/upgrade.md
@@ -112,7 +112,7 @@ error: `Cannot deserialize the contract state`, in which case you can choose to:
2. Rollback to the previous contract code
3. Add a method to migrate the contract's state
-
+
### The Migration Method
If you have no option but to migrate the state, then you need to implement a method that:
@@ -124,7 +124,7 @@ If you have no option but to migrate the state, then you need to implement a met
This is how DAOs [update themselves](https://github.com/near-daos/sputnik-dao-contract/blob/main/sputnikdao2/src/upgrade.rs#L59)
:::
-
+
### Example: Guest Book Migration
diff --git a/docs/3.tutorials/crosswords/02-beginner/00-overview.md b/docs/3.tutorials/crosswords/02-beginner/00-overview.md
index 76dbbca3897..128c867ed16 100644
--- a/docs/3.tutorials/crosswords/02-beginner/00-overview.md
+++ b/docs/3.tutorials/crosswords/02-beginner/00-overview.md
@@ -15,7 +15,7 @@ Let's give the smart contract the ability to store multiple crosswords and offer
- Art by r3v.near
+ Art by r3v.near
diff --git a/docs/3.tutorials/crosswords/02-beginner/03-actions.md b/docs/3.tutorials/crosswords/02-beginner/03-actions.md
index 8d5fa857099..8d4afc0353f 100644
--- a/docs/3.tutorials/crosswords/02-beginner/03-actions.md
+++ b/docs/3.tutorials/crosswords/02-beginner/03-actions.md
@@ -16,7 +16,7 @@ We're going to introduce a new Action: `Transfer`. In this chapter, we'd like th
- Art by qiqi04.near
+ Art by qiqi04.near
@@ -58,7 +58,7 @@ That's the value in yoctoNEAR. This concept is similar to other blockchains. Bit
- Art by jrbemint.near
+ Art by jrbemint.near
## Adding `Transfer`
@@ -96,7 +96,7 @@ Let's cover three commonly-used functions regarding accounts: predecessor, signe
- Alice sends a transaction to the contract on banana.near, which does a cross-contract call to cucumber.near. From the perspective of a contract on cucumber.near, we see a list of the predecessor, signer, and current account. Art by yasuoarts.near
+ Alice sends a transaction to the contract on banana.near, which does a cross-contract call to cucumber.near. From the perspective of a contract on cucumber.near, we see a list of the predecessor, signer, and current account. Art by yasuoarts.near
1. [predecessor account](https://docs.rs/near-sdk/latest/near_sdk/env/fn.predecessor_account_id.html) — `env::predecessor_account_id()`
diff --git a/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md b/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md
index 86960e3ea50..b5d6e68d255 100644
--- a/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md
+++ b/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md
@@ -54,7 +54,7 @@ Further down in the `submit_solution` method we'll follow our plan by **adding a
- Our smart contract is like this carpenter adding a key to itself. Art by carlcarlkarl.near
+ Our smart contract is like this carpenter adding a key to itself. Art by carlcarlkarl.near
diff --git a/docs/3.tutorials/examples/factory.md b/docs/3.tutorials/examples/factory.md
index fa51815c2e3..9b326aaf469 100644
--- a/docs/3.tutorials/examples/factory.md
+++ b/docs/3.tutorials/examples/factory.md
@@ -46,7 +46,7 @@ The [Generic Factory](https://github.com/near-examples/factory-rust/) presents a
1. Make sure you have installed [rust](https://www.rust-lang.org/).
2. Install the [`NEAR CLI`](https://github.com/near/near-cli#setup)
-
+
### Build and Deploy the Factory
@@ -63,7 +63,7 @@ cat ./neardev/dev-account
# e.g. dev-1659899566943-21539992274727
```
-
+
### Deploy the Stored Contract Into a Sub-Account
@@ -81,7 +81,7 @@ near view sub. get_beneficiary
# expected response is:
```
-
+
### Update the Stored Contract
@@ -108,7 +108,7 @@ near call update_stored_contract "$BYTES" --base64 --accountId
Factories are an interesting concept, here we further explain some of their implementation aspects,
as well as their limitations.
-
+
### Automatically Creating Accounts
@@ -124,7 +124,7 @@ This means that the factory:
It is important to remember that, while `factory.testnet` can create `sub.factory.testnet`, it has
no control over it after its creation.
-
+
### The Update Method
diff --git a/docs/4.tools/cli.md b/docs/4.tools/cli.md
index 6dc83c95202..ea15c040a18 100644
--- a/docs/4.tools/cli.md
+++ b/docs/4.tools/cli.md
@@ -110,7 +110,7 @@ npm install -g near-cli
npm install -g near-cli
```
-
+
heads up
Copy/pasting can be a bit odd using `WSL`.
@@ -520,7 +520,7 @@ near delete-key example-acct.testnet Cxg2wgFYrdLTEkMu6j5D6aEZqTb3kXbmJygS48ZKbo1
- arguments: `accountId` `--masterAccount`
- options: `--initialBalance` `--publicKey` `--newLedgerKey`
-
+
heads up
This command will only allow the creation of [subaccounts](/concepts/basics/accounts/model#subaccounts) of the `--masterAccount`. You can, however, create a [top-level account](/concepts/basics/accounts/model#top-level-accounts) if the length of the account ID is greater than 31 characters. This is most commonly used for [implicit account](/concepts/basics/accounts/model#implicit-accounts) creation.
diff --git a/docs/4.tools/explorer.md b/docs/4.tools/explorer.md
index 14897990dba..3097e2aae07 100644
--- a/docs/4.tools/explorer.md
+++ b/docs/4.tools/explorer.md
@@ -23,7 +23,7 @@ Created by NEAR, the [Near Explorer](https://nearblocks.io) enables to check inf
![NEAR Explorer](/docs/assets/explorers/near-explorer.png)
*Main page of [NEAR Explorer](https://nearblocks.io)*
-
+
## Stats Gallery
Created by the community, [Stats Gallery](https://stats.gallery) gamifies the experience of looking to an account, adding levels and badges based on the account's activity. One of its
@@ -32,7 +32,7 @@ best features is that it allows you to see the contract's methods.
![Stats Gallery](/docs/assets/explorers/stats-gallery.png)
*Account view in [Stats Gallery](https://stats.gallery)*
-
+
## NearBlocks
@@ -41,7 +41,7 @@ Created by the community, [NearBlocks](https://nearblocks.io/) enables to check
![NearBlocks](/docs/assets/explorers/nearblocks.png)
*Main page of [NearBlocks](https://nearblocks.io/)*
-
+
## Nearscope
@@ -50,7 +50,7 @@ Created by the community, [NearBlocks](https://nearblocks.io/) enables to check
![Nearscope](/docs/assets/explorers/nearscope.png)
*Main page of [Nearscope](https://nearscope.net/)*
-
+
## DappLooker
@@ -60,7 +60,7 @@ Created by the community, [NearBlocks](https://nearblocks.io/) enables to check
*Main page of [DappLooker](https://dapplooker.com/)*
-
+
## Pikespeak
diff --git a/docs/4.tools/indexer4explorer.md b/docs/4.tools/indexer4explorer.md
index ddba125baab..9f1d4eb45d1 100644
--- a/docs/4.tools/indexer4explorer.md
+++ b/docs/4.tools/indexer4explorer.md
@@ -39,7 +39,7 @@ where r.receiver_account_id ='v1.faucet.nonofficial.testnet'
and t.transaction_hash = r.originated_from_transaction_hash
```
-
+
### Users, Status, and Attached Money
Query for all users that called `contribute` in `v1.faucet.nonofficial.testnet`, how much they attached to the call, and the transaction status.
@@ -54,7 +54,7 @@ where r.receiver_account_id ='v1.faucet.nonofficial.testnet'
and r.receipt_id = eo.receipt_id
```
-
+
### Sent Money
Query for all the transfers going out from `v1.faucet.nonofficial.testnet`.
diff --git a/docs/4.tools/near-api-js/naj-account.md b/docs/4.tools/near-api-js/naj-account.md
index 158b3c3209b..46f389a73a9 100644
--- a/docs/4.tools/near-api-js/naj-account.md
+++ b/docs/4.tools/near-api-js/naj-account.md
@@ -14,7 +14,7 @@ This will return an Account object for you to interact with.
const account = await nearConnection.account("example-account.testnet");
```
-[ Class `Account`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html)
+[ Class `Account`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html)
### Create Account {#create-account}
@@ -28,7 +28,7 @@ await account.createAccount(
);
```
-[ Method `Account.createAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#createAccount)
+[ Method `Account.createAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#createAccount)
### Delete Account {#delete-account}
@@ -39,7 +39,7 @@ const account = await nearConnection.account("example-account.testnet");
await account.deleteAccount("beneficiary-account.testnet");
```
-[ Method `Account.deleteAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteAccount)
+[ Method `Account.deleteAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteAccount)
### Get Account Balance {#get-account-balance}
@@ -49,7 +49,7 @@ const account = await nearConnection.account("example-account.testnet");
await account.getAccountBalance();
```
-[ Method `Account.getAccountBalance`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountBalance)
+[ Method `Account.getAccountBalance`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountBalance)
### Get Account details {#get-account-details}
@@ -61,7 +61,7 @@ const account = await nearConnection.account("example-account.testnet");
await account.getAccountDetails();
```
-[ Method `Account.getAccountDetails`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountDetails)
+[ Method `Account.getAccountDetails`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountDetails)
### Deploy a Contract {#deploy-a-contract}
@@ -74,9 +74,9 @@ const transactionOutcome = await account.deployContract(
);
```
-[ Method `Account.deployContract`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deployContract)
+[ Method `Account.deployContract`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deployContract)
-[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html)
+[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html)
### Send Tokens {#send-tokens}
@@ -90,9 +90,9 @@ await account.sendMoney(
);
```
-[ Method `Account.sendMoney`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#sendMoney)
+[ Method `Account.sendMoney`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#sendMoney)
-[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html)
+[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html)
### State {#state}
@@ -103,9 +103,9 @@ const account = await nearConnection.account("example-account.testnet");
const accountState = await account.state();
```
-[ Method `Account.state`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#state)
+[ Method `Account.state`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#state)
-[ Interface `AccountView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccountView.html)
+[ Interface `AccountView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccountView.html)
### Access Keys {#access-keys}
@@ -119,7 +119,7 @@ const account = await nearConnection.account("example-account.testnet");
await account.addKey("8hSHprDq2StXwMtNd43wDTXQYsjXcD4MJTXQYsjXcc");
```
-[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey)
+[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey)
#### Add Function Access Key {#add-function-access-key}
@@ -133,7 +133,7 @@ await account.addKey(
);
```
-[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey)
+[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey)
#### Get All Access Keys {#get-all-access-keys}
@@ -142,9 +142,9 @@ const account = await nearConnection.account("example-account.testnet");
await account.getAccessKeys();
```
-[ Method `Account.getAccessKeys`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccessKeys)
+[ Method `Account.getAccessKeys`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccessKeys)
-[ Interface `AccessKeyInfoView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccessKeyInfoView.html)
+[ Interface `AccessKeyInfoView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccessKeyInfoView.html)
#### Delete Access Key {#delete-access-key}
@@ -153,4 +153,4 @@ const account = await nearConnection.account("example-account.testnet");
await account.deleteKey("8hSHprDq2StXwMtNd43wDTXQYsjXcD4MJTXQYsjXcc");
```
-[ Method `Account.deleteKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteKey)
+[ Method `Account.deleteKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteKey)
diff --git a/docs/4.tools/near-api-js/naj-contract.md b/docs/4.tools/near-api-js/naj-contract.md
index 51a62648be1..8ea1fc4f39f 100644
--- a/docs/4.tools/near-api-js/naj-contract.md
+++ b/docs/4.tools/near-api-js/naj-contract.md
@@ -38,7 +38,7 @@ const contract = new Contract(
);
```
-[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html)
+[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html)
@@ -57,7 +57,7 @@ const contract = new Contract(
);
```
-[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html)
+[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html)
@@ -121,7 +121,7 @@ const response = await contract.view_method_name({ arg_name: "arg_value" });
-[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html)
+[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html)
[//]: # "## Transactions {#transactions}"
[//]: # "A [Transaction](/concepts/basics/transactions/overview) is a collection of Actions, and there are few types of Actions."
diff --git a/docs/4.tools/near-api-js/naj-utils.md b/docs/4.tools/near-api-js/naj-utils.md
index 2fe98b17965..e20f3a95177 100644
--- a/docs/4.tools/near-api-js/naj-utils.md
+++ b/docs/4.tools/near-api-js/naj-utils.md
@@ -13,7 +13,7 @@ const { utils } = nearAPI;
const amountInYocto = utils.format.parseNearAmount("1");
```
-[ Function `parseNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.parseNearAmount.html)
+[ Function `parseNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.parseNearAmount.html)
### YoctoNEAR => NEAR {#yoctonear--near}
@@ -24,4 +24,4 @@ const { utils } = nearAPI;
const amountInNEAR = utils.format.formatNearAmount("1000000000000000000000000");
```
-[ Function `formatNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.formatNearAmount.html)
+[ Function `formatNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.formatNearAmount.html)
diff --git a/docs/4.tools/near-api-js/naj-wallet.md b/docs/4.tools/near-api-js/naj-wallet.md
index a7d16c9b3f3..7c15a33574a 100644
--- a/docs/4.tools/near-api-js/naj-wallet.md
+++ b/docs/4.tools/near-api-js/naj-wallet.md
@@ -66,9 +66,9 @@ const walletConnection = new WalletConnection(nearConnection);
-[ Module `browserConnect`](https://near.github.io/near-api-js/modules/near_api_js.browserConnect.html)
+[ Module `browserConnect`](https://near.github.io/near-api-js/modules/near_api_js.browserConnect.html)
-[ Class `WalletConnection`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html)
+[ Class `WalletConnection`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html)
### Ask your user to Sign In {#sign-in}
@@ -90,7 +90,7 @@ walletConnection.requestSignIn({
});
```
-[ Method `WalletConnection.requestSignIn`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#requestSignIn)
+[ Method `WalletConnection.requestSignIn`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#requestSignIn)
:::tip
Sign In is **_not required_** if you are using an alternative key store to local storage, or you are not signing transactions (meaning - you are only calling read-only _view_ methods on a contract)
@@ -103,7 +103,7 @@ Sign In is **_not required_** if you are using an alternative key store to local
walletConnection.signOut();
```
-[ Method `WalletConnection.signOut`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#signOut)
+[ Method `WalletConnection.signOut`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#signOut)
### Check if Signed In {#check-if-signed-in}
@@ -114,7 +114,7 @@ if (walletConnection.isSignedIn()) {
}
```
-[ Method `WalletConnection.isSignedId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#isSignedIn)
+[ Method `WalletConnection.isSignedId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#isSignedIn)
### Get Wallet Account {#get-authorized-account}
@@ -127,7 +127,7 @@ Get the [Account](naj-account.md) your user has signed in with in the Wallet.
const walletAccountId = walletConnection.getAccountId();
```
-[ Method `WalletConnection.getAccountId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#getAccountId)
+[ Method `WalletConnection.getAccountId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#getAccountId)
#### Get Account Object {#get-authorized-account-object}
@@ -136,6 +136,6 @@ const walletAccountId = walletConnection.getAccountId();
const walletAccountObj = walletConnection.account();
```
-[ Method `WalletConnection.account`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#account)
+[ Method `WalletConnection.account`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#account)
-[ Class `ConnectedWalletAccount`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.ConnectedWalletAccount.html)
+[ Class `ConnectedWalletAccount`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.ConnectedWalletAccount.html)
diff --git a/docs/4.tools/near-api-js/quick-reference.md b/docs/4.tools/near-api-js/quick-reference.md
index 1079aff3c70..5e3924928d0 100644
--- a/docs/4.tools/near-api-js/quick-reference.md
+++ b/docs/4.tools/near-api-js/quick-reference.md
@@ -90,7 +90,7 @@ const { keyStores } = nearAPI;
const myKeyStore = new keyStores.BrowserLocalStorageKeyStore();
```
-[ Class `BrowserLocalStorageKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_browser.browser_local_storage_key_store.BrowserLocalStorageKeyStore.html)
+[ Class `BrowserLocalStorageKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_browser.browser_local_storage_key_store.BrowserLocalStorageKeyStore.html)
@@ -107,7 +107,7 @@ const credentialsPath = require("path").join(homedir, CREDENTIALS_DIR);
const myKeyStore = new keyStores.UnencryptedFileSystemKeyStore(credentialsPath);
```
-[ Class `UnencryptedFileSystemKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_node.unencrypted_file_system_keystore.UnencryptedFileSystemKeyStore.html)
+[ Class `UnencryptedFileSystemKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_node.unencrypted_file_system_keystore.UnencryptedFileSystemKeyStore.html)
@@ -134,9 +134,9 @@ myKeyStore.setKey(
);
```
-[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html)
+[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html)
-[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html)
+[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html)
@@ -155,9 +155,9 @@ const keyPair = KeyPair.fromString(PRIVATE_KEY);
await myKeyStore.setKey("testnet", "example-account.testnet", keyPair);
```
-[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html)
+[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html)
-[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html)
+[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html)
@@ -218,4 +218,4 @@ const nearConnection = await connect(connectionConfig);
-[ Module `connect`](https://near.github.io/near-api-js/modules/near_api_js.connect.html)
+[ Module `connect`](https://near.github.io/near-api-js/modules/near_api_js.connect.html)
diff --git a/docs/4.tools/welcome.md b/docs/4.tools/welcome.md
index dd8c55b70b8..bea37b936c5 100644
--- a/docs/4.tools/welcome.md
+++ b/docs/4.tools/welcome.md
@@ -16,6 +16,6 @@ In this page you will find:
5. Developer tools to deploy and interact with contracts such as the [NEAR CLI](cli.md) and [NEAR JavaScript API](/tools/near-api-js/quick-reference).
-
+
diff --git a/docs/5.api/rpc/access-keys.md b/docs/5.api/rpc/access-keys.md
index 63a241885d7..fb26d4b7552 100644
--- a/docs/5.api/rpc/access-keys.md
+++ b/docs/5.api/rpc/access-keys.md
@@ -124,7 +124,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `view_access_key` request type:
-
+
@@ -196,7 +196,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -440,7 +440,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `view_access_key_list` request type:
-
+
@@ -502,7 +502,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -661,7 +661,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes_in_block` method:
-
+
@@ -695,7 +695,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -854,7 +854,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method:
-
+
@@ -888,7 +888,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
diff --git a/docs/5.api/rpc/block-chunk.md b/docs/5.api/rpc/block-chunk.md
index 7853d324dd8..4796e434007 100644
--- a/docs/5.api/rpc/block-chunk.md
+++ b/docs/5.api/rpc/block-chunk.md
@@ -275,7 +275,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `block` method:
-
+
@@ -309,7 +309,7 @@ Here is the exhaustive list of the error variants that can be returned by `block
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -524,7 +524,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes_in_block` method:
-
+
@@ -558,7 +558,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -729,7 +729,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `chunk` method:
-
+
@@ -782,7 +782,7 @@ Here is the exhaustive list of the error variants that can be returned by `chunk
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
diff --git a/docs/5.api/rpc/contracts.md b/docs/5.api/rpc/contracts.md
index f9d908529a6..9cf06c60742 100644
--- a/docs/5.api/rpc/contracts.md
+++ b/docs/5.api/rpc/contracts.md
@@ -115,7 +115,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `view_account` request type:
-
+
@@ -177,7 +177,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -336,7 +336,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method:
-
+
@@ -370,7 +370,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -500,7 +500,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `view_code` request type:
-
+
@@ -572,7 +572,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -892,7 +892,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `view_state` request type:
-
+
@@ -974,7 +974,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -1131,7 +1131,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method:
-
+
@@ -1165,7 +1165,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -1305,7 +1305,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method:
-
+
@@ -1339,7 +1339,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -1530,7 +1530,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `call_function` request type:
-
+
@@ -1611,7 +1611,7 @@ Here is the exhaustive list of the error variants that can be returned by `call_
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
diff --git a/docs/5.api/rpc/introduction.md b/docs/5.api/rpc/introduction.md
index d1b830bc5e9..c5b7b0f613b 100644
--- a/docs/5.api/rpc/introduction.md
+++ b/docs/5.api/rpc/introduction.md
@@ -11,13 +11,13 @@ import ContactUs from '@site/src/components/ContactUs.mdx';
The RPC API allows you to communicate directly with the NEAR network. For example,
tools such as [near-api-js](/tools/near-api-js/quick-reference) are just abstractions making RPC calls.
-
+
## RPC Providers
There are multiple [RPC providers which you can choose from](./providers.md). These providers will work as intermediaries to help you interact with the NEAR network.
-
+
## NEAR RPC - Quick Links
@@ -37,6 +37,6 @@ You can access the JSON RPC 2.0 endpoints using [Postman](/api/rpc/setup#postman
[JavaScript](/api/rpc/setup#javascript-setup), and [HTTPie](/api/rpc/setup#httpie-setup).
:::
-
+
diff --git a/docs/5.api/rpc/maintenance-windows.md b/docs/5.api/rpc/maintenance-windows.md
index 9f228572741..ba1af597404 100644
--- a/docs/5.api/rpc/maintenance-windows.md
+++ b/docs/5.api/rpc/maintenance-windows.md
@@ -101,7 +101,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `maintenance_windows` method:
-
+
diff --git a/docs/5.api/rpc/setup.md b/docs/5.api/rpc/setup.md
index 3b7f049f71c..66c2ffd2cbe 100644
--- a/docs/5.api/rpc/setup.md
+++ b/docs/5.api/rpc/setup.md
@@ -5,7 +5,7 @@ title: Setup
In order to use the RPC API you will need to setup the correct RPC endpoints.
-
+
## RPC Endpoint Setup
- `POST` for all methods
@@ -20,7 +20,7 @@ In order to use the RPC API you will need to setup the correct RPC endpoints.
### Limits
- Maximum number of requests per IP: 600 req/min
-
+
## Querying Historical Data
Querying historical data (older than 5 [epochs](../../1.concepts/basics/epoch.md) or ~2.5 days), you may get responses that the data is not available anymore. In that case, archival RPC nodes will come to your rescue:
diff --git a/docs/5.api/rpc/transactions.md b/docs/5.api/rpc/transactions.md
index 7d1144b7851..14a7fc30747 100644
--- a/docs/5.api/rpc/transactions.md
+++ b/docs/5.api/rpc/transactions.md
@@ -90,7 +90,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `broadcast_tx_async` method:
-
+
@@ -103,7 +103,7 @@ Here is the exhaustive list of the error variants that can be returned by `broad
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -264,7 +264,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `broadcast_tx_commit` method:
-
+
@@ -298,7 +298,7 @@ Here is the exhaustive list of the error variants that can be returned by `broad
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -470,7 +470,7 @@ http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=tx \
-
+
heads up
In the case of function call transactions, this query will not wait for **all** receipts generated by this transaction to finish before returning a result. Rather, it will only wait for its return value to finish before returning; _which could be a promise_.
@@ -528,7 +528,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `tx` method:
-
+
@@ -572,7 +572,7 @@ Here is the exhaustive list of the error variants that can be returned by `tx` m
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
@@ -905,7 +905,7 @@ When API request fails, RPC server returns a structured error response with a li
Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_tx_status` method:
-
+
@@ -949,7 +949,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
-
+
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
diff --git a/docs/6.integrator/errors/introduction.md b/docs/6.integrator/errors/introduction.md
index 2c6c11763e2..439f015c3d3 100644
--- a/docs/6.integrator/errors/introduction.md
+++ b/docs/6.integrator/errors/introduction.md
@@ -4,7 +4,7 @@ title: Introduction
sidebar_label: Introduction
---
-
+
did you know?
The [NEAR Platform overview](/concepts/welcome) clarifies much of the language in this section.
diff --git a/docs/7.primitives/dao.md b/docs/7.primitives/dao.md
index 96528ee5196..9f31210f3ab 100644
--- a/docs/7.primitives/dao.md
+++ b/docs/7.primitives/dao.md
@@ -63,7 +63,7 @@ You can also create a DAO by interacting with the `sputnik-dao` contract.
-
+
### Voting policy
Currently, DAOs support two different types of [voting policies](https://github.com/near-daos/sputnik-dao-contract#voting-policy): `TokenWeight`, and `RoleWeight`.
diff --git a/docs/7.primitives/nft.md b/docs/7.primitives/nft.md
index 7f430a8abcf..e85a3e0bda4 100644
--- a/docs/7.primitives/nft.md
+++ b/docs/7.primitives/nft.md
@@ -95,7 +95,7 @@ See the [metadata standard](https://nomicon.io/Standards/Tokens/NonFungibleToken
Values of gas and deposit might vary depending on which NFT contract you are calling.
:::
-
+
### Minting Collections
Many times people want to create multiple 100 copies of an NFT (this is called a collection). In such cases, what you actually need to do is to mint 100 different NFTs with the same metadata (but different `token-id`).
@@ -104,7 +104,7 @@ Many times people want to create multiple 100 copies of an NFT (this is called a
Notice that [minting in Mintbase](#minting-a-nft) allows you to pass a `num_to_mint` parameter.
:::
-
+
### Royalties
You might have noticed that one of the parameters is a structure called royalties. Royalties enable you to create a list of users that should get paid when the token is sell in a marketplace. For example, if `anna` has `5%` of royalties, each time the NFT is sell, `anna` should get a 5% of the selling price.
@@ -172,7 +172,7 @@ Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the
Optionally, a [`memo` parameter](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core#nft-interface) can be passed to provide more information to your contract.
:::
-
+
### How Does it Work?
Assume you want to attach an NFT (🎫) to a call on the receiver contract. The workflow is as follows:
diff --git a/docs/bos/api/near.md b/docs/bos/api/near.md
index 3f506c2edc0..1160bade5ad 100644
--- a/docs/bos/api/near.md
+++ b/docs/bos/api/near.md
@@ -50,7 +50,7 @@ return `The contract says: ${greeting}`;
Notice that the optional parameter `subscribe` allows users to subscribe to a query, which automatically refreshes the data every 5 seconds.
:::
-
+
#### Avoiding a Common Pitfall
diff --git a/docs/bos/api/social.md b/docs/bos/api/social.md
index 7568852bbfe..67a76cea906 100644
--- a/docs/bos/api/social.md
+++ b/docs/bos/api/social.md
@@ -231,7 +231,7 @@ NEAR Social readily provides an indexer - a service that listen to actions in So
The indexer is very useful, for example, to rapidly store and retrieve information on all comments for a post. Without the indexer, we would need to check all entries in the contract to see who answered, surely running out of GAS before completion.
-
+
### Indexing an Action
To index an action we need to add the `index` key to the data being saved, within the `index` key we will save the `action` being indexed, alongside a `key` and a `value` that identifies this specific instance.
@@ -301,7 +301,7 @@ To index a like, the standard is to save the action `like`, with `{key: object-r
-
+
### Retrieving Indexed Actions
diff --git a/docs/bos/api/state.md b/docs/bos/api/state.md
index 30e363acef8..8a2e9998d7c 100644
--- a/docs/bos/api/state.md
+++ b/docs/bos/api/state.md
@@ -71,7 +71,7 @@ useEffect(() => {
return (
You clicked {count} times
-
+
You clicked more than 5 times
setCount(count + 1)}>Click me
diff --git a/docs/bos/api/web-methods.md b/docs/bos/api/web-methods.md
index fa5419c697a..c5bc3557e69 100644
--- a/docs/bos/api/web-methods.md
+++ b/docs/bos/api/web-methods.md
@@ -31,7 +31,7 @@ return res.body;
-
+
#### Async Version
diff --git a/docs/bos/components.md b/docs/bos/components.md
deleted file mode 100644
index 908fd624403..00000000000
--- a/docs/bos/components.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-id: components
-title: Components
----
-
-import {WidgetEditor} from "@site/src/components/social-widget"
-
-NEAR allows you to create a decentralized frontend by writing and composing small applications known as `Components`.
-
-Components are stored in the NEAR blockchain, and execute locally in a custom Virtual Machine, thus ensuring the component can not access local storage or cookies.
-
----
-
-## Creating a Component
-
-To create a component you simply need to implement a return statement, returning some HTML code.
-
-
-
-```ts
-let greeting = "Have a great day";
-
-return (
- <>
-
- >
-);
-```
-
-
-
----
-
-## VM context
-
-You can access the `context` object to get specific information about the VM instance.
-
-### `networkId`
-
-You can detect the current network (`mainnet` or `testnet`) using `context.networkId`. For example:
-
-```js
-const childSrc =
- context.networkId === "mainnet"
- ? "near/src/Foobar"
- : "preview.testnet/src/Foobar";
-
-return (
-
-
A child dependency:
-
-
-);
-```
-
-### `accountId`
-
-You can get the current signed-in user account (e.g., `user.near`) using `context.accountId`. For example:
-
-```js
-let user_account = context.accountId;
-
-return (
- <>
-
-
Hello
-
{user_account}
-
- >
-);
-```
-
-
----
-
-## Props: Receiving Input
-
-Components can take arbitrary input, which will be reflected in the `props` variable. In the example below, we are passing as input `name="Anna"`.
-
-
-
-```ts
-let name = props.name || "User";
-let greeting = "Have a great day";
-
-return (
- <>
-
-
Hello {name}
-
{greeting}
-
- >
-);
-```
-
-
-
----
-
-## State: Storing Information
-
-Components have an internal state were they can store information.
-
-
-
-```ts
-State.init({greeting: "Have a great day"});
-
-const onChange = ({target}) => { State.update({greeting: target.value}) };
-
-return (
- <>
-
-
Greeting: {state.greeting}
-
-
Change the Greeting
-
-
- >
-);
-```
-
-
-
----
-
-## Composing Components
-
-To compose components you will use the [Predefined `Widget` component](./api/builtin-components.md#widget). For this, you only need the NEAR username of who created the component, and the component's name.
-
-
-
-```ts
-const user = "gagdiez.near";
-const props = { name: "Anna" };
-
-return (
- <>
-
-
-
Components can be composed
-
-
-
-
- >
-);
-```
-
-
\ No newline at end of file
diff --git a/docs/bos/index.md b/docs/bos/index.md
deleted file mode 100644
index ec87c569bd6..00000000000
--- a/docs/bos/index.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: welcome
-title: Composable Multi-Chain Apps
-sidebar_label: Home
-hide_table_of_contents: true
----
-
-import {FeatureList, Column, Feature} from "@site/src/components/featurelist"
-import ContactUs from '@site/src/components/ContactUs.mdx';
-
-Build fully decentralized applications for all chains. Publish and get discovered by thousands of users. Embrace the power of community and web 3.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
----
-
-
diff --git a/docs/bos/overview.md b/docs/bos/overview.md
index bd52bdfda1c..e1a8d28bbe7 100644
--- a/docs/bos/overview.md
+++ b/docs/bos/overview.md
@@ -30,19 +30,19 @@ Additionally, NEAR Components are chain-agnostic, making it a flexible solution
## The Pillars of NEAR Stack
The NEAR stack is based on three pillars:
-- [Components](#components): Composable frontends that solve specific problems.
+- Components: Composable frontends that solve specific problems.
- [Blockchains](#blockchains): To store the component's code, as well as their assets and data.
- [Gateways](#gateways): A simple way to render components anywhere.
-
+
### Components
-[Components](./components.md) are small web 3 applications (think [Lido](tutorial/hello-lido.md), Uniswap, Aave) that are stored **entirely on-chain**.
+Components are small web 3 applications (think [Lido](tutorial/hello-lido.md), Uniswap, Aave) that are stored **entirely on-chain**.
-Developers can fork these apps and [compose them](./components.md#composing-components) to create full web applications.
+Developers can fork these apps and compose them to create full web applications.
-
+
### Blockchains
@@ -50,7 +50,7 @@ Components can call functions on any blockchain, with current support for all EV
The source code for the apps is on NEAR, due to it's ability to very cheaply store HTML/CSS/JS (a few cents).
-
+
### Gateways
diff --git a/docs/bos/tutorial/hello-lido.md b/docs/bos/tutorial/hello-lido.md
index 17d0773974d..ace4c376e1a 100644
--- a/docs/bos/tutorial/hello-lido.md
+++ b/docs/bos/tutorial/hello-lido.md
@@ -212,67 +212,67 @@ const getSender = () => {
return (
-
-
-
+
+
Stake Ether
+
Stake ETH and receive stETH while staking.
-