Cartesi provides a simple way to handle deposits in your dApp by using Portals, which are a special type of smart contract that can hold funds and interact with the dApp. This guide will show you how to handle deposits in your dApp and manage the internal wallet abstraction using CrabRolls.
How it works
Currently Rollups APIs suport the following asset portals:
When a user deposits a asset on the respective portal, is triggered a new input from portal to dApp, which can be handled by the dApp by the Advance request on the Backend API. Crabrolls provides a simple way to handle this input and manage the internal wallet abstraction and the dApp logic.
Handling deposits
On creating a new dApp environment, CrabRolls will provide a Option<Deposit> parameter on the Advance request, which will be Some if a deposit was made on the respective portal. The Deposit enum contains the following variants:
The Deposit enum contains the sender address and the amount of the deposited asset. For ERC1155, the ids_amounts field contains a list of tuples with the id and amount of each asset deposited because ERC1155 allows multiple assets to be deposited in a single transaction (batch).
Example
The following example shows how to handle deposits in your dApp using a simple MyApp struct that implements the Application trait, you can see more on Environment and Application.
Now you can handle deposits in your dApp and make you own business logic.
Wallet abstraction
The Environment trait provides a simple way to manage the internal wallet abstraction using some functions based on which asset you want to manage.
Ether
Available functions for Ether:
Example
The following example shows how to handle Ether deposits and divide half of the amount among all the addresses on the internal wallet and generate a voucher withdraw of the amount to the address.
ERC20
Available functions for ERC20:
Example
In this example we will show how to handle ERC20 deposits and send the amount to the address with the highest balance.
ERC721
Available functions for ERC721:
Example
In this example we will show how to handle ERC721 deposits and transfer the token to a predefined address based on the token id(odd or even).
ERC1155
Available functions for ERC1155:
Example
In this example we will show how to handle ERC1155 deposits and transfer the tokens to the addresses with the lowest balance and withdraw a portion of the tokens from each address.
Portal handling configuration
On running your dApp, you can configure the portal handling by setting the PortalHandlerConfig on the RunOptions struct. The PortalHandlerConfig enum contains the following variants:
Default value is PortalHandlerConfig::Handle{ advance: true }.
So, you can set the PortalHandlerConfig on the RunOptions struct to configure the portal handling like:
Use-case examples:
PortalHandlerConfig::Handle { advance: true }: Handle the portals and pass the payload/deposit/ to the app.
This is the default value. The deposit will be evaluated by the app and the dApp logic of store the information on the internal wallet is executed, and the payload/deposit is passed to the app advance method.
PortalHandlerConfig::Handle { advance: false }: Handle the portals and not pass the payload/deposit to the app.
The deposit will be evaluated by the app and the dApp logic of store the information on the internal wallet is executed, but the payload/deposit is not passed to the app advance, so the app will not be able to handle the deposit using the Deposit parameter.
PortalHandlerConfig::Ignore: Ignore the deposit handle and pass the payload to the app.
The deposit will be ignored by the app and the dApp logic of store the information on the internal wallet is not executed, but the payload/deposit is passed to the app advance method in raw form(like a regular advance, only on the payload, without the Deposit parameter parsing).
PortalHandlerConfig::Dispense: Dispense the deposit and discard the advance input.
The deposit will be ignored by the app and the dApp logic of store the information on the internal wallet is not executed, and the payload/deposit is not passed to the app advance method. Commonly used when deposits are not part of the dApp business logic or wallet management.