#How It Works

ARU runs on a simple two-step flow: you submit a request, the multisig reviews and approves it within the price bounds you specified. Every step has explicit safeguards. This page shows exactly what happens where.

#The minting flow (USDC → ARU)

sequenceDiagram
    autonumber
    participant AP as AP wallet
    participant SM as Subscription Manager
    participant MS as Multisig
    participant T as Treasury

    AP->>SM: requestSubscription(usdcAmount, maxPricePerARU)
    Note over AP,SM: USDC → contract (not treasury yet)
    SM-->>AP: request ID + 48h expiry

    rect rgb(240, 248, 255)
    Note over MS: Review live NAV vs AP's maxPrice<br/>AutoSigner co-signs if within tolerance<br/>2 humans countersign
    end

    MS->>SM: approveSubscription(id, pricePerARU)
    Note over SM: Reverts if pricePerARU > maxPricePerARU
    SM->>AP: ARU minted
    SM->>T: USDC released

    Note over AP: Alternative paths:<br/>AP cancelSubscription(id) any time<br/>OR anyone cancelExpiredSubscription(id) after 48h

#What happens step by step

#	Actor	Action	Safeguard
1	AP	Calls requestSubscription(100_000 USDC, 1.15 × 10¹⁸) meaning "deposit 100k USDC, don't mint at a price worse than $1.15 per ARU"	AP allowlist check (isAP[msg.sender]); subscription-pause flag; minimum amount floor; open-request cap (50 per AP)
2	Contract	USDC transfers from AP → Subscription Manager contract (not treasury). Request struct stored with priceBound, createdAt, expiresAt = now + 48h, fulfilled = false	USDC custody is in immutable contract; treasury never sees pending mint USDC, so it can't accidentally spend it
3	Multisig	Reviews the request on the ops dashboard. Compares current NAV to AP's maxPricePerARU. Proposes approveSubscription(id, pricePerARU) tx	AutoSigner reads 3 NAV sources (Redstone + BlackRock IAU ref + internal model); co-signs only if within 100 bps tolerance. Humans independently verify
4	Contract	Verifies pricePerARU ≤ maxPricePerARU (reverts if not), marks request fulfilled, atomically: mints ARU to AP + transfers USDC from contract to treasury	Price bound enforcement is on-chain. No off-chain trust that admin respects it. Contract reverts if admin tries to settle at a worse price than AP agreed to

#If the multisig doesn't approve within 48h

sequenceDiagram
    participant A as Anyone
    participant SM as Subscription Manager

    Note over SM: Request expired (>48h since createdAt)
    A->>SM: cancelExpiredSubscription(id)
    SM->>SM: mark fulfilled=true (poison ID)
    SM-->>A: (caller pays gas; no reward)
    Note over SM: USDC returns to original AP address

Anyone can call cancelExpiredSubscription — a keeper, another AP, the original AP themselves. The refund always goes to the original AP, not the caller. This means your USDC is never stuck waiting on admin availability.

#If you change your mind before approval

AP calls cancelSubscription(id)
  → USDC returns to AP immediately
  → request ID becomes non-approvable

No cooldown. No admin cooperation needed. Common reasons to cancel:

• Market moved; you want to resubmit at a tighter bound
• You typed the wrong amount
• You need your USDC back for another purpose

#The redemption flow (ARU → USDC)

sequenceDiagram
    autonumber
    participant AP as AP wallet
    participant SM as Subscription Manager
    participant MS as Multisig
    participant T as Treasury

    AP->>SM: requestRedemption(aruAmount, minPricePerARU)
    Note over AP,SM: ARU → contract (escrowed, NOT burned)
    SM-->>AP: request ID + 48h expiry

    rect rgb(240, 248, 255)
    Note over MS: Review NAV vs AP's minPrice<br/>AutoSigner + humans as above
    end

    MS->>SM: approveRedemption(id, pricePerARU)
    Note over SM: Reverts if pricePerARU < minPricePerARU
    T->>SM: USDC transferFrom
    SM->>AP: USDC
    SM->>SM: burn escrowed ARU

    Note over AP: Alternative paths:<br/>AP cancelRedemption(id) any time → ARU returned intact<br/>OR cancelExpiredRedemption(id) after 48h → ARU returned intact

#Key property: your ARU is safe until actually settled

Unlike some other RWA tokens (Ondo USDY burns on request), ARU stays intact in the contract during the pending window. It's only burned at the exact moment USDC lands in your wallet. If the treasury can't pay (insufficient USDC), approveRedemption reverts and your ARU remains untouched — you reclaim it after 48h expiry.

#	Actor	Action	Safeguard
1	AP	Calls requestRedemption(50_000 ARU, 1.05 × 10¹⁸) meaning "redeem 50k ARU, don't settle below $1.05 per ARU"	AP allowlist, redemption-pause flag, minimum amount floor, open-request cap
2	Contract	ARU transfers from AP → Subscription Manager (escrowed, not burned)	ARU is held intact until settlement actually completes
3	Multisig	Reviews + checks treasury has sufficient USDC	If treasury is thin, admin pauses new redemption requests and/or liquidates gold first
4	Contract	Verifies pricePerARU ≥ minPricePerARU, atomically: transfers USDC from treasury to AP + burns escrowed ARU	Both sides fire or neither does. If treasury transfer reverts, ARU stays escrowed

#What happens if treasury runs dry mid-queue

sequenceDiagram
    participant MS as Multisig
    participant SM as Subscription Manager
    participant T as Treasury (insufficient USDC)
    participant AP as AP wallet

    MS->>SM: approveRedemption(id, price)
    SM->>T: transferFrom USDC
    T-->>SM: REVERT (insufficient balance)
    Note over SM: Entire approval reverts.<br/>ARU remains escrowed.<br/>No partial state.

    Note over MS,AP: Admin pauses new redemptions,<br/>treasury liquidates gold to USDC,<br/>retries approval later.

    Note over AP: OR: 48h elapses, AP reclaims ARU<br/>via cancelExpiredRedemption(id)

Worst case is delay, never loss. The multisig cannot burn your ARU without successfully paying you USDC. The two operations are atomic — both succeed or both revert.

#Request lifecycle (state diagram)

stateDiagram-v2
    [*] --> Pending: AP submits request
    Pending --> Approved: Multisig approves within bound
    Pending --> Cancelled: AP cancels (any time)
    Pending --> Expired: 48h elapsed
    Expired --> Reclaimed: Anyone calls cancelExpired*

    Approved --> [*]: Funds settled
    Cancelled --> [*]: Funds returned
    Reclaimed --> [*]: Funds returned

    note right of Approved
        Settlement price was within
        AP's stated bound. ARU minted
        (or USDC paid + ARU burned).
    end note

    note right of Reclaimed
        Permissionless: any address
        can trigger the refund. Funds
        always go to original AP.
    end note

Every pending request ends in one of three terminal states: Approved (settled successfully), Cancelled (AP withdrew), or Reclaimed (expired and refunded by keeper). There is no "stuck" state. There is no "partially settled" state.

#Security precautions — summary

#On-chain enforced (no one can bypass)

Protection	Mechanism
Price bound	Every request carries AP's priceBound. Approval transaction reverts if admin tries to settle outside the bound. Your explicit consent, captured immutably.
48-hour expiry	After createdAt + 48h, the request can be cancelled by anyone (not just the admin or AP). Funds return to original AP.
User cancel anytime	cancelSubscription(id) / cancelRedemption(id) callable by the AP at any point before approval. No cooldown. Funds return immediately.
Atomic settlement	Approval either mints ARU + releases USDC (subscription) or pays USDC + burns ARU (redemption) in the same transaction. No half-settled states.
Subscription isolation from treasury	Pending mint USDC is held in the contract, not the treasury. Even if treasury is drained or frozen, your pending mint is refundable.
Redemption ARU is escrowed, not burned	Until approval actually fires, your ARU remains in the contract intact. Treasury insolvency can't cause ARU loss.
AP allowlist	Only allowlisted APs can submit requests. Protects the protocol's KYC/AML perimeter.
Immutable contracts	No proxy, no upgrade, no admin-installable backdoor. What deploys is what runs forever.
Multi-minter with 48h timelock	ARU's minter set changes require a 48h delay visible on-chain. Any adversarial minter addition has a 48h public window for response.

#Operationally enforced (multisig discipline)

Protection	Mechanism
3-of-5 multisig approval	Every settlement needs 3 of 5 signers. One-signer compromise insufficient.
AutoSigner NAV gate	Automated signer participates in the multisig; co-signs only if proposed price is within 100 bps of NAV from 3 independent sources. Fails open: pure human quorum always works if AutoSigner is down or refuses.
Multi-source NAV	Oracle price + BlackRock IAU reference + internal NAV model. Inter-source divergence check (sources must agree within 500 bps).
Treasury separation	Treasury is a separate Safe with its own signers. Manager contract pulls USDC via allowance; treasury can revoke at any time.
Cold owner multisig	The role that controls minter add/remove is a different Safe from operational MANAGER_ADMIN. Even full compromise of operations can't mint ARU without owner cooperation via 48h timelock.

#Structural (by design)

Protection	Mechanism
No pause on transfers	ARU tokens transfer freely on the secondary market regardless of primary-market state. Your ability to hold or sell on DEX is never revoked.
No blocklist	No authority can freeze your ARU.
No rebasing, no fee-on-transfer	Balance arithmetic is simple ERC-20. DEX integrations work without special handling.
Chainlink-compatible price feed	ARUPriceOracle implements AggregatorV3Interface with an additional strict variant for consumers wanting hard-fail on stale.

#The trust summary in one sentence

You trust the multisig to approve requests within your stated bounds within 48 hours; if they don't, you (or anyone) reclaim your funds; if the treasury is insolvent, your pending positions remain safe and reclaimable.

Nothing you submit can be lost to contract logic, admin bounded misbehavior, or operational stalling. The 48h expiry with permissionless reclaim is the ultimate safety valve.

#Reading further

• Subscribing — detailed mint walkthrough with gas estimates and code samples
• Redeeming — detailed burn walkthrough
• Safeguards — exhaustive list of every protection in the system
• Contracts & Addresses — ABIs and integration reference