The arclUSDC vault

arclUSDC is a USDC vault on Arc. You deposit USDC and receive arclUSDC; the share price is the only thing that moves. This page is the long version of everything the vault page states in one line.

What arclUSDC is

An ERC-4626 vault. Deposit USDC, receive shares, redeem shares for USDC. There is no rebase, no reward to claim and no lock-up: your share count stays where you left it and the share price is what changes. It starts at exactly 1.000000 and moves only on realised profit and on recognised loss.

Where the money goes

Three places, at target weights of 10% idle, 30% on Arc in Bitwise PAPY, and 60% on Base in Morpho vaults curated by Gauntlet and Moonwell. Each venue is capped at 20% of that venue’s own size, so no single curator holds the majority of the money.

Read those numbers carefully. They were measured on chain on 2026-09-23 and they are the venues’ rates, gross of this vault’s 10% performance fee. They are not a prediction and they are not what arclUSDC pays: roughly a tenth of the vault sits idle earning nothing by design, money in transit over the bridge earns nothing at all, and bridge and keeper gas comes out of the vault. Blending them into a single headline figure would produce a number larger than any holder receives and impossible to check. That is why there is no yield figure on the vault page — only the share price, and what it has actually done since launch.

Why you cannot always withdraw all of it

Up to 60% of the vault is on Base, a bridge round trip away. Redemption is instant for whatever is liquid on Arc right now — the idle buffer plus whatever PAPY will release in the same transaction — and that is what maxRedeem reports.

That liquidity is one shared pool, first come first served. It is not a personal allowance. If the vault holds $1.6M liquid and there are $4M of shares outstanding, every holder is shown a maximum drawn from the same $1.6M, and two people can each be told they may redeem $400,000 when only one of them can. The vault page leads with the vault-wide figure for exactly this reason, refuses to submit a quote more than 15 seconds old, and simulates every redemption before asking you to sign it.

When the rest comes home is not something anyone can promise. A keeper moves funds back from Base; there is no queue you can join, no request you can file, and nothing on chain that lets a holder pull the Base leg home on demand.

Why gains appear slowly and losses appear at once

When the keeper brings money back from Base, the profit is recognised and then released into the share price linearly over 7 days. Without that, the price would step up in a single block and anyone watching could deposit immediately before the step and redeem after it, taking a share of yield they were not invested for.

A loss is not smoothed. If principal on Base is written off, the share price falls in one block, in full. The asymmetry is deliberate: delaying a loss would let people leave at a price the vault can no longer honour, at the expense of whoever stayed.

A consequence worth knowing before you deposit: the share price excludes anything the Base leg has earned but not yet brought home. The Base position is carried at what it cost, because nothing on Arc can read what it is currently worth. If the Base leg is up, a deposit made today buys in slightly cheap and a redemption made today sells slightly cheap.

The two pauses

A precautionary pause stops deposits and nothing else. It means the owner wants no new money arriving while something is looked at. No loss has been recognised, and lifting it is a single transaction with no waiting period.

A markdown pause is set when principal is written off. It stops deposits and cannot be lifted for 48 hours — deliberately, so that holders can leave at the marked-down price before new deposits can arrive at it. If it could be lifted instantly the protection would be one transaction deep and worth nothing.

Redemptions are never pausable. Not by the owner, not by a keeper, not by this interface. There is no function in the vault that stops them. The only thing that can limit a redemption is how much USDC is liquid at that moment.

The Arc USDC blocklist

USDC on Arc is Circle’s, and Circle operates a blocklist at the protocol level on this chain. A transfer to or from a blocked address fails regardless of balance or approval. If your address is blocked, deposits and redemptions both fail, and the failure has nothing to do with Arclight — it is not a restriction Arclight applies and not one Arclight can lift. The vault page checks before you sign and tells you plainly; if the check itself cannot be made, the transaction is simulated and the reason is reported as what it is.

The fee

10% of yield, taken only when profit is realised, and never on principal. There is no management fee and no deposit or withdrawal fee. A high-water mark applies: a vault recovering from a loss owes nothing until the share price is genuinely above where it last peaked. The rate can be changed by the owner, but it is capped at 20% in the contract code and no owner action can raise it past that. Raising it at all waits 48 hours.

What the operators can and cannot do

They can pause deposits, unwind the Arc leg to idle USDC, lower the fee, write down the Base leg, and move money between the hardcoded venues. Every destination address is fixed in the contracts. They cannot send the money anywhere else, cannot take principal, cannot stop a redemption, and cannot raise the fee past the coded cap. A compromised keeper can cause delay — money sitting in the wrong place for a while — rather than theft.

If the keeper goes silent

The Base leg depends on a keeper to bring money home. If that keeper stops — for any reason — the vault would otherwise be stuck with up to 60% of its assets on the wrong chain. So bridgeHome() on the Base-side contract becomes callable by anyone after 7 days of keeper silence, and the destination it sends to is hardcoded: back to the Arclight vault on Arc. Anyone can restart the flow; nobody can redirect it.

This app is pinned to Arc and cannot make the call for you, and it cannot show you a countdown either — the keeper’s last action is recorded on Base, and nothing on Arc exposes it. Rather than invent a number, here is the exact recipe:

# On Base, once the keeper has been silent for 7 days.
# ArclightRemoteVault.bridgeHome() becomes callable by anyone.
# Destinations are hardcoded in the contract: the funds can only go back
# to the Arclight vault on Arc. You pay the gas; you receive nothing extra.

cast send <ArclightRemoteVault on Base> "bridgeHome()" \
  --rpc-url https://mainnet.base.org \
  --private-key <your key>

# Or, without a terminal: open the contract on basescan.org, go to
# Contract -> Write Contract, connect a wallet, and call bridgeHome.

Addresses

ARCLIGHTREMOTEVAULT (BASE) shares its address with Arclight Builder V3 on Arc. Same deployer, nonce 0 on each chain, so CREATE derives the identical hex value on both — they are unrelated contracts that happen to land on the same address. The chain is what tells them apart; confirm you are on Base before sending anything to it.