A Vault is a specific type of Guild that you can create with the Guilds protocol.
It confers to a set of signatory addresses the permission to approve transactions for receiving, storing and sending funds from the Vault treasury; or, in general, to execute code.
A Vault does not have a Proposal Manager; decisions are made and carried out purely by the signatories.
For a Vault, it is possible to define:
- n -> the number of independent signing keys
- m -> the number of those keys that must sign to authorize a transaction
A standard Vault has the Treasury Manager Component for receiving storing and sending funds. A standard Vault architecture has also the:
- Microservices Manager Component -> This tracks, adds, removes, replaces, executes and in general manages all of the Guild's microservices. Other active Components of the Guild.Only the host can make these changes. can also add or remove microservices. When a microservice is executed, it is treated as a one-time 'temporary Guild sub-Component', allowing it to have write access on the Guild and the Guild's other Components. It then un-links in the same atomic call, and its key is deleted.
- State Manager Component -> This is Vault's main information storage. It allows any linked Component to read and (if active) write pieces of information in a memory area common to all Components.
Vaults have a wide variety of use cases. Consider, first of all, that as you can create one to not only have manageable Treasury, but also execute codes. This means that a Vault can serve as a base layer on which can be built an entire more or less decentralized application.