LSP9 - Vault
Introduction
Using the Key Manager with the Universal Profile will enable third parties to execute through your profile given specific permissions, but this will not eliminate the risk of operating maliciously with your data and belongings.
Third parties should be restricted when talking to a specific smart contract through the Universal Profile to avoid this risk when it almost has the same functionalities and is controlled by the Universal Profile.
What does this standard represent?
This standard defines a vault that can hold assets and interact with other contracts. It can attach information via ERC725Y to itself, execute, deploy or transfer value to any other smart contract or EOA via ERC725X. It can be notified of incoming assets via the LSP1-UniversalReceiver function.
This standard uses the ERC173 standard to provide ownership functions for owning and controlling the implementation contract.
Specification
ERC725X - Generic Executor
This substandard enables the vault to execute a call on any other smart contracts, transfer the blockchain's native token, or deploy a new smart contract. Only the owner can perform these operations below.
The following operationType MUST exist:
0forCALL1forCREATE2forCREATE23forSTATICCALL
The following operationType COULD exist:
4forDELEGATECALL- NOTE This is a potentially dangerous operation
ERC725Y - Generic Data Key-Value Store
This substandard enables the vault to hold arbitrary data through a generic data key/value store. It gives flexibility to the contract storage by allowing to attach any information to the contract and update it easily.
The data keys and values are constructed according to the LSP2-ERC725YJSONSchema standard.
LSP1 - UniversalReceiver
See the LSP1-UniversalReceiver standard for more information.
The implementation of the UniversalReceiverDelegate used by the Universal Profile is different from the one used by the vault. Check LSP1UniversalReceiverDelegateVault
This standard enables the vault to be notified of incoming transactions such as token transfers, information transfers, etc. Notifications are handy when users want to customize how their account contract reacts to certain tokens by either rejecting them or operating a specific call on each received token.
The LSP9-Vault implements the universalReceiver(..) function that:
-
Emits an event with the typeId and data passed to it, as well as additional parameters such as the amount sent to the function, the caller of the function, and the return value of the delegate contracts.
-
Forwards the call to the UniversalReceiverDelegate contract address stored under the data key attached below, if it supports LSP1UniversalReceiverDelegate InterfaceId.
{
"name": "LSP1UniversalReceiverDelegate",
"key": "0x0cfc51aec37c55a4d0b1a65c6255c4bf2fbdf6277f3cc0730c45b828b6db8b47",
"keyType": "Singleton",
"valueType": "address",
"valueContent": "Address"
}
- Forwards the call to the typeId delegate contract address stored under the data key attached below, if it supports LSP1UniversalReceiverDelegate InterfaceId.
{
"name": "LSP1UniversalReceiverDelegate:<bytes32>",
"key": "0x0cfc51aec37c55a4d0b10000<bytes32>",
"keyType": "Mapping",
"valueType": "address",
"valueContent": "Address"
}
<bytes32> is the
typeIdpassed to theuniversalReceiver(..)function.
LSP14 - Ownable2Step
See the LSP14 - Ownable2Step standard for more information.
This standard allows for the LSP9 - Vault contract's ownership to be controlled by an EOA or by another contract, by implementing 3 essential methods:
Flow
Developers could use the vault to hold assets and, as mentioned before, could be used to restrict third parties to only operate on the assets and metadata of the vault and not the Universal Profile. The Universal Profile's metadata and assets are safe if the third party tries to act maliciously.
1. The protocol should be allowed to only talk to the vault A1 through AllowedAddresses permission.
2. All the protocol transactions should be routed through the vault. Otherwise, the transaction will revert.
