[Docs]: Update Asset and State sections

docs/architecture/accounts.md

@@ -1,6 +1,6 @@
-# Accounts
+# Account
 
-> The primary entities of the Miden protocol
+> The primary entity of the Miden protocol
 
 ## What is the purpose of an account?
 
@@ -120,10 +120,4 @@ The storage mode is chosen during account creation, it cannot be changed later.
 
 ## Conclusion
 
-In this section, we covered:
-
-- [What is an `Account`](#what-is-an-account)  
-- [Its constituent components](#the-accounts-core-components)  
-- [Its lifecycle](#the-accounts-lifecycle)
-
-With this information, you are now better equipped to understand how Miden `Accounts` operate, how they manage data and assets, and how their programmable functions enable secure and flexible interactions within the Miden protocol.
+You are now better equipped to understand how a Miden `Account` operates, how it manages data and assets, and how its programmable interface enables secure and flexible interactions within the Miden protocol.

docs/architecture/assets.md

@@ -1,58 +1,78 @@
-In Miden, users can create and trade arbitrary fungible and non-fungible assets.
+# Asset
 
-We differentiate between native and non-native assets in Miden. Native assets follow the Miden asset model. Non-native assets are all other data structures of value that can be exchanged.
+> Fungible, Non-fungible, Native, and Non-native assets in the Miden protocol.
 
-Native assets in Polygon Miden have four goals:
+## What is the purpose of an asset?
 
-* Asset exchange should be parallelizable.
-* Asset ownership should be self-sovereign.
-* Asset usage should be censorship resistant.
-* Fees can be paid using any asset.
+In Miden, assets serve as the primary means of expressing and transferring value between [accounts](accounts.md) through [notes](notes.md). They are designed with four key principles in mind:
 
-All native assets in Miden are stored directly in accounts, like Ether in Ethereum. Miden does not track asset ownership using global hashmaps, e.g., ERC20 contracts. Local asset storage in accounts provides privacy and the ability for client-side proofs. That is because ownership changes are reflected only on an account and not in an ERC20 account (global hashmap). Thus, these changes can happen in parallel. Additionally, asset exchange is censorship resistant at this level because there is no global contract the transfer must pass through. Finally, users can pay fees in any asset.
+1. **Parallelizable Exchange:**  
+   By representing ownership and transfers at the account level rather than using centralized global structures, Miden enables multiple asset exchanges to occur simultaneously, improving network scalability and efficiency.
 
-## Native assets
+2. **Self-Sovereign Ownership:**  
+   Users retain full control over their assets, as there is no reliance on third-party custodians or global registries. This ensures that users directly manage their own value.
 
-Native assets are data structures that follow the Miden asset model (encoding, issuance, storing). All native assets are encoded using a single `word` (4 field elements). The asset encodes both the ID of the issuing account and the asset details. 
+3. **Censorship Resistance:**  
+   With no single authoritative contract or entity controlling asset transfers, users can transact freely. This reduces the risk of transactions being blocked, resulting in a more open and resilient system.
 
-Having the issuer's ID encoded in the asset makes determining the type of an asset, inside and outside Miden VM, cost-efficient. And, representing the asset in a `word` means the representation is a commitment to the asset data itself. That is particularly interesting for non-fungible assets.
+4. **Flexible Fee Payment:**  
+   Unlike protocols that require a specific base asset for fees, Miden allows users to pay fees in any supported asset. This flexibility simplifies the user experience.
 
-### Issuance
+## What is an asset?
+
+An asset in Miden is a unit of value that can be transferred from one [account](accounts.md) to another using [notes](notes.md).
+
+## Native asset
+
+> All data structures following the Miden asset model that can be exchanged.
+
+Native assets adhere to the Miden asset model (encoding, issuance, storage). Every native asset is encoded using a single `Word` (4 field elements). This `Word` includes both the [ID](accounts.md#id) of the issuing account and the asset details.
 
-Only specialized accounts called faucets can issue assets. As with regular accounts, anyone can create a faucet account. Faucets can issue either fungible or non-fungible assets - but not both. 
+### Issuance
 
-The `faucet_id` identifies the faucet and starts with a different sequence depending on the asset type, see the [account id discussion](accounts.md#account-id). The faucet's code defines rules for how assets can be minted, who can mint them etc. Conceptually, faucet accounts on Miden are similar to ERC20 contracts on Ethereum. However, there is no ownership tracking in Miden faucets.
+> **Info**
+> - Only [faucet](accounts.md#account-type) accounts can issue assets.
 
-Faucets can create assets and immediately distribute them by producing notes. However, assets can also stay in the faucet after creation to be sent later, e.g., in a bundle. That way, one can mint a million NFTs locally in a single transaction and then send them out as needed in separate transactions in the future.
+Faucets can issue either fungible or non-fungible assets as defined at account creation. The faucet's code specifies the asset minting conditions: i.e., how, when, and by whom these assets can be minted. Once minted, they can be transferred to other accounts using notes.
 
 ![Architecture core concepts](../img/architecture/asset/asset-issuance.png)
 
-### Fungible assets
+### Type
+
+#### Fungible asset
+
+Fungible assets are encoded with the amount and the `faucet_id` of the issuing faucet. The amount is always `$2^{63} - 1$` or smaller, representing the maximum supply for any fungible asset. Examples include ETH and various stablecoins (e.g., DAI, USDT, USDC).
 
-A fungible asset is encoded using the amount and the `faucet_id` of the faucet which issued the asset. The amount is guaranteed to be  `$2^{63} - 1$ or smaller, the maximum supply for any fungible asset. Examples of fungible assets are ETH and stablecoins, e.g., DAI, USDT, and USDC.
+If the `faucet_id` of ETH is `2`, 100 ETH is encoded as:  
+`[100, 0, 0, 2]`
 
-If the `faucet_id` of MATIC is `2`, 100 MATIC are encoded as `[100, 0, 0, 2]`; the `0`s in the middle distinguish between fungible and non-fungible assets.
+The zeros in the middle positions distinguish fungible from non-fungible assets.
 
-### Non-fungible assets
+#### Non-fungible asset
 
-A non-fungible asset is encoded by hashing the asset data into a `word` and then replacing the second element with the `faucet_id` of the issuing account: For example `[e0, faucet_id, e2, e3]`. Note that the second element is guaranteed to be non-zero. Together with the fungible asset encoding, this makes it easy to differentiate between both asset types by inspecting the second element.
+Non-fungible assets are encoded by hashing the asset data into a `Word` and placing the `faucet_id` as the second element. Examples include NFTs like a DevCon ticket.
 
-Examples of non-fungible assets are all NFTs, e.g., a DevCon ticket. The ticket's data might be represented in a JSON string representing which DevCon, the date, the initial price, etc. Now, users can create a faucet for non-fungible DevCon tickets. This DevCon faucet would hash the JSON string into a `word` to transform the ticket into an asset.
+A non-fungible asset is encoded as:  
+`[e0, faucet_id, e2, e3]`
+
+The `faucet_id` at position `1` distinguishes non-fungible from fungible assets.
 
 ### Storage
 
-[Accounts](accounts.md) and [notes](notes.md) contain asset vaults that are used to store assets. Accounts can keep unlimited assets in a sparse Merkle tree called `account vault`. Notes can store up to `255` distinct assets.
+[Accounts](accounts.md) and [notes](notes.md) have vaults used for asset storage.
 
 ![Architecture core concepts](../img/architecture/asset/asset-storage.png)
 
-The information on which and how many assets are owned can be private depending on the account's or note's storage mode. This is true for any native asset in Miden.
+### Burning
+
+Assets in Miden can be burned through various methods, such as rendering them unspendable by storing them in an unconsumable note, or sending them back to their original faucet for burning using it's dedicated function.
 
-## Non-native assets
+## Non-native asset
 
-Miden is flexible enough to create other types of assets as well.
+> All data structures not following the Miden asset model that can be exchanged.
 
-For example, developers can replicate the Ethereum ERC20 model, where ownership of fungible assets is recorded in a single account. To transact, users must send a note to that account to change the global hashmap.
+Miden is flexible enough to support other asset models. For example, developers can replicate Ethereum’s ERC20 pattern, where fungible asset ownership is recorded in a single account. To transact, users send a note to that account, triggering updates in the global hashmap state.
 
-Furthermore, a complete account can be treated as a programmable asset because ownership of accounts is transferrable. An account could be a "crypto kitty" with specific attributes and rules, and people can trade these "crypto kitties" by transferring accounts between each other.
+## Conclusion
 
-We can also think of an account representing a car. The owner of the car can change so the car account - granting access to the physical car - can be treated as an asset. In this car account, there could be rules defining who is allowed to drive the car and when.
+Miden’s asset model provides a secure, flexible, scalable, and privacy-preserving framework for representing and transferring value. By embedding asset information directly into accounts and supporting multiple asset types, Miden fosters a decentralized ecosystem where users maintain their privacy, control, transactions can scale efficiently, and censorship is minimized.

docs/architecture/notes.md

@@ -1,4 +1,4 @@
-# Notes
+# Note
 
 > The medium through which [Accounts](accounts.md) communicate in the Miden protocol
 
@@ -138,4 +138,4 @@ That means if a note is private and the operator stores only the note's hash, on
 
 ## Conclusion
 
-Miden’s notes introduce a powerful mechanism for secure, flexible, and private state management. By enabling asynchronous asset transfers, parallel execution, and privacy at scale, they transcend the limitations of strictly account-based models. As a result, developers and users alike enjoy enhanced scalability, confidentiality, and control. With these capabilities, Miden is paving the way for true **programmable money** where assets, logic, and trust converge seamlessly.
+Miden’s `note` introduce a powerful mechanism for secure, flexible, and private state management. By enabling asynchronous asset transfers, parallel execution, and privacy at scale, notes transcend the limitations of strictly account-based models. As a result, developers and users alike enjoy enhanced scalability, confidentiality, and control. With these capabilities, Miden is paving the way for true **programmable money** where assets, logic, and trust converge seamlessly.