fixed some links and gian answered my qs

packages/specs/pages/base-ledger/consensus.mdx

@@ -8,10 +8,10 @@ Namada uses [CometBFT](https://github.com/cometbft/cometbft/) (nee Tendermint Go
 Using the CometBFT consensus algorithm comes with a number of benefits including but not limited to:
 
 - Fast finality 
-    - Simplifying cross-blockchain communication
+    - Tendermint achieves fast and deterministic finality, meaning that once a block is committed to the blockchain, it is irreversible. This is crucial for applications rely on settled transactions that cannot be rolled back.
 - Inter-blockchain communication system (IBC)
     - Composability with all other Tendermint based blockchains, such as Cosmos-ecosystem blockchains
 - Battle tested
-    {/* - TODO: enter number of blockchains that have been using Tendermint */}
+    - The entire cosmos-ecosystem have been using the Tendermint 
 - Customisable
     - Allows the setting of various of parameters, including the ability to implement a custom proof of stake algorithm

packages/specs/pages/base-ledger/execution.mdx

@@ -4,26 +4,25 @@ The Namada ledger execution system is based on an initial version of the Anoma e
 
 ## Validity predicates
 
-Conceptually, a validity predicate (VP) is a boolean function which takes three inputs: 
-1. The transaction's data {/* TODO: I am actually a bit unclear about what the point in this is. Is this just the diff between prior and posterior storage state? Is it the signatures? */}
-2. The storage state prior to a transaction execution
-3. The storage state after the transaction execution
+Conceptually, a validity predicate (VP) is a boolean function which takes four inputs: 
+1. The transaction itself (This may be because certain parts of the transaction needs to be extracted in the VP logic)
+2. The addresses that are involved with that specific VP
+3. The storage state prior to a transaction execution
+4. The storage state after the transaction execution
 
 A transaction may modify any data in the accounts' dynamic storage sub-space. Upon transaction execution, the VPs associated with the accounts whose storage has been modified are invoked to verify the transaction. If any of them reject the transaction, all of its storage modifications are discarded; if all accept, the storage modifications are written.
 
 ## Namada ledger
 
-The Namada ledger is built on top of {/* TODO: Fix links below to point to cometbft  */} 
-[CometBFT](https://docs.cometbft.com/master/spec/)'s [ABCI](https://docs.tendermint.com/master/spec/abci/) interface with a slight deviation from the ABCI convention: in Namada, the transactions are currently *not* being executed in ABCI's [`DeliverTx` method](https://docs.tendermint.com/master/spec/abci/abci.html), but rather in the [`EndBlock` method](https://docs.tendermint.com/master/spec/abci/abci.html). {/* TODO: I don't know what we want to say about the above. Maybe delete the below sentence entirely? */} 
+The Namada ledger is built on top of [CometBFT](https://docs.cometbft.com/v0.37/spec/)'s [ABCI](https://docs.cometbft.com/v0.37/spec/abci/) interface with a slight deviation from the ABCI convention: in Namada, the transactions are currently *not* being executed in ABCI's [`DeliverTx` method](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#delivertx), but rather in the [`EndBlock` method](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). {/* TODO: I don't know what we want to say about the above. Maybe delete the below sentence entirely? */} 
 The reason for this is to prepare for future DKG and threshold decryption integration. 
 
-The ledger features an account-based system (in which UTXO-based systems such as the MASP can be internally implemented as specific accounts), where each account has a unique address and a dynamic key-value storage sub-space. Every account in Namada is associated with exactly one validity predicate. {/* TODO: is the below still true after removing the token vp? I'm assuming yes */}
-Fungible tokens, for example, are accounts, whose rules are governed by their validity predicates. Many of the base ledger subsystems specified here are themselves just special Namada accounts too (e.g. PoS, IBC and MASP). This model is broadly similar to that of {/* TODO: Ethereum link */}
-[Ethereum](https://ethereum.org), where each account is associated with contract code, but differs in the execution model.
+The ledger features an account-based system (in which UTXO-based systems such as the MASP can be internally implemented as specific accounts), where each account has a unique address and a dynamic key-value storage sub-space. Every account in Namada is associated with exactly one validity predicate. Fungible tokens, for example, are accounts, whose rules are governed by their validity predicates. Many of the base ledger subsystems specified here are themselves just special Namada accounts too (e.g. PoS, IBC and MASP). This model is broadly similar to that of [Ethereum](https://ethereum.org/en), where each account is associated with contract code, but differs in the execution model.
 
 Interactions with the Namada ledger are made possible via transactions. In Namada, transactions are allowed to perform arbitrary modifications to the storage of any account, but the transaction will be accepted and state changes applied only if all the validity predicates that were triggered by the transaction accept it. That is, the accounts whose storage sub-spaces were touched by the transaction will all have their validity predicates verifying the transaction. A transaction may also explicitly elect an account as the verifier of that transaction, which will result in that validity predicate being invoked as well. A transaction can add any number of additional verifiers, but cannot remove the ones determined by the protocol. For example, a transparent fungible token transfer would typically trigger 3 validity predicates - those of the token, source and target addresses.
 
 {/* TODO: Explain how the ledger knows which validity predicates to invoke based on a transaction. This is not clear to me. */}
+The ledger knows what addresses are involved in a wasm transaction because of how the storage is constructed. Each variable in storage is inherently tied to a substorage owned by some account, and thus that VP is invoked.
 
 ## Supported validity predicates