Add high-level overview from NEPs

docs/primitives/ft.md

@@ -22,7 +22,25 @@ In contrast with the NEAR native token, fungible token (FT) are **not stored** i
 
 ![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.
+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). The **NEP-141** & **NEP-148** standards explain the **minimum interface** required to be implemented, as well as the expected functionality.
+
+---
+
+## About the FT Standard
+
+[NEP-141](https://github.com/near/NEPs/tree/master/neps/nep-0141.md) is the blueprint for all community-created fungible tokens (like stablecoins, governance tokens, etc.) on NEAR. It defines a common set of rules and function calls that allow wallets, exchanges, and decentralized applications (dApps) to interact with any NEP-141 compliant token in a predictable way.
+
+A key concept in NEP-141 is the use of a **receiver pattern** for transfers. This pattern prevents tokens from being stuck in a contract that doesn't know how to handle them.
+
+Instead of a simple _`transfer(to, amount)`_ call that only involves two parties, the pattern introduces a three-step process for more secure and flexible interactions:
+
+- `ft_transfer(receiver_id, amount, memo)`: The standard function to send tokens to another account.
+
+- `ft_transfer_call(receiver_id, amount, memo, msg)`: This is the most important function. It not only transfers tokens but also calls a method on the `receiver_id`'s contract in a single, atomic transaction. This is essential for DeFi and dApps.
+
+- `ft_on_transfer(sender_id, amount, msg)`: A callback function that the receiver contract must implement if it wants to receive tokens via `ft_transfer_call`. This allows the receiving contract to execute logic upon receiving the tokens (e.g., automatically swapping them, depositing them into a liquidity pool, or minting an NFT).
+
+NEP-141's focus on cross-contract calls make it inherently more powerful for a decentralized application ecosystem than a simple _transfer-only_ standard, enabling the complex, interconnected DeFi and dApp experiences that you want to build on a blockchain.
 
 ---
 
@@ -44,7 +62,7 @@ We have created a simple UI to interact with the existing `tkn.primitives.testne
 
 <summary> 2. Interacting with a pre-deployed Token Factory smart contract </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">
@@ -426,7 +444,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,10 +527,10 @@ 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.
 
 ---
@@ -575,7 +593,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/linkdrop.md

@@ -27,6 +27,22 @@ The simplest way to create a linkdrop is by interacting with our [LinkDrop Gener
 
 ---
 
+## About the Linkdrop Standard
+
+[NEP-0452](https://github.com/near/NEPs/blob/master/neps/nep-0452.md) standardizes a secure and flexible method for creating linkdrops on NEAR. A linkdrop is a mechanism where a sender can fund a special, one-time-use account (or `key`) and generate a unique link. Anyone who possesses this link can then claim the assets (like NEAR tokens or NFTs) locked within it, often without needing an existing NEAR account.
+
+The specification keeps the linkdrop logic in a smart contract and introduces a secure key type:
+
+- Separation of Concerns: The standard clearly separates the roles of the **Sender** (who funds the linkdrop), the **Claimer** (who redeems it), and the **Contract** (which holds the logic and assets).
+
+- Function Call Keys: Instead of a full-access key, a linkdrop is secured by a [Function Call Access Key](../protocol/access-keys.md#function-call-keys). This key is only permitted to call a single, specific method on the smart contract (e.g., `claim`). Even if the private key is exposed, an attacker cannot do anything else with it.
+
+- Smart Contract Driven: The entire claiming process is managed by a smart contract. This allows for immense flexibility, enabling linkdrops to contain not just NEAR tokens, but also [NFTs](nft.md), [FTs (Fungible Tokens)](ft.md), or any other on-chain asset.
+
+The NEP-0452 standard defines linkdrop implementation by leveraging smart contracts and Function Call Keys, opening up a wide range of possibilities for developers while prioritizing security and a seamless user experience.
+
+---
+
 ## AccessKeys
 
 In order to create any kind of drop, you need to first generate key pairs. You will need to create **one key per drop**.

docs/primitives/nft.md

@@ -20,7 +20,7 @@ In contrast with fungible tokens, non-fungible tokens (NFT) are unitary and ther
 
 As with fungible tokens, NFTs are **not stored** in the user's wallet, instead, each NFT lives in a **NFT contract**. The NFT contract works as a bookkeeper, this is: it is in charge of handling the creation, storage and transfers of NFTs.
 
-In order for a contract to be considered a NFT-contract it has to follow the [**NEP-171 and NEP-177 standards**](https://github.com/near/NEPs/tree/master/neps/nep-0171.md). The **NEP-171** & **NEP-177** standards explain the **minimum interface** required to be implemented, as well as the expected functionality.
+In order for a contract to be considered a NFT-contract it has to follow the [**NEP-171**](https://github.com/near/NEPs/tree/master/neps/nep-0171.md) and [**NEP-177 standards**](https://github.com/near/NEPs/tree/master/neps/nep-0177.md). The **NEP-171** & **NEP-177** standards explain the **minimum interface** required to be implemented, as well as the expected functionality.
 
 :::info NFT & Marketplaces
 
@@ -30,6 +30,28 @@ Be mindful of not confusing an NFT with an NFT-marketplace. NFT simply store inf
 
 ---
 
+## About the NFT Standard
+
+[NEP-171](https://github.com/near/NEPs/tree/master/neps/nep-0171.md) is the foundational standard for Non-Fungible Tokens (NFTs) on the NEAR blockchain. It defines a common set of rules that all NFT contracts must follow, ensuring interoperability, predictability, and a consistent experience for users, wallets, and marketplaces.
+
+The core philosophy of NEP-171 is simplicity and gas efficiency (the cost of viewing or querying data is free). It provides a minimal, event-driven skeleton, leaving more complex logic (like sale mechanics or detailed metadata) to other complementary standards.
+
+Due to its minimalist design, the NEP-171 standard only mandates three core functionalities:
+
+- `nft_transfer`: Transfer an NFT to a new owner.
+
+- `nft_token`: The primary view method to query all information about a specific token (its ID, owner, and approved accounts).
+
+- [Events](https://github.com/near/NEPs/blob/master/neps/nep-0171.md#events): The contract must emit standardized events for all transfers and approvals. This allows indexers and applications to reliably track NFT activity without scanning every transaction.
+
+Everything else—like minting, burning, enumeration (listing all tokens), and rich metadata—is defined in separate, complementary standards:
+
+- [Metadata Standard](https://github.com/near/NEPs/tree/master/neps/nep-0177.md): Defines how to attach metadata (name, description, image, etc.) to the contract and individual tokens.
+- [Approval Management Standard](https://github.com/near/NEPs/blob/master/neps/nep-0178.md): Standardizes the mechanism that allows a token owner to grant permission to another account (or a contract) to transfer a specific token on their behalf. This is essential for listing NFTs on a marketplace..
+- [Enumeration Standard](https://github.com/near/NEPs/tree/master/neps/nep-0181.md): Provides methods to list all tokens, tokens by owner, etc., without which the NFTs would be unlistable.
+
+---
+
 ## Deploying a NFT Contract
 
 If you want to deploy your own NFT contract, you can create one using our [reference implementation](https://github.com/near-examples/NFT).

docs/tutorials/examples/near-drop.md

@@ -17,7 +17,7 @@ Particularly, it shows:
 
 :::tip
 
-This example showcases a simplified version of the contract that both [Keypom](https://keypom.xyz/) and the [Token Drop Utility](https://dev.near.org/tools?tab=linkdrops) use to distribute tokens to users
+This example showcases a simplified version of the contract that both [Keypom](https://github.com/keypom/keypom) and the [Token Drop Utility](https://dev.near.org/tools?tab=linkdrops) use to distribute tokens to users
 
 :::
 
@@ -65,7 +65,7 @@ Creates the `account_id`, and then drops the tokens into it
 
 ## Contract's State
 
-We can see in the contract's state that the contract keeps track of different `PublicKeys`, and links them to a specific `DropId`, which is simply an identifier for a `Drop` (see below). 
+We can see in the contract's state that the contract keeps track of different `PublicKeys`, and links them to a specific `DropId`, which is simply an identifier for a `Drop` (see below).
 
 - `top_level_account`: The account that will be used to create new accounts, generally it will be `testnet` or `mainnet`
 - `next_drop_id`: A simple counter used to assign unique identifiers to each drop