> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/reserve-protocol/reserve-index-dtf/llms.txt
> Use this file to discover all available pages before exploring further.

# Chain Assumptions

> Blockchain requirements and assumptions for Reserve Folio deployment

## Overview

Reserve Folio is designed to work on EVM-compatible chains that meet specific requirements. Understanding these assumptions is critical for safe deployment and operation.

## Block Time Requirements

<Card title="Maximum Block Time: 30 seconds" icon="clock">
  The chain is assumed to have block times equal to or under **30 seconds**.

  This assumption affects:

  * Auction timing precision
  * Fee accrual calculations
  * Timelock delay effectiveness
  * Rebalance TTL behavior
</Card>

<Warning>
  Deploying on chains with block times exceeding 30 seconds may result in:

  * Imprecise auction pricing
  * Suboptimal execution timing
  * Fee calculation drift
</Warning>

## Compatible Chains

Reserve Folio is compatible with chains that meet these criteria:

<Steps>
  <Step title="EVM Compatibility">
    Must be fully EVM-compatible with standard Solidity contract support
  </Step>

  <Step title="Block Time">
    Block time ≤ 30 seconds (see above)
  </Step>

  <Step title="Block Timestamp Reliability">
    Block timestamps must be reasonably accurate and monotonically increasing
  </Step>

  <Step title="Standard Token Support">
    Must support standard ERC20 token implementations
  </Step>
</Steps>

### Supported Networks

<CardGroup cols={2}>
  <Card title="Ethereum Mainnet" icon="ethereum">
    **Block Time:** \~12 seconds

    **Status:** ✅ Fully supported
  </Card>

  <Card title="Base" icon="b">
    **Block Time:** \~2 seconds

    **Status:** ✅ Fully supported
  </Card>

  <Card title="Arbitrum" icon="circle">
    **Block Time:** \~0.25 seconds

    **Status:** ✅ Fully supported
  </Card>

  <Card title="Optimism" icon="o">
    **Block Time:** \~2 seconds

    **Status:** ✅ Fully supported
  </Card>

  <Card title="Polygon" icon="triangle">
    **Block Time:** \~2 seconds

    **Status:** ✅ Fully supported
  </Card>
</CardGroup>

<Info>
  The protocol can theoretically work on any EVM chain meeting the requirements, but the above networks are the most commonly targeted.
</Info>

## Timing Considerations

### Auction Timing

Auction prices decay continuously based on block timestamps:

```solidity theme={null}
// Price calculation based on timestamp
function getBid(
   uint256 auctionId,
   IERC20 sellToken,
   IERC20 buyToken,
   uint256 timestamp,
   uint256 maxSellAmount
) external view returns (uint256 sellAmount, uint256 bidAmount, uint256 price);
```

<Note>
  The first block may not have a price of exactly `startPrice` if it does not occur on the exact `start` timestamp. Similarly, the final block may not hit exactly `endPrice`.
</Note>

### Fee Accrual

<Card title="Fee Inflation: Every 24 Hours" icon="percent">
  Starting with version 4.0.0, fee inflation is accounted for every 24 hours rather than every block.

  This change:

  * Has no performance impact
  * Is equivalent to previous per-block behavior
  * Allows for more flexibility
  * Reduces gas costs
</Card>

### Timelock Delays

Governance timelocks rely on accurate block timestamps:

<Accordion title="Slow Folio Governor (DEFAULT_ADMIN_ROLE)">
  Expected to have a substantial timelock delay for security.

  Block time affects the precision of when operations can be executed after the delay.
</Accordion>

<Accordion title="Fast Folio Governor (REBALANCE_MANAGER)">
  May have a shorter timelock for operational agility.

  Still relies on accurate timestamps for delay enforcement.
</Accordion>

### Rebalance TTL

<Card title="Time-to-Live" icon="hourglass">
  Rebalances have a TTL that controls how long they can run.

  **Important:** An auction can be opened at `ttl - 1` and run beyond the rebalance's TTL.

  Block time affects when exactly the TTL expires.
</Card>

## Block Timestamp Assumptions

<AccordionGroup>
  <Accordion title="Monotonically Increasing">
    Block timestamps must always increase or stay the same (never decrease).

    This is a standard blockchain assumption enforced by consensus rules.
  </Accordion>

  <Accordion title="Reasonable Accuracy">
    Timestamps should be within a few seconds of actual wall-clock time.

    Large deviations could affect:

    * Auction pricing accuracy
    * Fee calculations
    * Rebalance timing
  </Accordion>

  <Accordion title="No Manipulation">
    Block producers should not be able to manipulate timestamps significantly.

    Most PoS chains have strict timestamp validation rules.
  </Accordion>
</AccordionGroup>

## Gas and Transaction Considerations

### Gas Prices

<Warning>
  **MEV Considerations**

  On networks with high MEV activity, auction participants need to consider:

  * Gas price volatility
  * Transaction ordering
  * Front-running risks

  The `AUCTION_LAUNCHER` role helps mitigate some MEV risks through trusted filler integration.
</Warning>

### Transaction Finality

<Info>
  Consider transaction finality guarantees on the target chain:

  * L2s typically have fast finality
  * Ethereum mainnet has longer finality (12-15 minutes)
  * Auction participants should account for reorg risks
</Info>

## Dependencies

### RoleRegistry

The protocol depends on an existing `RoleRegistry` instance:

```solidity theme={null}
interface IRoleRegistry {
  // Must adhere to this interface
  // See contracts/interfaces/IRoleRegistry.sol
}
```

### External Price Feeds

<Note>
  While not strictly required, many Folios rely on external price feeds for:

  * Setting initial price ranges
  * Monitoring for price excursions
  * Validating auction results

  Price feed availability and reliability vary by chain.
</Note>

## Deployment Checklist

<Steps>
  <Step title="Verify Block Time">
    Confirm the target chain has block times ≤ 30 seconds.

    Check recent blocks to verify consistent timing.
  </Step>

  <Step title="Test Timestamp Behavior">
    Deploy test contracts and verify timestamp behavior matches expectations.
  </Step>

  <Step title="Verify RoleRegistry">
    Ensure a compatible `RoleRegistry` is deployed on the target chain.
  </Step>

  <Step title="Test Token Compatibility">
    Verify all intended collateral tokens work correctly on the target chain.

    Some tokens behave differently across chains.
  </Step>

  <Step title="Configure Governance Delays">
    Set appropriate timelock delays based on chain block times.

    Faster block times may allow for shorter delays while maintaining security.
  </Step>

  <Step title="Test Auction Mechanics">
    Run test auctions to verify timing and pricing behavior.
  </Step>
</Steps>

## Chain-Specific Considerations

<AccordionGroup>
  <Accordion title="Ethereum Mainnet">
    **Pros:**

    * Highest security and decentralization
    * Most established ecosystem
    * Best liquidity

    **Cons:**

    * High gas costs
    * Slower finality
    * High MEV activity
  </Accordion>

  <Accordion title="Layer 2s (Arbitrum, Optimism, Base)">
    **Pros:**

    * Much lower gas costs
    * Faster block times
    * Fast finality

    **Cons:**

    * Depends on L1 for security
    * Potential centralization in sequencer
    * Withdrawal delays to L1
  </Accordion>

  <Accordion title="Sidechains (Polygon)">
    **Pros:**

    * Very low gas costs
    * Fast transactions

    **Cons:**

    * Separate security model
    * Bridge risks
    * Different validator set
  </Accordion>
</AccordionGroup>

## Performance Expectations

Expected performance on supported chains:

| Chain    | Auction Price Update Frequency | Fee Accrual Precision | Typical Gas Cost        |
| -------- | ------------------------------ | --------------------- | ----------------------- |
| Ethereum | Every \~12 seconds             | High                  | High (over \$50)        |
| Base     | Every \~2 seconds              | Very High             | Low (under \$1)         |
| Arbitrum | Every \~0.25 seconds           | Extremely High        | Very Low (under \$0.50) |
| Optimism | Every \~2 seconds              | Very High             | Low (under \$1)         |
| Polygon  | Every \~2 seconds              | Very High             | Very Low (under \$0.10) |

<Tip>
  Faster block times provide more granular auction pricing and better execution, but the protocol is designed to work well on all supported chains.
</Tip>

## Related Documentation

<CardGroup cols={2}>
  <Card title="Deployment" icon="rocket" href="/development">
    Deployment guide and scripts
  </Card>

  <Card title="Rebalancing" icon="balance-scale" href="/essentials/rebalancing">
    How timing affects rebalancing
  </Card>

  <Card title="Audits" icon="shield" href="/resources/audits">
    Security audits and chain-specific findings
  </Card>
</CardGroup>