Skip to main content
Mainnet integration guide draft · English v1.0 · 7 October 2026 Docs Home · Developer Guide · Smart Contracts and References Partners enter the official deployment materials and ABIs for the selected product, then prepare deposits and redemptions with the user’s EVM wallet. The TypeScript examples below connect quotes, simulation, submission, successful receipts, and actual token receipt for the public deposit and redemption interfaces. Check the product’s eligibility requirements and supported features, then apply the examples to the relevant release version.

Inputs to prepare

The values and distribution paths for the official mainnet manifest, ABI files, and partner API specification will be finalized at release. The following is an integration input template to map into a partner’s local configuration, rather than a finalized official manifest schema. null and empty arrays indicate values that have not been entered. Do not invent addresses or a chainId, or use public verification environment values as mainnet values.
paymentToken, productToken, depositVault, and redemptionVault are the official user-facing call addresses. Enter the full ABI arrays matching the deployment in abis.deposit and abis.redemption. Compare implementation addresses, source versions, ABI file integrity, and supported routes against the release materials described in Smart Contracts and References. Obtain confirmations from the network and product’s confirmation policy. Read and validate the official inputs from a local configuration file, then pass them to connectIntegration(config, abis, provider, recordSubmission). provider is the user’s connected EIP1193 wallet. This example uses the calling conventions of viem 2.53.1. Saving the code or connecting a wallet does not submit a transaction. Call deposit or redemption functions when the user confirms the displayed amount, recipient, and route. recordSubmission is the partner’s function for storing the transaction hash, chain, product, and call immediately after submission. If a replacement transaction is confirmed, also store its new hash, the original hash, and the replacement reason. If the connection is lost while waiting for a receipt, use the stored hash to query the transaction again.

Connect the wallet and contracts

Display the quote and set the minimum receipt

On the deposit screen, convert the amount using the payment asset’s decimals, then query quoteDeposit. On the redemption screen, use the ProductToken’s decimals and quoteRedeem. The user reviews the quote, recipient, network, and permitted price movement. Pass minSharesOut and minAssetsOut as integers in the smallest units after this confirmation. Do not use 0 to disable price protection. Calculate amounts with bigint and display them in the relevant token’s units. For example, when permitted price movement is entered as an integer bps, the minimum receipt can be calculated as quote * (10_000n - bps) / 10_000n. Validate the range of bps and apply the product’s pricing and cost policies. Show the amount to the user again after obtaining a new quote. Do not insert an estimated fee into a quote that does not include fees.

Submit a deposit and verify receipt

The function below rechecks the quote after approving the required payment asset and then simulates the deposit. After submission, it checks the deposit event’s product contract, user, recipient, and quantities against the ProductToken mint log. The returned balance is the holding at the confirmed receipt’s block. The quantity received in this transaction is sharesOut.

Internal direct redemption and request acceptance

This example is limited to the internal direct redemption and request-and-claim flow in the public ArcoRedemptionVault. The public redemption implementation burns user tokens through the vault’s permissions, so it does not require a separate ProductToken approve. Products whose release ABI uses a different transfer or approval mechanism follow that specification.
For internal-instant, show receipt only after verifying the successful transaction receipt, the user’s token burn, and the payment asset transfer logs. For request, the acceptance transaction burns the tokens and fixes the expected payment amount at the price recorded at that time; it returns requested. Store the chainId, vault address, request ID, and original transaction together. Do not show acceptance as payment completion.

Verify payment after a request

In the public request-and-claim implementation, query redemptionRequests(requestId) to check recipient, assetsOut, fulfilled, and claimed. ProductRedeemFulfilled indicates that payment assets have been reserved and the claim is ready; it does not mean payment is complete. When fulfilled=true and claimed=false, the designated recipient simulates and signs claimRedeem(requestId). Show payment as complete only after checking ProductRedeemClaimed in the successful receipt and the actual payment asset transfer. If a released product uses direct operator payment, NAV fixed at settlement, or a separate settlement route, use that payment transaction and the release’s state specification. OTC quote acceptance, orders, execution, and settlement are not replaced by this direct redemption function. Do not record an acquisition-based token transfer as a burn.

Interruptions and recovery

Simulation failure, user rejection, and an unknown result after submission are distinct states. Once a submission hash is available, query the chain, original transaction, account nonce, and relevant events before resubmitting. Do not treat an RPC timeout as transaction failure or create a new request because a query returns no result. When the API lags, distinguish the onchain outcome from a pending display update. Follow the recovery tables in the Developer Guide for specific event and error responses.

Scope

These examples reference the ProductToken, ArcoDepositVault, and ArcoRedemptionVault interfaces in public source version 8160f354. ArcoUSD’s multiple assets and 1:1 exchanges, Savings return connections, Funds burning and treasury settlement, and OTC orders and execution connect through separate release interfaces and feature matrices. For an actual product integration, verify official addresses, full ABIs, eligibility conditions, pricing policies, and supported routes.