Comment on page
Deposit
Learn how to deposit assets into your Arc application.
The deposit operation enables users to deposit on-chain assets into the Arc platform so that they can be utilized in applications. Deposits are initiated by invoking the Ethereum deposit function corresponding to the asset type being deposited. To facilitate the deposit procedure, the Arc API exposes a supplementary endpoint that can be used to query auxiliar deposit data.
The Arc Bridge, scheduled to be released as part of the public testnet, will allow for deposits from any EVM compatible chain (eg. Arbitrum, BNB Chain, Polygon).
This page describes multiple deposit flows that can be used interchangeably based on the needs of the application and the type of asset being deposited:
In order to deposit assets in a Arc application, users will need to call a deposit function in the Arc Ethereum smart contracts. For ERC-20, ERC-721, and ERC-1155 assets the user must call the approve function on the token contract, authorizing Arc to transfer funds on behalf of the user, prior to invoking the deposit function:
You don't need to call the approve function before every deposit. By setting a high allowance (for ERC-20 tokens) or using the approve for all function (for ERC-721 and ERC-1155) tokens, you'll only need to execute the approval once.
ERC-20
ERC-721
ERC-1155
// Sets amount as the allowance of spender over the caller's tokens.
function approve(
address spender,
uint256 amount
) external returns (bool);
// Approves another address to transfer the given token ID.
// The zero address indicates there is no approved address.
// There can only be one approved address per token at a given time.
// Can only be called by the token owner or an approved operator.
function approve(address to, uint256 tokenId) external;
// Sets or unsets the approval of a given operator.
// An operator is allowed to transfer all tokens of the sender on their behalf.
function setApprovalForAll(address to, bool approved) external;
// Grants or revokes permission to operator to transfer the caller’s tokens, according to approved
function setApprovalForAll(address operator, bool approved) external;
The deposit function to call depends on the type of asset being deposited:
ETH
ERC-20
ERC-721
ERC-1155
// deposit ETH (ie. Ether)
function depositEth(
uint256 starkKey,
uint256 assetType,
uint256 vaultId
) external payable;
// deposit ERC-20 tokens
function depositERC20(
uint256 starkKey,
uint256 assetType,
uint256 vaultId,
uint256 quantizedAmount
) external;
// deposit ERC-721 token (ie. NFT)
function depositNft(
uint256 starkKey,
uint256 assetType,
uint256 vaultId,
uint256 tokenId
) external;
// deposit ERC0-1155 tokens
function depositERC1155(
uint256 starkKey,
uint256 assetType,
uint256 tokenId,
uint256 vaultId,
uint256 quantizedAmount
) external;
Arc will then monitor the Ethereum blockchain for deposit emitted on-chain, and automatically credit the user in the platform. More information regarding the smart contract deposit functions used in Arc can be found here.
Only assets whitelisted in your application can be used for deposit operations. Deposits for other assets will be ignored and can be later reclaimed by the user.
In order to facilitate fetching the necessary details to call the deposit function, Arc exposes an HTTP POST endpoint under /api/v1/vaults/deposit-details with the following form:
post
https://testnet-api.onarc.io
/api/v1/vaults/deposit-details
Returns the deposit details for a given asset.
The retrieved deposit details contain information regarding which deposit function to call as well as the exact input values.
In a future update, the response details will also include a pre-encoded transaction that can be signed using the user's Ethereum private key and submitted directly to the network
In the regular deposit flow the user deposits the assets into the Arc platform directly, via a call to the smart contract deposit function, upon requesting deposit details from the Arc API (proxied by the application). The steps involved in the process are:
- 1.The user initiates the deposit process by sending a GET request to the Application's server for deposit details. This is necessary due to the fact that the user cannot access the Arc API directly and should therefore proxy the request through the application's back-end.
- 2.The Application receives the user's request and forwards the POST request to the Arc server endpoint /api/v1/vaults/deposit-details to retrieve the deposit details.
- 3.Arc receives the Application's request, processes the deposit details, and sends the details back to the Application.
- 4.The Application receives the deposit details from Arc and sends them back to the user.
- 5.The user then creates and sends a deposit transaction to the Ethereum blockchain by calling the corresponding deposit function with the input values returned in the deposit details.
- 6.Ethereum receives the user's deposit transaction and adds it to a block in the blockchain.
- 7.The Arc server logs the deposit event and updates the user's account balance.
- 8.The user's account on Arc is updated to reflect the deposit.
The following flow diagram illustrates these steps:
Regular deposit flow
The transfer deposit flow represents an alternative flow where the application keeps an inventory of previously deposited tokens and is able to mediate user deposits without requiring users to send Ethereum transactions themselves. This can provide a more seamless experience for users who may not be familiar with the complexities of interacting with the blockchain. The steps involved in this process are:
- 1.The Application initiates the deposit process, used to replenish asset inventory, by sending a GET request to the Arc server endpoint /api/v1/vaults/deposit-details to retrieve the deposit details.
- 2.Arc receives the Application's request, processes the deposit details, and sends them back to the Application.
- 3.The Application then creates and sends a deposit transaction to the Ethereum blockchain by calling the corresponding deposit function with the input values returned in the deposit details.
- 4.Ethereum receives the Application's deposit transaction and adds it to a block in the blockchain.
- 5.The Arc server logs the deposit event and updates the Application's account balance.
- 6.The user initiates a deposit by sending a request to the Application's server.
- 7.The Application receives the user's request and sends a POST request to the Arc server endpoint api/v1/transfer to transfer tokens from the Application's inventory to the user's account.
- 8.Arc receives the Application's request, processes the transfer, and sends a response back to the Application.
- 9.The Arc server updates the balances of both the Application and the user, decreasing the Application's balance and increasing the user's balance.
- 10.The Application sends a response back to the user indicating that the deposit was successful.
Note that steps 1-5 should not be executed for every single deposit. Instead the application should make a sufficiently large deposit to create an inventory of assets to accommodate for future user deposit requests and replenish the inventory periodically.
The following flow diagram illustrates these steps:
Transfer deposit flow
The mint deposit flow is an alternative deposit flow, where the application mediates user deposits by leveraging the mint operation, provided by Arc, without requiring explicit on-chain actions (ie. sending Ethereum transactions) by any party.
Using this flow the application mints new assets in order to fulfil deposit request instead of executing a transfer of previously deposited assets (as it happens in the transfer deposit flow).
The mint deposit flow is only available for mintable assets for which the current application has mint permissions. The new assets should be minted directly to the depositor.
The steps involved in a mint deposit operation are:
- 1.The user initiates a deposit by sending a POST request to the Application's server indicating it's intent to execute a deposit.
- 2.The Application receives the user's request, executes some business logic, and sends a POST request to the Arc server endpoint api/v1/mint to mint a corresponding amount of assets directly to the user's account.
- 3.Arc receives the Application request, processes the minting of the assets, and sends a response back to the Application indicating that the minting was successful.
- 4.The Application sends a response back to the user indicating that the deposit was successful.
Mint deposit flow
Last modified 3mo ago