0xPolygonMiden · phklive · Jan 21, 2025 · Jan 29, 2025 · Jan 29, 2025 · Jan 29, 2025
diff --git a/docs/architecture/accounts.md → docs/architecture/account.md b/docs/architecture/accounts.md → docs/architecture/account.md
diff --git a/docs/architecture/assets.md → docs/architecture/asset.md b/docs/architecture/assets.md → docs/architecture/asset.md
diff --git a/docs/architecture/notes.md → docs/architecture/note.md b/docs/architecture/notes.md → docs/architecture/note.md
diff --git a/docs/architecture/transaction.md b/docs/architecture/transaction.md
@@ -0,0 +1,64 @@
+# Transaction
+
+> Single account state transition
+
+## What is the purpose of a transaction?
+
+To facilitate single account state transitions.
+
+## What is a transaction?
+
+In Miden, a `Transaction` represents the state transition of a single account. A `Transaction` takes a single [account](accounts.md) and one or more [notes](notes.md), and none or one script (piece of code executed after all notes have been executed) as input, and outputs the same account with a potentially updated state, together with some potential newly created notes.
+
+![Transaction diagram](../img/architecture/transaction/transaction-diagram.png)
+
+## Transaction core components
+
+WIP
+
+## Transaction architecture
+
+Miden aims for the following characteristics in `Transaction`s:
+
+- **Parallel transaction execution**: Because a transaction is always performed against a single account, Miden obtains asynchronicity. 
+- **Private transaction execution**: Local execution of transactions enables preservation of sensitive data.
+
+There are two types of transactions in Miden: **local transactions** and **network transactions**.
+
+![Local vs network transactions](../img/architecture/transaction/local-vs-network-transaction.png)
+
+### Local transactions
+
+This is where clients executing the transactions also generate the proofs of their correct execution. So, no additional work needs to be performed by the network.
+
+Local transactions are useful for several reasons:
+
+1. They are cheaper (i.e., lower fees) as zk-proofs are already generated by the clients.
+2. They allow fairly complex computations because the proof size doesn't grow linearly with the complexity of the computation.
+3. They enable privacy as neither the account state nor account code are needed to verify the zk-proof.
+
+### Network transactions
+
+This is where the operator executes the transaction and generates the proofs.
+
+Network transactions are useful for two reasons:
+
+1. Clients may not have sufficient resources to generate zk-proofs.
+2. Executing many transactions against the same public account by different clients is challenging, as the account state changes after every transaction. Due to this, the Miden node/operator acts as a "synchronizer" to execute transactions sequentially by feeding the output of the previous transaction into the input of the next.
+
+## Transaction lifecycle
+
+In Miden, every `Transaction` is executed within the Miden VM. Throughout its lifetime, a `Transaction` progresses through various phases:
+
+1. **Compilation:** All `Transaction` inputs (account, notes, script) are compiled into an executable Miden program.
+2. **Execution:** The `Transaction` program is executed within the Miden VM, which produces outputs (updated account, notes).
+3. **Proving:** The executed `Transaction` is proven by the Miden prover.
+
+![Transaction execution process](../img/architecture/transaction/transaction-execution-process.png)
+
+> **Info**
+> - One of the main reasons for separating out the execution and proving steps is to allow _stateless provers_; i.e., the executed transaction has all the data it needs to re-execute and prove a transaction without database access. This supports easier proof-generation distribution.
+
+## Conclusion
+
+Miden’s `Transaction` introduces an innovative mechanism for local single-account state transitions. By enabling parallel execution and privacy at scale, `Transaction`s in Miden transcend the limitations of conventional account-based model blockchains.
diff --git a/docs/architecture/transactions/contexts.md b/docs/architecture/transactions/contexts.md
diff --git a/docs/architecture/transactions/execution.md b/docs/architecture/transactions/execution.md
diff --git a/docs/architecture/transactions/kernel.md b/docs/architecture/transactions/kernel.md