Skip to main content

LSP5 - Received Assets

Standard Document

Goal: Keeps track of digital assets

LSP5 - Received Assets enables smart contracts including Universal Profiles to automatically track and manage the assets they own and received, such as tokens and NFTs.

Traditionally, keeping track of owned assets on the blockchain is cumbersome, requiring manual additions and checks or reliance on external services to scan the entire network. LSP5 simplifies this by providing a standardized way to list all assets associated with a Universal Profile directly in its smart contract storage. This is achieved through specific data keys within the ERC725Y data key-value store, allowing for a dynamic and efficient way to manage and reference assets.

By integrating with the LSP1-UniversalReceiverDelegate, this process is automated, ensuring that any new assets received by the Universal Profile are immediately recognized and accessible. This standard not only enhances the usability of Universal Profiles by providing a clear overview of owned assets but also lays the foundation for more complex interactions and functionalities within the LUKSO ecosystem.


Keeping track of all the tokens that an address owns is currently unfeasible.

If you want to know from which tokens you own, you need to manually import the token contract address and query the balance of your key in it each time for each token. This inconvenience brings light to the following problem: owning tokens without being aware because there are no ways of being notified about the tokens you have received in the first place.

Explorers like Etherscan are currently responsible for listing all the tokens each address owns. They do so through their API by scanning the entire network of Ethereum, including the balance on each token contract and potential interacting address. As a result, keeping track of the user's owned assets and balances relies on such centralized services.

One way to solve this problem is to create generic metadata keys that would register in the smart contract storage how many different tokens you own and the address of the transferred token contracts. LSP5 removes the problem listed above by storing the addresses of the tokens you own directly inside your UP storage or any contract that implements LSP5.

What does this standard represent?​


Make sure to understand the ERC725Y Generic Key/Value Store and LSP2 - ERC725YJSONSchema Standards before going through the ERC725Y Data Keys.

This Metadata standard describes two data keys that can be added to an ERC725Y smart contract to reference and keep track of received assets.


This data key represents a list of all tokens and NFTs currently owned by the contract.

"name": "LSP5ReceivedAssets[]",
"key": "0x6460ee3c0aac563ccbf76d6e1d07bada78e3a9514e6382b736ed3f478ab7b90b",
"keyType": "Array",
"valueType": "address",
"valueContent": "Address"

It is advised to query the LSP5ReceivedAssets[] data key to verify if a contract supports the LSP5 - ReceivedAsset standard.


This data key represents a map key, both holding:

  • an ERC165 interface ID to quickly identify the standard used by each asset smart contract (without the need to query the asset contracts directly).
  • the index in the LSP5ReceivedAssets[] Array where the received asset addresses are stored.

The LSP5ReceivedAssetsMap data key also helps to prevent adding duplications to the array when automatically added via smart contract (_e.g., _ an LSP1-UniversalReceiverDelegate).

"name": "LSP5ReceivedAssetsMap:<address>",
"key": "0x812c4334633eb816c80d0000<address>",
"keyType": "Mapping",
"valueType": "(bytes4,uint128)",
"valueContent": "(Bytes4,Number)"



The data keys are also set on the sender Universal Profile to remove the token contract address if all the balance is sent.

If set when transferring tokens, these data keys are automatically updated in the Universal Profile storage via the LSP1UniversalReceiverDelegateUP contract.


Check the token transfer scenario for more details.

Token transfer detailed flow

LSP5 Received Assets Flow