Access Policies

Access policies in Flux Protocol control who can interact with vaults and under what conditions. They provide fine-grained access control for vault deposits, withdrawals, and borrowing operations.

Overview

Access policies enable vault creators to:

• Restrict vault access to specific addresses or roles

• Implement KYC/compliance requirements for regulated use cases

• Create private vaults for specific user groups

• Enforce deposit/withdrawal limits per user

• Control manager permissions separately from LP permissions

---

Policy Types

1. Open Access (Default)

Anyone can deposit, withdraw, or borrow from the vault.

// No access policy set - fully permissionless
IFluxVault vault = IFluxVault(vaultAddress);

Use Cases:

• Public lending pools

• Permissionless DeFi protocols

• Maximum composability

2. Allowlist Policy

Only approved addresses can interact with the vault.

interface IAllowlistPolicy {
    function isAllowed(address user) external view returns (bool);
    function addToAllowlist(address user) external;
    function removeFromAllowlist(address user) external;
}

Use Cases:

• Private funds

• Institutional vaults

• Compliance requirements

• Testing/beta access

3. Role-Based Access

Different permissions for different roles (LPs vs Managers).

interface IRoleBasedPolicy {
    function canDeposit(address user) external view returns (bool);
    function canWithdraw(address user) external view returns (bool);
    function canBorrow(address user) external view returns (bool);
}

Use Cases:

• Separate LP and manager lists

• Professional manager programs

• Tiered access levels

4. Cap-Based Policy

Enforce per-user deposit limits.

interface ICapPolicy {
    function maxDeposit(address user) external view returns (uint256);
    function currentDeposit(address user) external view returns (uint256);
}

Use Cases:

• Fair launch mechanisms

• Prevent whale concentration

• Regulatory limits

5. Time-Locked Policy

Restrict access based on time windows.

interface ITimeLockPolicy {
    function canInteract(address user, uint256 timestamp)
        external
        view
        returns (bool);
}

Use Cases:

• Vesting schedules

• Lock-up periods

• Scheduled access

---

Implementing Access Policies

Creating a Custom Policy

contract CustomAccessPolicy is IAccessPolicy {
    mapping(address => bool) public allowedLPs;
    mapping(address => bool) public allowedManagers;

    function canDeposit(address user) external view returns (bool) {
        return allowedLPs[user];
    }

    function canBorrow(address user) external view returns (bool) {
        return allowedManagers[user];
    }

    function canWithdraw(address user) external view returns (bool) {
        return allowedLPs[user];
    }
}

Attaching Policy to Vault

Access policies are set during vault creation:

IFluxVault vault = factory.createVault(
    baseAsset,
    strategy,
    accessPolicy,  // Your policy contract
    name,
    symbol
);

Policy Upgrades

Important: Access policies in Flux are immutable by default to protect depositors.

If you need updatable policies:

1. Implement a proxy pattern in your policy contract

2. Clearly communicate upgrade rights to users

3. Consider timelock mechanisms for policy changes

---

Policy Best Practices

For Public Vaults

// No policy = maximum composability
address accessPolicy = address(0);

Pros:

• Maximum DeFi composability

• Lowest integration friction

• Largest potential user base

Cons:

• No compliance controls

• Cannot restrict bad actors

• No preferential access

For Private Vaults

// Allowlist policy with owner controls
AllowlistPolicy policy = new AllowlistPolicy(owner);
policy.addToAllowlist(trustedUser1);
policy.addToAllowlist(trustedUser2);

Pros:

• Full control over participants

• Compliance-friendly

• Can meet KYC requirements

Cons:

• Manual user management

• Reduced composability

• Ongoing maintenance

For Hybrid Models

// Separate LP and manager access
RoleBasedPolicy policy = new RoleBasedPolicy();
policy.setLPAccess(PUBLIC);
policy.setManagerAccess(ALLOWLIST);

Pros:

• Open LP access for liquidity

• Curated manager selection

• Balanced approach

Cons:

• More complex policy logic

• Two allowlists to maintain

---

Security Considerations

Policy Immutability

• Default behavior: Policies cannot be changed after vault creation

• Rationale: Protects LPs from rug pulls

• Trade-off: Cannot adapt to new requirements

Upgradeability Risks

If implementing upgradeable policies:

// ⚠️ DANGEROUS: Owner can change rules
contract UpgradeablePolicy {
    address public owner;

    function setAccess(address user, bool allowed) external {
        require(msg.sender == owner);
        // Owner can rug pull by revoking LP access
    }
}

Mitigation:

• Use timelocks for policy changes

• Emit events for all policy updates

• Consider multi-sig ownership

• Document upgrade rights clearly

Gas Optimization

// BAD: External call on every deposit
function canDeposit(address user) external view returns (bool) {
    return expensiveExternalCall(user);
}

// GOOD: Cached allowlist
mapping(address => bool) public allowed;

---

Policy Examples

Example 1: Allowlist with Max Users

contract CappedAllowlist is IAccessPolicy {
    mapping(address => bool) public allowlist;
    uint256 public maxUsers;
    uint256 public currentUsers;

    function addToAllowlist(address user) external onlyOwner {
        require(currentUsers < maxUsers, "Max users reached");
        require(!allowlist[user], "Already allowed");

        allowlist[user] = true;
        currentUsers++;
    }

    function canDeposit(address user) external view returns (bool) {
        return allowlist[user];
    }
}

Example 2: Deposit Cap Per User

contract PerUserCap is IAccessPolicy {
    uint256 public maxDepositPerUser;
    mapping(address => uint256) public userDeposits;

    function canDeposit(address user, uint256 amount)
        external
        view
        returns (bool)
    {
        return userDeposits[user] + amount <= maxDepositPerUser;
    }

    function recordDeposit(address user, uint256 amount) external {
        userDeposits[user] += amount;
    }
}

Example 3: Time-Gated Access

contract TimeLocked is IAccessPolicy {
    uint256 public startTime;
    uint256 public endTime;

    function canDeposit(address) external view returns (bool) {
        return block.timestamp >= startTime && block.timestamp <= endTime;
    }
}

---

Integration Guide

For Vault Creators

1. Determine requirements: Do you need access control?

2. Choose policy type: Select from standard policies or build custom

3. Deploy policy: Deploy your policy contract

4. Create vault: Pass policy address during vault creation

5. Manage access: Update allowlists if using mutable policies

For Integrators

Always check if a vault has access restrictions:

IAccessPolicy policy = vault.accessPolicy();

if (address(policy) != address(0)) {
    // Vault has access control
    bool canDeposit = policy.canDeposit(user);
    require(canDeposit, "User not authorized");
}

For LPs

Before depositing:

// Check if you can deposit
try vault.accessPolicy().canDeposit(msg.sender) returns (bool allowed) {
    require(allowed, "Not authorized to deposit");
} catch {
    // No policy = open access
}

vault.deposit(amount, msg.sender);

---

Policy Standards

IAccessPolicy Interface

interface IAccessPolicy {
    /// @notice Check if user can deposit
    function canDeposit(address user) external view returns (bool);

    /// @notice Check if user can withdraw
    function canWithdraw(address user) external view returns (bool);

    /// @notice Check if user can borrow
    function canBorrow(address user) external view returns (bool);

    /// @notice Check if user can liquidate
    function canLiquidate(address user) external view returns (bool);
}

---

Comparison with Other Protocols

Protocol	Access Control	Immutable
Flux	Flexible policies	Yes (by default)
Aave	None	N/A
Compound	None	N/A
Morpho	Vault-level	Varies
Euler	None	N/A

---

Advanced Topics

Multi-Sig Policies

contract MultiSigPolicy is IAccessPolicy {
    uint256 public requiredSignatures;
    mapping(address => bool) public signers;

    function addToAllowlist(
        address user,
        bytes[] memory signatures
    ) external {
        require(signatures.length >= requiredSignatures);
        // Verify signatures from signers
        // Add user to allowlist
    }
}

Oracle-Based Policies

contract OraclePolicy is IAccessPolicy {
    IOracle public creditScoreOracle;
    uint256 public minCreditScore;

    function canDeposit(address user) external view returns (bool) {
        uint256 score = creditScoreOracle.getCreditScore(user);
        return score >= minCreditScore;
    }
}

NFT-Gated Access

contract NFTGatedPolicy is IAccessPolicy {
    IERC721 public membershipNFT;

    function canDeposit(address user) external view returns (bool) {
        return membershipNFT.balanceOf(user) > 0;
    }
}

Related Documentation

• Flux Vault - Understanding vault architecture

• Strategies - Strategy configuration

• Creating a Vault - Vault deployment guide

• Access Policy Selection - Choosing the right policy

Questions?

• Do policies apply to liquidators? Typically no - liquidations should remain permissionless for protocol safety

• Can I change the policy later? Not by default - policies are immutable to protect depositors

• Do all vaults need policies? No - most public vaults have no access control

• What is the gas cost of policies? Minimal if implemented efficiently with allowlists