> For the complete documentation index, see [llms.txt](https://docs.originprotocol.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.originprotocol.com/resources/guides/arm-integrations.md). # ARM Integrations ### Integrating Origin’s Automated Redemption Manager (ARM) This guide covers protocol-level integrations for Origin’s ARM vaults. It applies to all ARM deployments, including `ARM-WETH-stETH`, `ARM-USDe-sUSDe`, `ARM-WETH-eETH`, and `ARM-WS-OS`. All ARM vaults share the same integration behavior. ### Vault Behavior ARM vaults issue a non-rebasing ERC-20 share token representing a proportional claim on vault assets. Share balances do not change over time; yield accrues through changes in the share exchange rate rather than rebasing. ARM vaults expose a vault-like interface for deposits, redemptions, and share valuation. While similar to ERC-4626, the interface differs to support asynchronous withdrawals. ### Entry and Exit Deposits are synchronous and return ARM shares immediately. Integrators may optionally call `previewDeposit` prior to depositing to estimate shares received. Redemptions follow a two-step flow. Users first submit a redemption request using `requestRedeem`. If sufficient liquidity is available in the vault, the redemption may be claimable after a 10 minute delay. Otherwise, the request remains pending until liquidity is returned, at which point `claimRedeem` can be called to complete the exit. Integrations should assume that redemptions may not be instantly claimable and handle pending claims accordingly. When instant liquidity is unavailable, withdrawals follow the underlying asset’s withdrawal mechanics, such as the stETH withdrawal queue for ARM-WETH-stETH. For select ARM deployments, including the stETH ARM, there is onchain liquidity available via AMMs. Integrators should distinguish between redemption request time and claim time. Redemption NAV is set at request time, but if NAV decreases before claim, the claim amount is reduced to the lower claim-time NAV. Integrations should not assume that a queued redemption is economically final until claimed. Claimability depends on vault liquidity. If instant liquidity is unavailable, requests can remain pending until liquidity returns from underlying withdrawals, lending-market withdrawals, new deposits, or swap inflows. Integrations should surface pending state clearly and avoid assuming a fixed maximum exit latency. ### Share Valuation ARM share value should be derived using the vault’s onchain conversion functions, such as `convertToAssets`, rather than AMM spot prices. This provides the canonical share-to-asset exchange rate for accounting and risk calculations. For integrations that require a USD price, protocols typically combine the share exchange rate with their preferred oracle for the underlying asset. ARM shares should not be treated as 1:1 with ETH or other base assets. ### Pricing and Oracles ARM vaults do not rely on AMM pricing for valuation. Integrations should avoid using pool spot prices as an oracle due to potential liquidity constraints and price dislocations. When oracle pricing is required, protocols should compose pricing from the onchain share exchange rate and an external oracle for the underlying asset. Oracle provider selection and risk parameters are left to the integrating protocol. ### Integration Considerations Lending protocols should account for redemption latency when modeling collateral risk and liquidation behavior. Vault aggregators should compute NAV using share conversion functions and surface pending redemptions clearly to users. AMMs, when used, should be treated as optional liquidity venues rather than authoritative pricing sources. ### Failure Modes and Edge Cases Calls to `claimRedeem` may revert until a redemption request becomes claimable. Integrations should handle this behavior gracefully. Preview functions are estimations and may be affected by rounding. Integrators should avoid assumptions of guaranteed immediate settlement. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.originprotocol.com/resources/guides/arm-integrations.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.