ndau accounts are protected by security mechanisms more powerful and more flexible than those offered by other digital currencies. Account transactions may be required to meet multiple criteria before being accepted as valid, such as having multiple signatures and minimum or maximum amounts. In order to be a source of transactions, an ndau account must have at least one validation key associated with it, and it may also have a validation script assigned. Those keys and validation script are used to validate any subsequent transactions submitted for that account.
Ownership and Validation keys
An ndau account has an address that is generated from a key known as the ownership key.
The ownership key is only used for 2 things:
- The ownership key’s public key is used to generate the ndau account address.
- The ownership key’s private key is used to sign the account’s SetValidation transaction, thereby registering a set of validation keys (at least one) and an optional validation script for that account.
After a SetValidation transaction is processed, the ownership key is not used to sign any other transactions.
SetValidation and ChangeValidation transactions
A newly-created account can be the target of transfer transactions from other sources (including EAI) and can receive ndau newly released from the Endowment. No validation keys are associated with it and no other transactions are valid until a SetValidation transaction is submitted for the account. That transaction assigns one or more validation keys and an optional validation script to it.
Once a SetValidation transaction has been processed, all subsequent transactions use only the validation key(s) and the validation script. All transactions must be signed by the appropriate validation key(s), with the validation script deciding whether the transaction is valid. Although the validation key(s) may be changed later, at least one validation key is always required.
After the initial validation rules have been established with the SetValidation transaction, those rules may be changed with a ChangeValidation transaction. When submitting a ChangeValidation transaction, validation key(s) and validation script are required fields. To reset a validation script if one has been assigned, it must be replaced with a trivial script that permits all transactions signed with one of the current set of keys. The ChangeValidation transaction itself is checked against the current validation rules. An account holder can, therefore, establish validation rules that prevent any further changes to those rules.
The SetValidation transaction for an account must be signed with that account’s ownership key. All subsequent transactions submitted must be signed with one or more of the validation keys currently assigned to the account and they must be authorized as valid by the current validation script if one is present. If there is no validation script assigned, then the transaction’s signatures alone are sufficient to validate it. If a validation script is present, the transaction signatures only indicate that the transaction was properly formatted and was submitted by at least one valid signer, and only then will the validation script be run. The validation script then determines the validity of the transaction: the transaction signatures alone may not be sufficient. Each validation script indicates the minimum number of keys it requires. For example, a script implementing two-of-three key validation will require three keys be specified for it in a SetValidation transaction.
The validation script is checked for proper formatting and syntax when it is being set, and a SetValidation or ChangeValidation transaction is not valid if the validation script contains syntax errors. Validation scripts have access to the current transaction, account state, and system variables but may not modify them. They may not generate new transactions or trigger external events of any sort: they perform no function other than to determine the validity of a transaction submitted for an account.
Since all system variables and properties of the account and transaction are available to the validation script, it may establish validation rules for specific transaction types or rules based on specific values in the transaction or account.