Benefits of the LUKSO Standards
Discover the features and benefits of the LUKSO Standards (LSPs) compared to over standards and existing solutions.
Universal Profiles vs. Smart Walletsβ
Universal ProfilesΒ (known as π) are smart accounts that come with many benefits because of their features.
TheΒ π Browser Extension offers a better user experience to interact with dApps compared to traditional web3 wallets.
Gnosis SAFE | Base Smart Contract Account | EIP 6900 Modular Smart Contract account | Universal Profiles | |
---|---|---|---|---|
Profile like information | β | β | β | β Through LSP3 |
Generic Information Storage | β | β | β | β Through ERC725Y |
Notifications and Reactability | β | β | β | β Through LSP1 |
Permission System | β | β | β | β Through LSP6 |
Multisig | β | β | β | πΆ Can be controlled by a multisig |
Multi purpose | πΆ (With future extension) | πΆ (With future extension) | πΆ (With future extension) | β Can be a DAO, Organisation, Brand, AI, Robot, etc through and permissions [LSP6] |
Gasless Experience | β | β | β | β via the Transaction Relayer |
Extensible | β | β | β | β Through LSP17 |
Upgradeable Security | β | β | β | β Through LSP14 |
Pre and Post Execution Hooks | β | β | β | β Through LSP20 |
Feature | Benefits |
---|---|
ποΈ Metadata in one place | Removes the requirement to refill the same information again and again on each new app you register to! Your information is stored and fetched from the same place (your π storage) and displayed the same across all the dApps ecosystem! |
π¨ Customizable metadata | Make your Universal Profile stand out from others! Give it a profile and cover image, and add as many amount of information with its unlimited storage. |
β½οΈ Gas-Less transactions | No more need to buy and hold native tokens to pay for the gas. Use the transaction relayer from universalprofile.cloud plugged to the Universal Profile from the start to get started. |
π Multi-Control with permissions | Universal Profiles can be controlled by multiple addresses (EOAs and contracts) with various permission levels, held across different devices or representing dApps. Each can have specific access rights (token transfers, playlist management, account recovery, etc). |
π’ Notification and customized reactivity | The π can be customized to react differently based on different events it receives. For instance, the default implementation automatically register new received assets. |
βοΈ Extendability with pluggable Extensions | New features (like new function selectors not present by default in the smart contract code) can be added to a Universal Profile, using a system of extensions. See our guide Extending Universal Profile functionalities for more details. |
ποΈ Metadata in one placeβ
With traditional web3 wallets, a user has to fill the same infos every time it registers on a new dApp (e.g: username, biography, social media accounts). A Universal Profile stores user's data in one single place: the contract's storage. Any dApp can then retrieve the same information from the same place, making dApp onboarding easier and faster.
3 x different dApps (UniversalProfile.cloud, Universal.Page and UniversalSwaps.io) using the same Universal Profile data.
π¨ Customizable Metadataβ
A Universal Profile can represent many personas or forms of identities:
- a user profile (personal or professional)
- a brand
- a DAO or an organisation
- an AI living on the internet
- a service like a wallet recovery
- a character in a video game (represented as an NFT with its own metadata)
4 x different Universal Profiles used for different purposes (a brand, a DAO, a user's profile, a wallet recovery service).
β½οΈ Gas-Less transactionsβ
Using the relayer and always gas less transactions is not mandatory!
Users can also choose not to rely on the Transaction Relay Service and the pay the gas fees of the transaction themselves by funding the controller of their Universal Profile with native currency (e.g: LYX).
Universal Profiles enable gas-less transactions. The relayer pays the gas fees and does not require the user to hold native tokens to pay the transaction fees. Users do not need to go through the whole cumbersome process of:
- downloading a wallet
- creating a new address
- registering to a crypto exchange or a service to buy crypto
- performing KYC
- buying native crypto by card or bank transfer
- in some cases, requesting the bank to authorize the transaction to buy crypto (some user banks restrict from buying crypto online)
- finally start using dApps!
This improves onboarding experiences in the following ways:
- most of the new web3 users do not get their heads around the concept of "gas" and having to pay fees every time they interact with a dApp (compared to interacting with other applications on the internet).
- native and experienced web3 users need to acquire more native currency from various chains just to "play around with dApps" and explore, increasing the costs even more for users present across many chains.
- users can also bridge native currency from one chain to another (e.g: having to bridge ethers from Ethereum to Base to use dApps on Base), but this requires giving up some funds on one chain as a result.
- developers looking to build dApps on new chains need to acquire test LYX from testnet faucets, but most of them now require to hold a minimum amount of native currency on the mainnet to avoid spam and over-usage of the faucet.
As Universal Profile supports gas-less transactions, it is possible to add multiple relayers and switch between them before the confirmation of the transaction.
π Multi-Control with permissionsβ
Universal Profiles can be controlled through multiple EOAs (and their associated private keys), where each private key can be allowed or restricted to specific actions viaΒ permissions.
These controllers can be on multiple devices (laptop, desktop, mobile, hardware wallet like ledger) and represent:
- EOAs or other π
- dapps protocols (defi trading app, gaming app), granted specific access to the Universal Profile.
Some real-life examples for a user's Universal Profile could be:
- A defi app can transfer only a specific token to a particular pool for trading.
- A music dApp can only update a list of music playlists in the Universal Profile's storage.
- A family member can be granted recovery access for trusted third-party recovery.
LSP7/8 Token standards vs. ERC20/721β
Interested to migrate your token or NFT collection? See our hands-on developer guides:
Below are the benefits offered by the LUKSO Token standards LSP7 Digital Asset and LSP8 Identifiable Digital Asset.
Feature | Benefits |
---|---|
π Easier functions for developers | You are a developer? Stop learning different functions for each new ERC token standard! (ERC20, ERC721, ERC1155, etc...). LSP7 and LSP8 use the same function names for transfer and operator approvals, whether it is a token or NFT transfer. |
ποΈ Unlimited & Dynamic Metadata for Tokens & NFTs | Your NFT is not only an image. It can now hold as many information as can be imagined (custom traits, attributes, ...). This information can evolve overtime. |
δ· Flexible Batching functionalities | Distribute multiple tokens or NFTs easily to users with transferBatch(...) or perform multiple actions in a single transaction with batchCalls(...) . (e.g: authorize multiple operators, transfer an NFT and update its metadata). |
π’ Notify sender & recipient(s) on transfer and new operators | Sender is notified "I have sent tokens", recipient is notified "I have received tokens" and both can have custom logic to react on these notifications. Finished the old " approve(...) then transferFrom(...) " flow!. Using the Universal Receiver and automatic reactions on notifications is the new way! |
βοΈ Extendability with pluggable Extensions | New features (like new function selectors not present by default in the smart contract code) can be added to a Digital Asset, using a system of extensions. |
βπ» Safety parameter (by default!) to prevent accidental transfers | Prevent bad web3 user stories and reduce the number of Google searches for: "Transferred tokens to the wrong wallet address. How can I recover them?". |
π Easier functions for developersβ
Both LSP7 and LSP8 use the same function to transfer tokens, with only one different parameter type.
- LSP7
transfer(address,address,uint256,bool,bytes)
function uses auint256
to transfer an amount. - LSP8
transfer(address,address,bytes32,bool,bytes)
function uses abytes32
to transfer a token ID.
Similarly, they both use the same function authorizeOperator(address,[uint256/bytes32],bytes)
to approve new operators for a token allowance or specific token Ids.
ποΈ Unlimited & Dynamic Metadataβ
3 x different NFT collections with their unique traits and characteristics.
Like Universal Profile, digital assets based on the LSP7 and LSP8 standards can hold an unlimited quantity of metadata for any type of information considered relevant to the token or NFT collection. This can include:
- Icons and image.
- The creators of the tokens / NFT collection.
- The list of exchanges where this token can be found.
LSP8 also allows to create more complex and rich NFT collections where each NFT can have its own custom metadata. Setting metadata specific to each NFT is done using the standardized functions setDataForTokenId(...)
and setDataBatchForTokenIds(...)
. This is useful for instance for:
- NFTs that need to hold specific items like digital clothing items for avatars, or weapons / body armors in a video game.
- dynamic NFTs, where any information, traits or attributes of an NFT could be programmed to change or evolve overtime according to certain conditions, logics or triggers.
π’ Notify on transfersβ
On each token transfers, bother sender & recipient are notified that a token transfer happened. This notification includes a specific notification ID (e.g: "I have sent / received some tokens / NFTs". See typeIds for more infos).
In addition, it is possible to program and "plug-in" custom logic contracts called Universal Receiver Delegate to the sender and recipient, so that they can automatically react based on these different types of notifications. For example:
- Registering / Removing tokens from your list of received assets.
- Block incoming spam tokens that can contain malicious logic to steal user's funds if interacting with such token contracts, by filtering them against a spam or blacklist registry.
- Forward automatically a certain percentage of the tokens received to a specific address (e.g: a Vault to implement "save the change" schemes, a wallet for savings, a family member).
- Implement automated mechanisms to re-distribute equally and proportionally the tokens received in a trustless manner (e.g: distribute dividends to shareholders, or bonuses to employees.)
In the web3 ecosystem, many contracts can hold, send and receive assets (e.g: π, Vaults, Marketplaces, Liquidity pools, etc...). The LSP1 Universal Receiver standard offers many ways to build innovative automation systems on top of those, so that users can enjoy a better and safer experience interacting with digital assets on the blockchain.
βπ» Safety to prevent accidental transfersβ
The transfer(...)
function of LSP7 and LSP8 contains a bool force
parameter to prevent accidental transfers like:
- when an incorrect address was pasted in an input field on a dApp or blockchain explorer.
- when an incorrect
address
parameter was passed within an internal transaction of a complex interaction. - when a smart contract does not have any functionality to transfer tokens, preventing the tokens from being stuck.
- when transferring tokens to an EOA address, which should be for advanced users who use private keys / seed phrases and could loose access to funds in the future.
The bool force
parameter ensures that users and smart contracts are not transferring tokens to addresses that could potentially not hold or re-transfer the token.