Skip to main content
Partner integration guide draft · English v1.0 · 13 October 2026 Distribution OS Start by selecting the Arco vault products your company will offer and confirming the scope of the partner integration. The steps below are a conceptual integration sequence. They do not define API operations, status enums or a self-service credential flow.

​
1. Select products and confirm access

Review RWA Vaults and Arco Saving Vault. For each selected product, confirm the intended customer group, permitted jurisdictions, rights, accepted assets, valuation, costs and redemption conditions. Confirm the partner’s access separately from each customer’s participation eligibility. Use the procedure actually supplied for the selected product, including any required document review or wallet registration. A public catalog listing is product information, not an eligibility decision.

​
2. Establish the integration environment

Use the integration materials supplied for the selected product and version. Map the product identifier, environment, authentication, supported operations, account or wallet model and relevant network to the partner’s configuration. For a contract-based route, use its official call addresses and matching ABIs. Keep API credentials separate from wallet or custody signing authority. Partner authentication does not grant a user allowance, create a wallet signature or authorize an operator to move assets. Describe the supported signing arrangement for that integration without assuming that both customer-wallet and custody execution models are offered.

​
3. Present the product and prepare a transaction

Present the accepted deposit asset and representation, strategy exposure, position received, performance basis, redemption asset and route. Show the applicable pricing time, fees and expected receipt under the selected product’s terms. Connect transaction preparation through the supplied interface. Before execution, verify the target product, environment, account, recipient, quantity units and required permissions. Keep exact quantities separate from rounded display values. Where the route uses quotes or minimum receipt protection, apply its actual validity and execution rules.

​
4. Connect authorization and completion checks

Explain what the customer or authorized signer is approving. Asset spending approval, transaction signing, request acceptance, confirmed funds and position allocation are separate concepts, even when a particular route combines some of them. Store the transaction or request identifiers supplied by that route. Confirm actual position receipt and payout according to the Deposits & Redemptions guide, rather than treating submission as completion.

​
5. Reconcile holdings and pending activity

Show confirmed holdings separately from pending deposits, redemption obligations and any amount ready to receive. Display the source and valuation time with the position value. Use the definitions in Positions & Performance to avoid counting the same economic value twice. An unavailable or delayed API response does not establish that an asset movement failed. Resolve the original transaction or request before attempting another submission.

​
6. Validate the full lifecycle

Validate product selection, access restrictions, amounts, authorization, allocation and redemption in the agreed validation environment. Cover insufficient balances, unavailable liquidity, invalid pricing, rejected signatures, delayed results and unknown outcomes as applicable to the route. Exercise cancellation, partial processing, refunds and retries only where their behavior is explicitly supported. Reconcile a completed deposit and a completed payout with the records that establish receipt. Confirm support responsibilities and recovery procedures before the partner’s production rollout.

​
Read the implementation references

The existing Integration Guide, Developer Quickstart and Smart Contracts and References explain the pinned EVM reference implementation. Use them to understand that implementation’s calls and events. Apply only the operations and versions specified for the selected partner environment; the reference code does not establish a production Distribution OS release.