Vault architecture (V3.2)

psXDC V3 is a complete rebuild of the liquid staking contract, moving from a custodial model to a fully non-custodial, ERC-4626 tokenized vault. This is the architecture underpinning every new psXDC stake. V3.2 keeps this architecture and makes the partially-backed state the permanent operating model (the "permanent ledger"): rewards accrue at any backing level through a manager-only reward lane, NAV is protected against write-downs, and the withdrawal queue is settled from ring-fenced funding lanes so fresh deposits are never consumed by the redemption backlog and user exits keep working throughout.

---

Overview

---

How It Works

1. Stake

Deposit XDC through the staking interface. The contract mints psXDC shares based on the current exchange rate. The more rewards the vault accumulates, the more XDC each psXDC share is worth.

There is no minimum deposit. Staking is permissionless: no account, no KYC, just connect your wallet.

2. Earn Rewards

Your staked XDC is pooled and delegated to KYC-verified masternode operators on the XDC Network. Validator rewards flow back into the contract automatically, increasing the total assets backing all psXDC shares.

You don't need to claim rewards. They are embedded in the share price, so your psXDC simply becomes worth more XDC over time.

3. Withdraw

You have full self-service access to your XDC:

• Instant withdrawal: if the contract has sufficient liquid XDC, you redeem shares and receive XDC in the same transaction. No admin approval. No waiting.
• Queued withdrawal: if the vault's free liquidity is too low, your request enters an automatic FIFO queue. The queue is paid from its own ring-fenced budget (queueBackingBudget), which the team tops up as masternode principal is unwound and returned; escrowed shares are valued at the exchange rate of the moment they are paid, so queued positions keep earning.
• DEX swap: sell psXDC directly on a DEX (verify the pool holds the live V3.2 token) for immediate exit at market rate.

4. Use psXDC

psXDC is a standard ERC-20 token on the XDC Network. While your XDC earns yield in the background, you can:

• Hold to accumulate rewards passively
• Trade on DEXs
• Use as collateral in DeFi protocols that support ERC-4626 vault tokens
• Transfer to any wallet; the recipient inherits the yield automatically

---

Share-Based Pricing

The vault uses a share model:

Example: If the exchange rate is 1.05, burning 100 psXDC returns 105 XDC. The rate only goes up (assuming no validator losses).

This is the same model used by major DeFi protocols (Aave aTokens, Compound cTokens, Lido wstETH).

---

Masternode Integration

V3 directly stakes XDC with masternodes via the on-chain XDC validator contract. This is what makes psXDC productive: your XDC is not sitting idle.

How masternodes are managed

Liquidity buffer

V3.2 has no percentage buffer target (the earlier bufferBps knob was removed). Whatever XDC the vault holds that is not earmarked for the queue or for failed payouts is available for instant withdrawals, and the queue has its own separate budget. In practice:

• Most XDC is working in masternodes earning yield
• A buffer remains in the contract for immediate redemptions
• If the buffer is depleted, the withdrawal queue handles the overflow automatically

---

Governance & Roles

V3 separates responsibilities across five roles. No single key can make unilateral changes.

Time-locked changes

Every sensitive parameter change follows a three-step pattern:

1. Schedule the change → mandatory governance delay begins (default 1 day)
2. Wait, during which anyone can see the pending change on-chain
3. Execute the change after the delay expires, or cancel it at any time

This applies to: role changes, loss caps, governance delay itself, ownership transfer, and migration bridge configuration.

---

Risk Controls

---

Smart Contract Details

---

Withdrawal Queue Internals

When liquidity is constrained the queue absorbs the overflow without disrupting validator operations:

• Queued requests escrow shares inside the vault. They are not burned until settlement.
• Settlement value is computed at processing time, not at enqueue time. The user redeems at the live share rate, not a stale snapshot.
• Failed receiver payouts (rare; e.g. contract receivers that revert on payment) are deferred into pendingQueuedAssets. Users collect their XDC via claimQueuedAssets(receiver) later.
• Auto-propose is blocked while the queue has a backlog, so the vault doesn't lock more XDC in masternodes while users are waiting to withdraw.
• Operator and queue scans are bounded by operatorScanLimit and queueScanLimit to prevent gas-griefing.

→ Withdrawals: Instant vs Queued (user guide)

---