Epoch-Based Batching is a settlement mechanism that collects deposit and redemption requests over a defined time period (an epoch), then processes all requests simultaneously at a single Net Asset Value (NAV). This pattern is fundamental to ERC-7540 implementations for Real-World Assets (RWAs), ensuring fair pricing for all participants, preventing front-running of NAV updates, and enabling efficient coordination between on-chain requests and off-chain settlement processes.

The concept borrows from traditional fund administration where investor orders are batched and processed at daily NAV cutoffs. On blockchain, epoch-based batching adapts this model to handle exogenous liquidity while maintaining the fairness guarantees institutional investors expect.

Epoch Lifecycle

A typical epoch progresses through distinct phases:

1. Request Collection (Open Period) The epoch is open for deposits and redemptions. Users call requestDeposit or requestRedeem, and the vault records their requests with associated parameters (amounts, controllers, timestamps). Assets and shares may be locked or transferred to holding contracts. No shares are minted, no assets are released—only commitments are recorded.

2. Epoch Close (Submission Deadline) The request window closes. After this point, no new requests are accepted for the current epoch. This creates a clear boundary: all requests in the batch are known, and no one can submit last-minute requests to exploit upcoming NAV information.

3. NAV Calculation (Price Determination) The protocol calculates the epoch's NAV. For RWA vaults, this typically involves: off-chain asset valuation (custodian reports, market prices), oracle updates pushing NAV on-chain, and forward pricing ensuring the rate reflects current values. This step may take time if dependent on T+1/T+2 settlement.

4. Batch Processing (Fulfillment) All requests are processed at the single epoch NAV. Depositors receive shares calculated as assets * totalShares / epochNAV. Redeemers receive assets calculated as shares * epochNAV / totalShares. Every participant in the epoch gets the same effective price—no timing advantage exists.

5. Claim Period (User Finalization) Users claim their results. For deposits, they receive minted shares. For redemptions, they receive assets (or stablecoins representing liquidated assets). Claims may happen immediately after batch processing or within a subsequent window.

Why Batching Matters for RWAs

Anti-Front-Running: Without batching, users could observe pending requests or anticipated NAV changes and strategically time their own requests. With batching: NAV is unknown until after submission closes, all epoch participants get identical pricing, and no information advantage from transaction timing.

Operational Efficiency: Processing requests individually requires per-request off-chain coordination (wire transfers, custodian instructions). Batching: aggregates capital flows (single wire for all deposits), reduces operational overhead, and amortizes gas costs across participants.

Fairness Guarantee: Institutional investors require assurance that they won't be disadvantaged by other participants' timing. Batching provides: same price for all epoch participants, no preferential treatment based on submission time, and auditable fairness (all prices verifiable against epoch NAV).

Liquidity Management: RWA vaults often have limited liquidity. Batching: aggregates redemption demand for efficient liquidation, enables matching (deposit inflows offset redemption outflows), and prevents liquidity fragmentation from ad-hoc processing.

Implementation Patterns

Time-Based Epochs

Most common approach—fixed duration epochs:

1uint256 public constant EPOCH_DURATION = 24 hours;
2uint256 public currentEpochStart;
3
4function requestDeposit(uint256 assets, address controller, address owner) external {
5    require(block.timestamp < currentEpochStart + EPOCH_DURATION, "Epoch closed");
6    // Record request for current epoch
7}
8
9function closeEpoch() external {
10    require(block.timestamp >= currentEpochStart + EPOCH_DURATION, "Epoch not finished");
11    // Calculate NAV, process batch
12    currentEpochStart = block.timestamp;
13}

Centrifuge uses 24-hour epochs aligned with traditional market closes. Users can submit requests anytime during the epoch, with processing occurring after the epoch closes.

Threshold-Based Epochs

Alternative approach—epochs close when conditions are met:

1uint256 public constant MIN_EPOCH_DURATION = 4 hours;
2uint256 public constant MAX_PENDING_VALUE = 1_000_000e18;
3
4function maybeCloseEpoch() internal {
5    if (pendingValue >= MAX_PENDING_VALUE || 
6        block.timestamp >= currentEpochStart + MIN_EPOCH_DURATION) {
7        closeEpoch();
8    }
9}

This allows faster processing when demand is high while maintaining minimum batching windows for low-activity periods.

Hybrid Epochs

Some protocols combine approaches:

• Minimum epoch duration (ensure batching window)
• Maximum epoch duration (guarantee processing frequency)
• Emergency closure conditions (extreme market events)
• Admin override (regulatory requirements)

Epoch Accounting

Managing request state across epochs requires careful accounting:

Pending Requests: Each request tracks: epoch submitted, amount committed, controller/owner, and current status. Requests can only be fulfilled after their epoch's NAV is set.

Epoch NAV Snapshots: Each epoch stores its NAV at close. This enables: share/asset calculations for fulfillment, historical verification (auditing), and late claims (users claiming after epoch).

Waterfall Processing: For tranched structures (Centrifuge), epochs process in priority order: senior tranche redemptions first (guaranteed liquidity), junior tranche redemptions second (if liquidity remains), then deposits allocated to tranches. This ensures structural protections are maintained.

Security Considerations

Epoch Boundary Manipulation: If epoch close timing is predictable, attackers might: submit large requests just before close to influence processing order, delay transactions to miss unfavorable epochs, or coordinate with miners/sequencers for timing advantages. Defense: randomized close windows, commitment schemes, and order-independent processing.

NAV Oracle Attacks: The batch processing depends on accurate NAV. Attacks include: oracle manipulation before NAV snapshot, delayed NAV updates trapping users in stale epochs, or sandwich attacks around NAV updates. Defense: multi-source NAV, TWAP calculations, and circuit breakers on unusual movements.

Dust Attack Stalling: Many small requests could: fill processing capacity without meaningful value, increase gas costs for batch processing, or delay legitimate users. Defense: minimum request sizes, processing priorities, and gas cost allocation to requesters.

Cross-Epoch Arbitrage: If users can predict NAV direction, they might: deposit before expected NAV increase, redeem before expected NAV decrease, or cancel requests if NAV moves unfavorably. Defense: forward pricing, cancellation restrictions, and epoch timing uncertainty.

Liquidity Mismatch: If redemption requests exceed available liquidity: epoch processing may fail, users may receive partial fulfillment, or processing may be indefinitely delayed. Defense: redemption gates, queue management, and clear communication of liquidity constraints.

Audit Checklist for Epoch-Based Systems

1. Epoch Boundaries: Are open/close times clearly defined? Can timing be manipulated?
2. NAV Calculation: When is NAV determined relative to epoch close? Who can update it?
3. Processing Order: Does processing order matter? Is it deterministic and fair?
4. Partial Fulfillment: How are insufficient liquidity scenarios handled?
5. Cancellation Rules: Can users cancel pending requests? Under what conditions?
6. State Consistency: Are epoch transitions atomic? Can requests span epochs incorrectly?
7. Gas Limits: Can batch processing exceed block gas limits? What's the fallback?
8. Claim Deadlines: Do unclaimed results expire? What happens to orphaned claims?

Epoch Configuration Tradeoffs

Most RWA implementations choose 24-hour epochs to align with traditional market NAV calculations while providing daily liquidity for investors.

Real-World Implementations

Centrifuge: 24-hour epochs with waterfall processing. Senior tranches receive priority on redemptions. NAV calculated from Centrifuge Chain oracle aggregating off-chain asset valuations. Epoch submission via on-chain calls, claiming via separate transactions.

Maple Finance: Withdrawal windows function as epochs. Lenders request withdrawals, which are queued until the next window opens. Processing depends on pool liquidity and may be partial. Multiple-day epochs for institutional lending pools.

Ondo OUSG: Daily epochs aligned with US market close. Subscription/redemption requests collected during the day, processed at 4 PM ET NAV. Institutional-grade batching matching traditional fund administration.

Understanding epoch-based batching is essential for evaluating asynchronous vault security and UX. The mechanism provides critical fairness guarantees for institutional adoption while introducing complexity around timing, state management, and liquidity coordination. Auditors must verify that epoch boundaries prevent timing attacks, NAV calculations are manipulation-resistant, and edge cases (partial fills, expired claims, epoch transitions) are handled correctly.