# Namada spes audit
This is an effort to review Namada specs with an Occam's razor prospective, aiming to cut away everything but the necessary. I will also try to allin the terminology used to the latest agreed upon on by the Anoma team. Opinions on the specs presented here are my own.
## Intro
The relationship between Anoma and Namada is not necessary here. As I understand, the sole connection between Anoma and Namada at this moment in time is the developers. The "why Namada" should come before the "what Namada".
What does it mean for the MASP to be "dervided from" the Sapling Circuit?
The base ledger execution system is claimed to be based on validity-predicates, which is a terminology that we are going to drop from the Anoma architecture. How can Namada be based on VPs if it is not intent-centric?
## Base ledger
Why are we talking of a "Base ledger", are there more than one ledger? Is the base ledger different from the namada ledger?
In the specs we read:
*The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps.*
The difference between a smart-contract based execution model and a VP based one should be expanded. For instance, what is the dual of the deployment of a smart-contract on a VP based system.

### Consensus
A clear definition of "Namada's custom state machine" is missing. How does it relate to the base ledger /the Namada ledger?

### Execution
**A formal definition of an account in Namada is missing** - seems to me there is a correlation with what is called "application" in Taiga.
In *Validity predicates* we refer to "the transaction itself", but we do not mention transaction before in this paragraph. Seems to me it should be "a transaction", or re-arrange the order of the bullet points in the validity predicates definition. Moreover here would probably be a good place to talk about validity predicate reletions to logic of the functions users want to execute on chain.

### k-of-n multisignature
Why do we have k-of-n as a chapter here? Is this an example of a VP or is it a fundamental component of Namada?
Is k-of-n signature the only way of authorizes transactionsn on Namada?
Use of the word "invoke" to describe interaction with other smart contracts.
What is a user account? What is NOT a user account?
We refer to "user-owner accounts", but the notion of user-owner accounts was never introduced.
What does it mean to be written in storage?

To verify the correctness of the signatures, the VP checks the following conditions:
    Enough unique signatures for the given threshold are provided
    Enough valid signatures for the given threshold are provided

Say we have a threshld at 4 and we are provided with 15 signature. 10 of them are unique but not valid, 5 of them are valid but are not unique. Would the VP verify the correctness of the signature as valid?
The reader was not introduced to the concept of `established` adresses. What are they?
How/when we create accounts?

### Fungible token

## Multi-asset shielded pool
We should state that sends arbitrary assets privately: adds support for sending arbitrary assets mantaing the nature of the asset private.
The order in which I should see the documents is unclear: do I have to read the Cryptographic specification before going into Ledger integration? Is it optional?

## Governace

# General notes
The implementation details are spares

# Git Issue
* [base-ledger/execution](https://github.com/anoma/namada-docs/blob/master/packages/specs/pages/base-ledger/execution.mdx):
In *Validity predicates* we refer to "the transaction itself", but we do not mention transaction before in this paragraph. Seems to me it should be "a transaction", or re-arrange the order of the bullet points in the validity predicates definition
It is not clear to me what is the difference between the *Namada ledger* and the *base ledger*. A clear definition of what an account is in Namada is missing.
*