> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arco.financial/llms.txt
> Use this file to discover all available pages before exploring further.
# ETH Staking Vault
Mainnet product guide draft · English v1.2 · 14 October 2026
[Savings](/products/savings) · [Crypto-native (Staking)](/products/savings/staking) · [Arco Saving Vault](/distribution-os/arco-saving-vault) · [Vault Liquidity Architecture](/liquidity/architecture)
ETH Staking Vault is a crypto-native Savings product designed to connect ETH participation on GIWA to institutional validator operations on Ethereum. Users deposit the supported ETH representation on GIWA and receive vault shares on GIWA. The GIWA vault and Ethereum allocation use MPC-based custody. Arco retains withdrawal and recovery authority within the custody and approval framework; institutional operators perform validator duties and participate with Arco in the Security Council multisig.
The liquid staking token model represents participation in the vault’s ETH assets and staking performance. The design reflects rewards, losses and costs in the ETH value of each share, with deposits, issuance, validator activation and redemption payment recorded as separate outcomes. Product availability and execution follow the applicable offering terms and release specification.
## Product overview
| Item | ETH Staking Vault design |
| - | - |
| Product family | Crypto-native (Staking); a representative Arco Saving Vault product |
| Deposit | The supported ETH representation on GIWA, identified in the product’s deposit instructions |
| Position received | Vault share token issued on GIWA, with product-specific rights and transfer conditions |
| Underlying exposure | ETH deployed to Ethereum validators operated by institutional providers |
| Custody | MPC-based custody for the GIWA vault and Ethereum allocation |
| Withdrawal authority | Arco controls the designated Ethereum withdrawal address and recovery authority under the applicable custody and Security Council approval policy |
| Security Council | Arco and the institutional validator operator participate in the multisig for the actions assigned to the Council |
| Performance basis | ETH value per share and net staking performance; USD valuation is shown separately |
| Return treatment | Non-rebasing shares: performance changes the value per share rather than automatically increasing the holder’s token count |
| Redemption | The specified ETH representation paid to the recipient on GIWA through the offered route |
| Liquidity | Standard asset recovery, or Instant through available internal liquidity or an executable OTC quote |
A share is not a fixed claim to one ETH, and it is not sarcoUSD. Native ETH, wrapped ETH and other representations have different execution and recovery conditions. Use the product’s specified asset form for both deposit and payout.
## Capital and data flow
The diagram describes the product design. Chain-to-chain movement, Ethereum staking and GIWA settlement are distinct operations; the arrows do not identify a bridge provider, a single transaction or a guaranteed processing time.
| Stage | What is recorded |
| - | - |
| GIWA deposit | Payment asset receipt, customer and quantity |
| Share allocation | The valuation basis, allocated quantity and recipient’s confirmed GIWA holding |
| Ethereum allocation | Movement through the approved transfer route, destination receipt and staking allocation |
| Validator activation | The validators attributed to the vault and their activation or operating state |
| Recovery | Exit or withdrawal progress and actual ETH receipt at the designated Arco-controlled, MPC-custodied Ethereum withdrawal address |
| GIWA settlement | Return movement, payment readiness and actual receipt by the customer |
Issuing shares does not establish that the corresponding ETH is already active in a validator. Funds awaiting transfer or activation remain separate from actively staked ETH. Likewise, an Ethereum recovery receipt does not establish that the customer has received payment on GIWA.
## Deposits and vault shares
Before depositing, review the accepted asset, network, recipient, valuation time, expected share quantity, applicable costs and participation conditions. Asset spending approval or wallet authorization is separate from a completed deposit and share allocation.
The allocation model uses the accepted ETH-equivalent deposit value and the applicable ETH price per share, with the product’s cost and conversion treatment. Confirm the actual allocated quantity; a transaction hash or deposit acknowledgement alone is not an issued position.
Shares use a non-rebasing model. Staking performance changes their ETH valuation without automatically changing the number held. Losses and costs can reduce that valuation. Transfers, redemption and any additional issuance follow the product’s rules; the LST description does not establish unrestricted transfers, a secondary market or acceptance as collateral.
## Institutional validators and Arco authority
### MPC custody and Security Council
The product design uses MPC-based custody for the GIWA vault and Ethereum asset allocation, including custody of recovered ETH at the designated withdrawal address. MPC signing is distinct from the Security Council multisig: the custody layer coordinates signing through key shares, while the Council supplies the required signatures for the actions assigned to it. Council approval and execution through custody controls are separate records.
Arco and the institutional validator operator participate in the Security Council multisig. Arco remains responsible for withdrawal and recovery authority, exercised within the applicable custody and joint approval controls. The operator's Council role is separate from its validator signing role. The product's permissions and custody policy identify the actions governed by the Council, the signer quorum and execution responsibilities; Council membership alone does not imply unilateral asset movement or control of every vault operation.
| Role | Scope in the design |
| - | - |
| Customer | Authorizes participation and holds the GIWA shares under the product’s terms |
| Arco | Manages vault allocation and records, retains withdrawal and recovery authority under the custody and Council controls, participates in the Council multisig, and connects valuation and redemption settlement |
| Institutional validator operator | Operates validators using validator signing authority and separately participates in the Council multisig for its assigned governance actions |
| Security Council | Provides multisig approval for the actions assigned to it under the vault's permissions |
| MPC custody layer | Executes authorized custody transactions through its signing policy; does not itself establish Council approval or customer payout completion |
Validator deposits must be matched to the designated withdrawal credentials and the vault’s validator records. The operator’s validation signing role is separate from control of the Ethereum withdrawal destination. Arco’s recovery process connects withdrawal authorization, validator exit or partial withdrawal where applicable, and confirmed asset receipt.
Ethereum processes eligible consensus-layer withdrawals under its protocol rules. Council multisig and MPC custody govern their assigned authorization and asset movement functions; they are not an additional signature requirement for each automatic consensus-layer withdrawal. An approved custody transaction does not establish validator activation, network withdrawal completion or receipt by a customer on GIWA.
Execution-layer reward recipients and consensus-layer withdrawal destinations are separate settings. Reward receipts, operator fees and their allocation to the vault are tracked through the applicable arrangements. Validator operation alone does not establish where all rewards are received.
The product uses a custodial structure. A customer holding a GIWA share does not have exclusive direct control of the validator's ETH or the MPC-custodied assets. Product agreements define asset holding and custody responsibilities, holder claims, loss allocation and the scope of administrative powers. MPC and multisig controls do not by themselves establish legal segregation, insurance or an audit.
## ETH price and net APR
### ETH value per share
The valuation relationship is:
**ETH value per share = ETH net assets attributable to shares ÷ shares outstanding.**
The accounting includes ETH held for the vault, validator balances and verified movement or recovery balances, valued on the product’s ETH basis. Outstanding obligations and accrued costs are accounted for before attributing net assets to shares.
| Accounting category | Treatment to keep consistent |
| - | - |
| Liquid and actively staked assets | Attribute balances to the vault and distinguish their availability for payout |
| Movement, activation and recovery in progress | Track the same economic asset through its stages and count it once |
| Staking rewards | Include consensus and execution rewards according to their attribution; rewards already included in a balance are not added again |
| Penalties, losses and costs | Reflect them once, including amounts already deducted in provider or onchain records |
| Deposits awaiting allocation | Keep received funds and the obligation to allocate or return them separate from confirmed shareholder assets |
| Pending redemptions | Reconcile outstanding shares, restricted shares and any fixed payout obligation without counting the same claim twice |
Arco’s valuation design reconciles institutional staking reports with the relevant chain records and vault accounting. Price observations identify their reference time and scope. Missing or stale data is not treated as a current confirmed value. The price publication and transaction validity policies govern which valuation can be used for an offered operation.
The share’s USD value uses its ETH valuation and the relevant ETH/USD price. ETH price movement in dollars is separate from staking performance measured in ETH.
### Vault net APR
Vault net APR describes observed net ETH performance on a stated annualization basis. Display the observation period, capital basis, included rewards and treatment of costs with the rate. An estimated or historical APR is not a fixed return commitment.
An operator’s reported rate may use actively staked capital and a different reward or fee scope. The vault measure also accounts for Arco costs, losses and the effect of liquid buffers and funds awaiting allocation or activation. Fees already deducted from the provider’s reported value are not deducted a second time.
The ETH share price is derived from reconciled net assets. An APR estimate is a separate performance measure; it is not additional ETH to add to the vault’s assets. APR and compounded APY are labeled according to their calculation method. See [NAV and Returns](/transparency/nav-and-returns).
## Standard and Instant Redemption
### Standard Redemption
A Standard request records the shares to redeem, recipient and applicable pricing basis, and restricts the submitted shares while processing. Recovery can use available product assets or require validator withdrawals. Ethereum recovery, return movement and GIWA settlement are followed through to actual payout.
| Checkpoint | Meaning |
| - | - |
| Request accepted | The request and share restriction are recorded; payment is not complete |
| Recovery in progress | Validator withdrawal or asset recovery is underway where required |
| Ethereum receipt confirmed | Recovered ETH has reached the designated Arco-controlled address |
| GIWA payment ready | The supported payout asset is available for the request after return settlement |
| Settlement and payout | Price and costs are applied under the settlement policy, share processing is reconciled, and actual customer receipt is verified |
The settlement policy defines price fixing, the treatment of rewards, losses and costs during the wait, and when shares are burned or a payout obligation is established. Restricted but unburned shares remain part of the outstanding share accounting. After burning, the associated payout obligation is recorded separately until paid.
Ethereum withdrawal and exit queues, chain-to-chain movement and product processing can affect timing. A network estimate is not a guaranteed payout date. Any claim step, cancellation or return procedure follows the offered route’s actual terms. A request receipt or a payment-ready state alone does not establish receipt by the customer.
### Instant Redemption
Instant uses payout assets already available in the GIWA Internal Liquidity Sleeve or an executable OTC arrangement. Available balances are measured after reserved payouts and other restrictions. Ethereum validator balances or ETH awaiting return settlement are not immediately available GIWA payout balances.
For the internal route, review the applicable share price, fee, limits and net receipt. For OTC, review the buyer or liquidity counterparty, firm quote, fees, expiry, token treatment and payment conditions. In an acquisition transaction, shares transfer to the buyer rather than being burned; a separate redemption arrangement follows its own settlement rules.
LST transferability does not guarantee an Instant route or a market price equal to the vault’s ETH valuation. When executable liquidity is unavailable, Standard follows the product’s recovery and settlement process. See [Vault Liquidity Architecture](/liquidity/architecture).
## Illustrative example: deposit to redemption
All numbers below are invented solely to explain the accounting. They are not actual or historical Arco results, a target or forecast APR, market prices, an approved fee schedule, a reserve allocation target or a payout commitment. The same hypothetical position is followed from deposit to redemption. Actual asset forms, valuation, costs, approvals and settlement follow the product's specifications.
### 1. Deposit and share issuance on GIWA
Assume the vault starts with **1,000 ETH of net assets and 1,000 shares**, so its ETH price is **1.000 ETH per share**. A customer deposits the supported GIWA asset with an accepted value of **10 ETH**, with no entry or conversion cost assumed for this example.
| Example step | Calculation or result |
| - | - |
| GIWA deposit confirmed | 10 ETH-equivalent received; share issuance remains a separate outcome |
| Shares allocated | 10 ETH ÷ 1.000 ETH per share = **10 shares** |
| After confirmed issuance | **1,010 ETH** of net assets ÷ **1,010 shares** = **1.000 ETH per share** |
| Customer holding | **10 shares**, initially valued at **10 ETH** |
Before issuance, the received deposit has a corresponding allocation or return obligation. It is not simply added to the existing shareholders' net assets while the share count stays at 1,000. The post-issuance amounts above assume that allocation has completed.
For this example only, assume the pooled vault then has **900 ETH actively staked on Ethereum and 110 ETH liquid**, totaling 1,010 ETH. This is not a target allocation. The customer's 10 ETH participates in the pool; it is not a standalone 10 ETH validator. GIWA custody receipt, MPC execution, required Council approval, Ethereum receipt and validator activation are confirmed separately. The liquid amount is not necessarily available on GIWA or available for payout after other obligations.
### 2. Rewards, costs and losses reflected in ETH price
Assume a **30-day observation period** after issuance, with no further deposits, redemptions or share changes. Invented, reconciled pool results are:
| Example accounting item | ETH amount |
| - | - |
| Starting net assets | 1,010.00 |
| Gross rewards attributed to the vault | +4.04 |
| Operator and Arco costs, counted once | −0.60 |
| Penalties or other losses, counted once | −0.41 |
| Net ETH performance | **+3.03** |
| Ending net assets attributable to shares | **1,013.03** |
**ETH price per share = 1,013.03 ÷ 1,010 = 1.003 ETH.**
The customer still holds **10 shares**, now valued at **10 × 1.003 = 10.03 ETH**. The extra 0.03 ETH is reflected in share value; it is not a separate reward added again to the customer's position. An increase in value does not establish immediate payout liquidity.
### 3. Net APR and USD valuation are separate measures
The hypothetical pool's 30-day net ETH return is **3.03 ÷ 1,010 = 0.30%**. Using a **365-day simple annualization** and the unchanged starting capital basis:
**Illustrative net APR = 0.30% × 365 ÷ 30 = 3.65%.**
This is an annualized description of the invented 30-day observation, not an actual staking rate, a projection for the next year or compounded APY. It uses total vault capital, including the assumed liquid assets, and includes the stated costs and losses. A provider rate based only on actively staked ETH would use a different basis. The customer's value is derived from the reconciled share price, not by adding 3.65% to the assets.
For a separate currency example, assume ETH/USD moves from **USD 2,000 to USD 1,800**:
| Customer valuation | Calculation |
| - | - |
| Initial USD value | 10 ETH × USD 2,000 = **USD 20,000** |
| Ending USD value | 10.03 ETH × USD 1,800 = **USD 18,054** |
| USD change | **−USD 1,946 (−9.73%)**, despite the hypothetical +0.30% ETH return |
Prices can also fall in ETH terms. In an alternative loss case, a **3.03 ETH net loss**, rather than the gain above, would leave **1,006.97 ETH ÷ 1,010 shares = 0.997 ETH per share**. The same 10 shares would be worth **9.97 ETH** before redemption costs. This is a separate scenario, not an additional loss applied to the gain case.
### 4. Standard Redemption through confirmed payout
Return to the gain case. Assume the customer redeems all **10 shares**, the example policy fixes the price at settlement at **1.003 ETH**, and no redemption, transfer or conversion costs are charged in this example. Assume no additional performance changes during processing. The actual product's price-fixing point, waiting-period performance treatment and costs may differ.
| Example checkpoint | Position or payment meaning |
| - | - |
| Request accepted | 10 shares are restricted; the customer has not received ETH |
| Asset recovery, if required | Necessary custody approvals, Ethereum recovery and return movement are tracked; approval or Ethereum receipt alone is not a GIWA payout |
| GIWA payment ready | The supported payout asset is available for the request; payment is still pending |
| Settlement | 10 shares × 1.003 ETH = **10.03 ETH-equivalent** payable under the example's zero-cost assumption |
| Payout confirmed | The customer's receipt of **10.03 ETH-equivalent in the specified GIWA asset** is verified and the request is complete |
For the following accounting illustration, assume the observation-period costs have been paid, losses are already reflected in asset balances and no other obligations remain. To illustrate a burn before payment, assume settlement burns the 10 shares and records the 10.03 ETH payout obligation. While unpaid, **1,013.03 ETH of assets − 10.03 ETH owed = 1,003 ETH attributable to the remaining 1,000 shares**, still **1.003 ETH per share**. After payment, assets are 1,003 ETH and that payout obligation is zero. Burning shares does not make an unpaid obligation disappear. This timing is an example accounting policy, not a claim about the released contract's burn behavior or a guaranteed processing time.
### 5. Alternative Instant outcomes
These are alternative quotes for the same 10 shares in the gain case, not extra payouts after Standard Redemption:
| Hypothetical route | Illustrative customer receipt and token treatment |
| - | - |
| Internal Liquidity Sleeve | Assume executable GIWA liquidity, a gross value of 10.03 ETH and an invented fixed fee of 0.05 ETH: **9.98 ETH-equivalent net receipt**. Share processing follows the internal redemption policy. |
| OTC acquisition | Assume a firm quote of **9.97 ETH-equivalent net**, including all assumed quote costs. The buyer acquires the **10 shares by transfer**, so the acquisition itself does not reduce the vault's 1,010 outstanding shares. |
Neither quote is an actual Arco offer or fee. Actual availability, expiry, costs and payment conditions must be checked before acceptance, with asset authorization and verified receipt recorded separately. Council participation and MPC custody do not guarantee an Instant quote or eliminate withdrawal queues.
## Eligibility and risk
Participation and transfers follow the product’s investor, jurisdiction, account and wallet conditions. API access or wallet connection does not establish eligibility or authorize asset movement.
Staking penalties and slashing, operator performance, asset representation, chain-to-chain movement, valuation, contracts, custody, administrative authority and liquidity affect the product's value and recoverability. Custody compromise, unavailable MPC signing participants or unavailable Council signers can impair authorized operations or delay recovery. Institutional operation does not guarantee principal, returns or uninterrupted redemption. Operator responsibilities and any loss recovery obligations follow the applicable agreements.
Read the product’s rights, costs and asset control arrangements alongside [Terms and Risks](/security/terms-and-risks) and [Security and Operations](/security/operations).
## Frequently asked questions
### Does a GIWA deposit directly activate an Ethereum validator?
Deposit receipt and share allocation are separate from Ethereum transfer, validator allocation and activation. Pending assets and actively staked balances are recorded separately.
### Do rewards increase my share balance?
In this non-rebasing design, rewards, losses and costs change the ETH value per share. Additional deposits and other supported token operations can change the quantity held; a price update alone does not.
### Is the validator operator in control of the withdrawal address?
Arco retains withdrawal address and recovery authority within the MPC custody and applicable Security Council approval framework. The institutional operator performs validator duties and separately participates in the Council multisig. That participation does not give the operator unilateral withdrawal control; its permissions follow the assigned Council scope. Reward recipients, fees and operational permissions are identified separately.
### Are MPC custody and the Council multisig the same control?
They are separate layers. MPC coordinates custody signing through key shares; the Council multisig supplies signatures for its assigned actions. The applicable permissions connect approval to execution. Neither an approval nor a signature proves that assets have reached Ethereum validators or the customer's GIWA wallet.
### Does an Ethereum withdrawal mean my GIWA redemption is complete?
ETH recovery on Ethereum and customer payment on GIWA are separate outcomes. Follow the original request through return settlement and verified receipt.
## Design references and related guides
The following explain relevant staking mechanisms and design patterns. They are references, not a statement that Arco uses their contracts, tokens, operators or APIs.
* [Ethereum staking withdrawals](https://ethereum.org/staking/withdrawals/) — withdrawal authority and network recovery stages.
* [MPC and multisignature background](https://www.fireblocks.com/report/digital-asset-custody-and-transaction-processing-leading-practices-using-fireblocks-mpc-solution) — custody signing and multisignature distinctions; a technical reference, not an Arco custody provider appointment.
* [Lido stVaults roles and permissions](https://docs.lido.fi/run-on-lido/stvaults/concepts-and-reference/roles-and-permissions/) — separation of vault-owner and validator-operator authority.
* [StakeWise Vaults](https://docs.stakewise.io/docs/vaults/intro) — individual staking vaults and optional vault tokens; osETH is a separate collateralized token model.
* [Kiln pooled staking integration](https://docs.api.kiln.fi/docs/kiln-on-chain-pooled-staking) — partner shares, performance data and exit-to-claim flows.
For partner integrations, start with [Distribution OS](/distribution-os/overview) and the [Integration Guide](/resources/developer-guide). Its pinned EVM examples do not establish this staking product’s execution interface. Use the selected product’s actual release specification for calls, addresses, permissions and completion records.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.