Add high-level overview from NEPs

docs/chain-abstraction/omnibridge/how-it-works.md

@@ -23,7 +23,7 @@ Before exploring how Chain Signatures solves these issues, it's important to und
 
 When a token transfer happens on NEAR using `ft_transfer_call`, the token contract first transfers the tokens and then automatically calls the specified `ft_on_transfer` method on the receiver contract. While these operations happen in sequence within the same transaction, the receiver contract has the ability to reject the transfer, causing the tokens to be refunded. This atomic behavior ensures the integrity and safety of bridge operations by preventing partial execution states.
 
-For more information see [Fungible Tokens](../../primitives/ft.md).
+For more information see [Fungible Tokens](../../primitives/ft/ft.md).
 
 ## Enter Chain Signatures
 

docs/primitives/dao.md

@@ -2,7 +2,6 @@
 id: dao
 title: Decentralized Autonomous Organizations
 sidebar_label: Autonomous Organizations (DAO)
-hide_table_of_contents: false
 description: "Learn about Decentralized Autonomous Organizations (DAOs) on NEAR - self-organized groups that coordinate membership, decision-making, and funding through smart contract voting."
 ---
 
@@ -18,7 +17,7 @@ Decentralized Autonomous Organizations (DAOs) are self-organized groups that for
 
 ![dao](/assets/docs/primitives/dao.png)
 
-In contrast with [FT](ft.md) and [NFT](nft.md), DAO contract's are not standardized. Because of this, on this page we will use as
+In contrast with [FT](./ft/ft.md) and [NFT](./nft/nft.md), DAO contract's are not standardized. Because of this, on this page we will use as
 reference the [Astra dao](https://dev.near.org/astraplusplus.ndctools.near/widget/home?page=daos) [contract](https://github.com/near-daos/sputnik-dao-contract). The main concepts covered here should
 easily generalizable to other DAO implementations.
 
@@ -176,7 +175,7 @@ Deploying by **hash** creates an immutable contract that never changes. Deployin
 ### Voting policy
 Currently, DAOs support two different types of [voting policies](https://github.com/near-daos/sputnik-dao-contract#voting-policy): `TokenWeight`, and `RoleWeight`.
 
-When the vote policy is `TokenWeight`, the council votes using [tokens](ft.md). The weigh of a vote is the proportion of tokens used for voting over the token's total supply.
+When the vote policy is `TokenWeight`, the council votes using [tokens](./ft/ft.md). The weigh of a vote is the proportion of tokens used for voting over the token's total supply.
 
 When the vote policy is `RoleWeight(role)`, the vote weigh is computed as "one over the total number of people with the role".
 

docs/primitives/dex.md

@@ -1,7 +1,6 @@
 ---
 id: dex
 title: Decentralized Exchanges (DEX)
-hide_table_of_contents: false
 description: "Learn how to interact with decentralized exchanges on NEAR Protocol, including token swapping, liquidity pools, and integration with Ref Finance DEX."
 ---
 

docs/primitives/didnear.md

@@ -1,7 +1,6 @@
 ---
 id: did
 title: Decentralized Identifiers (DIDs)
-hide_table_of_contents: false
 description: "Learn about W3C-compliant identity resolution on NEAR." 
 ---
 

docs/primitives/ft.md → docs/primitives/ft/ft.md

@@ -1,8 +1,7 @@
 ---
 id: ft
-title: Fungible Tokens (FT)
-hide_table_of_contents: false
-description: "Learn about NEAR fungible tokens (FT) following NEP-141 and NEP-148 standards - create, transfer, and integrate FT contracts with comprehensive examples and tools."
+title: Using FTs
+description: "Learn how to create, transfer, and integrate FT in your dApp"
 ---
 
 import {FeatureList, Column, Feature} from "@site/src/components/featurelist"
@@ -15,36 +14,24 @@ import { TryOutOnLantstool } from "@site/src/components/lantstool/TryOutOnLantst
 
 import CreateTokenForm from "@site/src/components/tools/FungibleToken/CreateTokenForm";
 
-
-Besides the native NEAR token, NEAR accounts have access to a [multitude of tokens](https://guide.rhea.finance/developers-1/cli-trading#query-whitelisted-tokens) to use throughout the ecosystem. Moreover, it is even possible for users to create their own fungible tokens.
-
-In contrast with the NEAR native token, fungible token (FT) are **not stored** in the user's account. In fact, each FT lives in **their own contract** which is in charge of doing **bookkeeping**. This is, the contract keeps track of how many tokens each user has, and handles transfers internally.
-
-![FT](/assets/docs/primitives/ft.png)
-
-In order for a contract to be considered a FT-contract it has to follow the [**NEP-141 and NEP-148 standards**](https://github.com/near/NEPs/tree/master/neps/nep-0141.md). The **NEP-141** & **NEP-148** standards explain the **minimum interface** required to be implemented, as well as the expected functionality.
+Wanting to use Fungible Tokens (FT) in your dApp? Here you will find all the information you need to get started creating your own tokens, registering users
+, querying balances, transferring tokens, and integrating them into your smart contracts.
 
 ---
 
 ## Creating a New Token
 
-The simplest way to create a new Fungible Token is by using a factory contract, to which you only need to provide the token metadata, and they will automatically deploy and initialize a [canonical FT contract](https://github.com/near-examples/FT).
+The simplest way to create a new Fungible Token is by interacting with a factory contract, to which you only need to provide the token metadata, and they will automatically deploy and initialize a [canonical FT contract](https://github.com/near-examples/FT).
 
-<details>
-
-<summary> 1. Using the Token Factory Tool </summary>
-
-We have created a simple UI to interact with the existing `tkn.primitives.testnet` factory contract
+Here you can make a call to the `token.primitives.testnet` by filling out the form below:
 
 <CreateTokenForm />
 
-</details>
-
 <details>
 
-<summary> 2. Interacting with a pre-deployed Token Factory smart contract </summary>
+<summary> Manual Interaction </summary>
 
-Here is how to directly interact with the factory contract through your application: 
+Here is how to directly interact with the factory contract through your application:
 
 <Tabs groupId="code-tabs">
   <TabItem value="🌐 WebApp" label="🌐 WebApp">
@@ -72,9 +59,9 @@ Here is how to directly interact with the factory contract through your applicat
     await wallet.callMethod({
       method: 'create_token',
       args,
-      contractId: 'tkn.primitives.near',
+      contractId: 'token.primitives.near',
       gas: 300000000000000,
-      deposit: '2234830000000000000000000',
+      deposit: '2234830000000000000000',
     });
     ```
 
@@ -84,15 +71,15 @@ Here is how to directly interact with the factory contract through your applicat
   <TabItem value="🖥️ CLI" label="🖥️ CLI">
 
     ```bash
-    near call tkn.primitives.near create_token '{"args":{"owner_id": "bob.near","total_supply": "1000000000","metadata":{"spec": "ft-1.0.0","name": "Test Token","symbol": "TTTEST","icon": "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7","decimals": 18}},"account_id": "bob.near"}' --gas 300000000000000 --depositYocto 2234830000000000000000000 --accountId bob.near
+    near call token.primitives.near create_token '{"args":{"owner_id": "bob.near","total_supply": "1000000000","metadata":{"spec": "ft-1.0.0","name": "Test Token","symbol": "TTTEST","icon": "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7","decimals": 18}},"account_id": "bob.near"}' --gas 300000000000000 --depositYocto 2234830000000000000000000 --accountId bob.near
     ```
   </TabItem>
   <TabItem value="Lantstool" label={<LantstoolLabel />}>
     <TryOutOnLantstool path="docs/2.build/5.primitives/ft/create-ft-via-factory.json" />
   </TabItem>
 </Tabs>
 
-The FT you create will live in the account `<your_token_symbol>.tkn.primitives.near` (e.g. `test.tkn.primitives.near`).
+The FT you create will live in the account `<your_token_symbol>.token.primitives.near` (e.g. `test.token.primitives.near`).
 
 </details>
 
@@ -138,7 +125,7 @@ To initialize a FT contract you will need to deploy it and then call the `new` m
 
 ### Global Contracts
 
-You can deploy a new Fungible Token using our global FT contract - a pre-deployed [standard FT contract](https://github.com/near-examples/FT) that you can reuse. [Global contracts](../smart-contracts/global-contracts.md) are deployed once and can be reused by any account without incurring high storage costs.
+You can deploy a new Fungible Token using our global FT contract - a pre-deployed [standard FT contract](https://github.com/near-examples/FT) that you can reuse. [Global contracts](../../smart-contracts/global-contracts.md) are deployed once and can be reused by any account without incurring high storage costs.
 
 <Tabs groupId="code-tabs">
   <TabItem value="account" label="By Account">
@@ -426,7 +413,7 @@ To send FT to another account you will use the `ft_transfer` method, indicating
 ## Attaching FTs to a Call
 Natively, only NEAR tokens (Ⓝ) can be attached to a function 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 function call in your name.
 
-Let's assume that you need to deposit FTs on Ref Finance.
+Let's assume that you need to deposit FTs on [Ref Finance](https://rhea.finance/).
 
 <Tabs groupId="code-tabs">
   <TabItem value="🌐 WebApp" label="🌐 WebApp">
@@ -509,15 +496,15 @@ Let's assume that you need to deposit FTs on Ref Finance.
 
 How it works:
 
-1. You call ft_transfer_call in the FT contract passing: the receiver, a message, and the amount.
+1. You call `ft_transfer_call` in the FT contract passing: the receiver, a message, and the amount.
 2. The FT contract transfers the amount to the receiver.
-3. The FT contract calls receiver.ft_on_transfer(sender, msg, amount)
-4. The FT contract handles errors in the ft_resolve_transfer callback.
+3. The FT contract calls `receiver.ft_on_transfer(sender, msg, amount)`
+4. The FT contract handles errors in the `ft_resolve_transfer` callback.
 5. The FT contract returns you how much of the attached amount was actually used.
 
 ---
 
-## Handling Deposits (Contract Only)
+## Handling Deposits
 
 If you want your contract to handle deposit in FTs you have to implement the `ft_on_transfer` method. When executed, such method will know:
 
@@ -575,7 +562,8 @@ impl FungibleTokenReceiver for Contract {
 
 ## Additional Resources
 
-1. [NEP-141 and NEP-148 standards](https://github.com/near/NEPs/tree/master/neps/nep-0141.md)
-2. [FT Event Standards](https://github.com/near/NEPs/blob/master/neps/nep-0300.md)
-3. [FT reference implementation](https://github.com/near-examples/FT)
-4. [Fungible Tokens 101](../tutorials/fts/0-intro.md) - a set of tutorials that cover how to create a FT contract using Rust.
+1. [NEP-141 standard](https://github.com/near/NEPs/tree/master/neps/nep-0141.md)
+2. [NEP-148 standard](https://github.com/near/NEPs/tree/master/neps/nep-0148.md)
+3. [FT Event Standards](https://github.com/near/NEPs/blob/master/neps/nep-0300.md)
+4. [FT reference implementation](https://github.com/near-examples/FT)
+5. [Fungible Tokens 101](../../tutorials/fts/0-intro.md) - a set of tutorials that cover how to create a FT contract using Rust.

docs/primitives/ft/standard.md

@@ -0,0 +1,186 @@
+---
+id: standard
+title: The Standard
+description: "Learn how Fungible Tokens (FT) are defined on NEAR"
+---
+
+Besides the native NEAR token, users have access to a multitude of tokens created by institutions and other users known as fungible tokens.
+
+In contrast with the native token, fungible token (FT) are **not stored** in the user's account, but rather in a smart contract. Such contract is in charge of doing **bookkeeping**, i.e. to track how many tokens each user has, and to handle transfers internally.
+
+![FT](/assets/docs/primitives/ft.png)
+
+In order for a contract to be considered a FT contract it has to follow the [**NEP-141**](https://github.com/near/NEPs/tree/master/neps/nep-0141.md) and [**NEP-148 standards**](https://github.com/near/NEPs/tree/master/neps/nep-0148.md)which define the **minimum interface** required to be implemented, as well as the expected functionality.
+
+---
+
+## NEP-141 (Fungible Token Interface)
+
+[NEP-141](https://github.com/near/NEPs/tree/master/neps/nep-0141.md) is the blueprint for all fungible tokens (e.g. stablecoins, governance tokens, etc.) on NEAR.
+
+It defines a **common set of rules** and **functions** that the contract MUST implement to be considered a fungible token contract.
+
+:::tip
+
+Notice that the NEP-141 defines the **interface** and **expected behavior** of a fungible token contract, but it does not dictate how the internal logic should be implemented
+
+Different FT contracts can have different internal implementations while still adhering to the NEP-141 standard
+
+:::
+
+<hr class="subsection" />
+
+### Interface
+
+#### `ft_total_supply` (*read-only*)
+
+Returns the total supply of the token
+
+```ts
+ft_total_supply(): string
+```
+
+<br />
+
+#### `ft_balance_of` (*read-only*)
+
+Returns the balance of a given account
+
+```ts
+ft_balance_of(account_id: string): string
+```
+
+<br />
+
+#### `ft_transfer`
+
+Transfers `amount` of tokens from the account calling the function to a `receiver_id`, optionally the function can include a `memo` field to provide additional information to the contract
+
+> *Requirement: The caller must attach [exactly 1 yoctoNEAR](../../smart-contracts/security/one_yocto.md) to the call*
+
+```ts
+ft_transfer(receiver_id: string, amount: string, memo: string?): void
+```
+
+<br />
+
+#### `ft_transfer_call`
+
+The function transfers `amount` of tokens to the `receiver_id` **and calls the method `ft_on_transfer(sender_id, amount, msg)`** on `receiver_id`.
+
+Optionally the function can include a `memo` for the FT contract, and a `msg` field to which will be sent to the receiver contract.
+
+> 📖 This function is useful to transfer tokens to a contract and trigger some action on the receiver side in a single transaction, thus acting as **attaching fungible tokens to a function call**.
+
+> *Requirement: The caller must attach [exactly 1 yoctoNEAR](../../smart-contracts/security/one_yocto.md) to the call*
+
+```ts
+ft_transfer_call(receiver_id: string, amount: string, memo: string?, msg: string): void
+```
+
+<details>
+
+    <summary> ft_on_transfer </summary>
+
+    Smart contracts expecting to **receive** Fungible Tokens **must** implement this method.
+
+    The method **must** return the amount of tokens that were **NOT used** by the receiver, so that the **sender can be refunded**.
+
+    ```ts
+    ft_on_transfer(sender_id: string, amount: string, msg: string): string
+    ```
+
+    ⚠️ Note that this method does not need to be implemented by the FT contract itself, but rather by any contract that expects to receive fungible tokens
+
+</details>
+
+<br />
+
+#### `ft_resolve_transfer`
+
+This method is used as a [callback](../../smart-contracts/anatomy/crosscontract.md#callback-function) to resolve the `ft_transfer_call` transaction, handling refunds if necessary.
+
+```js
+ft_resolve_transfer(sender_id: string, receiver_id: string, amount: string): string
+```
+
+---
+
+## NEP-145 (Storage Management)
+
+On NEAR, accounts need to pay for the storage they use on the network. As more users hold tokens on a fungible token contract, more information needs to be stored, and thus the contract needs to reserve more storage.
+
+[NEP-145](https://github.com/near/NEPs/blob/master/neps/nep-0145.md) is a standard that defines a common interface for registering users, allowing FT contracts to **charge users for the storage they use**.
+
+:::tip
+
+While not mandatory, it is highly recommended for FT contracts to implement the NEP-145 standard to avoid running out of storage
+
+:::
+
+<hr class="subsection" />
+
+### Interface
+
+#### `storage_balance_bounds` (*read-only*)
+Returns the minimum and maximum storage balance required for an account to be registered with the contract
+
+```ts
+storage_balance_bounds(): { min: string, max?: string} | null
+```
+
+#### `storage_balance_of` (*read-only*)
+Returns the storage balance of a given account, or `null` if the account is not registered
+
+```ts
+storage_balance_of(account_id: string): { total: string, available: string } | null
+```
+
+#### `storage_unregister`
+Removes all information from an account from the contract, returning the storage deposit to the user. The function can only be called by the user themselves.
+
+```ts
+storage_unregister(force?: boolean): boolean
+```
+
+#### `storage_deposit`
+Registers an account with the contract, reserving enough storage to keep track of the user's balance. The function can be called by the user themselves **or by a third party** on behalf of the user.
+
+```ts
+storage_deposit(account_id?: string, registration_only?: boolean): { total: string, available: string }
+```
+
+#### `storage_withdraw`
+Unregisters an account from the contract, returning the storage deposit to the user. The function can only be called by the user themselves.
+
+```ts
+storage_withdraw(amount: string): { total: string, available: string }
+```
+
+
+
+---
+
+## NEP-148 (Token Metadata)
+
+[NEP-148](https://github.com/near/NEPs/tree/master/neps/nep-0141.md) is an extension to the NEP-141 standard that defines the fungible tokens **metadata**.
+
+Metadata provides **key information** about the token, such as its **name, symbol, and decimal precision**, particularly, the following fields MUST be included in the token's metadata:
+
+- `spec`: a string. Should be `ft-1.0.0` to indicate that a Fungible Token contract adheres to the current versions of this Metadata and the [Fungible Token Core][FT Core] specs
+- `name`: the human-readable name of the token
+- `symbol`: the abbreviation, like wETH or AMPL
+- `decimals`: used in frontends to show the proper significant digits of a token
+
+The metadata is useful for wallets and other user interfaces to display the token correctly, for example if a token is defined as:
+
+```json
+{
+  "spec": "ft-1.0.0",
+  "name": "My Awesome Token",
+  "symbol": "MAT",
+  "decimals": 4
+}
+```
+
+A balance of `123456` units of such token should be displayed in a user interface as `12.3456 MAT`.

docs/primitives/linkdrop.md → docs/primitives/linkdrop/linkdrop.md

@@ -1,7 +1,6 @@
 ---
 id: linkdrop
-title: Linkdrops
-hide_table_of_contents: false
+title: Using Linkdrops
 description: "Learn about linkdrops following NEP-452 standard - distribute assets and onboard users to Web3 apps through simple web links using access keys and the Keypom platform."
 ---
 import {FeatureList, Column, Feature} from "@site/src/components/featurelist"
@@ -11,13 +10,7 @@ import { Github } from "@site/src/components/UI/Codetabs"
 import { LantstoolLabel } from "@site/src/components/lantstool/LantstoolLabel/LantstoolLabel";
 import { TryOutOnLantstool } from "@site/src/components/lantstool/TryOutOnLantstool";
 
-Linkdrops allow users to distribute assets and onboard people to Web3 apps through a simple web link.
-
-![Linkdrop](/assets/docs/primitives/linkdrop.png)
-
-They work by storing assets and linking [AccessKeys](../protocol/access-keys.md) to them. The `AccessKeys` are then distributed to users in the form of web links. These links take users to a website that automatically uses the keys to call the `claim` method in the `linkdrop` contract.
-
-In order for a contract to be considered a Linkdrop-contract it has to follow the [**NEP-452 standard**](https://github.com/near/NEPs/blob/master/neps/nep-0452.md). The **NEP-452** explains the **minimum interface** required to be implemented, as well as the expected functionality.
+Wanting to use Linkdrops in your dApp? Here you will find all the information you need to get started.
 
 :::tip