Ethereum mainnet
Arbitrum
Optimism
BNB chain
Base
Polygon
Avalanche
Berachain
Hyperliquid EVM

Token Standards Used

The contracts integrate ERC20 tokens only. Specifically:

• Standard ERC20 tokens for the variable asset (premium payments)

• Token pairs (token0/token1) from Uniswap V3 pools, which are also ERC20 tokens

• The protocol uses OpenZeppelin's SafeERC20 library for safe token transfers

  Whitelisting Mechanism

  No explicit token whitelisting is implemented. The contracts allow:

• Any ERC20 token to be used as the variableAsset (specified during vault initialization)

• Any valid Uniswap V3 pool tokens (token0/token1) through the adapter

  The only validation is that pool addresses must be genuine Uniswap V3 pools (verified against the Uniswap V3 Factory in UniV3LimitedRangeAdapter.sol:124-130).

  Token Properties and Assumptions

  Required Properties:

• Non-deflationary tokens only - The contracts explicitly check for this:

  • In UniV3Vault.sol:62-66, the contract verifies that the actual amount received equals the expected amount
  • Comment states: "Transfer (restricted to non-deflationary tokens)"
  • Uses balance checks before and after transfer to detect fee-on-transfer tokens

• Standard ERC20 compliance - Tokens must properly implement:

  • transfer(), transferFrom(), approve()
  • balanceOf(), totalSupply()
  • Return correct boolean values

• Reentrancy protection - While the contracts use ReentrancyGuard modifier, tokens themselves are not explicitly required to be non-reentrant

  Weird Token Traits Not Supported

  The contracts will NOT work with:

• ❌ Deflationary/fee-on-transfer tokens - Explicitly blocked by balance checks (error code "NDT")

• ❌ Rebasing tokens - Would break accounting as balances change unexpectedly

• ❌ Tokens with transfer hooks that could cause reentrancy (though ReentrancyGuard provides some protection)

• ❌ Tokens with pause functionality - Could freeze vault operations

• ❌ Non-standard decimals - While 6-18 decimals should work, extreme values might cause issues

In summary, we allow any standard ERC20 tokens that comply with the ERC20 standard, with the explicit requirement that they must be non-deflationary. Tokens are not whitelisted but must pass our deflationary check (balance validation) during deposits. We do NOT support weird tokens with fee-on-transfer, or rebasing. Standard tokens with 6-18 decimals are supported.

Examples of supported tokens: USDC, USDT, DAI, WETH
Examples of unsupported tokens: Any deflationary tokens, AMPL (rebasing), or tokens with transfer fees.

Tokens added to vaults will be carefully considered by admins. Vaults aren’t able to be created by end users yet, and the tokens chosen by admins will have their code and associated risks carefully considered.

Access Control and Admin Limitations

Identified Roles

1. Owner (from OpenZeppelin's Ownable)

   • Controls the VaultFactory and RestrictedVaultFactory contracts
   • Cannot be renounced (renounceOwnership() is overridden to do nothing)
   • FULLY TRUSTED

2. FeeReceiver

   • Address that receives protocol fees
   • Not an access-controlled role (just a recipient address)
   • No administrative powers or functions to call

   Admin-Controlled Functions and Their Limitations

   VaultFactory Owner Functions:

3. setFeeBps(uint256 _feeBps)

   • Limitation: _feeBps < 10_000 (must be less than 100%)
   • Can set protocol fee from 0 to 9999 basis points

4. setFeeReceiver(address _feeReceiver)

   • Limitation: _feeReceiver != address(0x0) (cannot be zero address)
   • No other restrictions

5. setDefaultDepositTolerance(uint256 _defaultDepositTolerance)

   • Limitations:
     • _defaultDepositTolerance != 0 (cannot be zero)
     • _defaultDepositTolerance <= 10000 (maximum 100%)
   • Range: 1 to 10000 basis points

6. addVaultType(bytes calldata bytecode)

   • Limitation: bytecode.length > 0 (cannot be empty)
   • No upper limit on bytecode size

7. addAdapterType(bytes calldata bytecode)

   • Limitation: bytecode.length > 0 (cannot be empty)
   • No upper limit on bytecode size

8. revokeVaultType(uint256 id)

   • Limitation: id < nextVaultTypeId (must be valid existing ID)

9. revokeAdapterType(uint256 id)

   • Limitation: id < nextAdapterTypeId (must be valid existing ID)

   Array Length Restrictions

   No explicit array length restrictions. The contract uses:

10. Fixed-size arrays created in memory (new uint256 and new uint256)

11. Bytes arrays for bytecode with no upper limit enforced

12. No loops over unbounded arrays

    Hardcoded Values

13. 10_000 - Maximum basis points (100%)

14. type(uint128).max - Maximum liquidity capacity check

15. 1e18 - Scaling factor for calculations

16. 100 - Default deposit tolerance (1%) in VaultFactory

    Trust Assumptions

    Owner is TRUSTED

17. Can deploy arbitrary bytecode as vaults or adapters

18. Can change fees up to 99.99%

19. Can change fee receiver to any address

20. Cannot renounce ownership (protection against accidental loss)

21. In RestrictedVaultFactory: Owner has exclusive rights to create vaults/adapters

    FeeReceiver is NOT a trusted role - it's simply an address that receives fee tokens and has no access-controlled functions or administrative capabilities.

In summary, the Owner role is fully trusted with the following input validations:

• feeBps: Limited to < 10,000 (less than 100%)

• feeReceiver: Cannot be zero address

• defaultDepositTolerance: Must be between 1 and 10,000 basis points

• Bytecode parameters: Must be non-empty, but no upper size limit

• No array length restrictions are implemented as the contract doesn't process unbounded arrays

• Ownership cannot be renounced (safeguard against accidental loss)

  No plans to change hardcoded values - the constants (10_000 for basis points, type(uint128).max for capacity checks, 1e18 for scaling) are standard values that should remain fixed.

No limitations assumed on integrated protocol admin functions. The protocol:

1. Fully trusts Uniswap V3 governance - No protection against Uniswap parameter changes or upgrades
2. Trusts ERC20 token governance - Beyond blocking deflationary tokens, accepts any token admin actions
3. Assumes integrated protocols act honestly - No defensive measures against malicious governance

EIP Compliance

The codebase is expected to comply with the following EIPs:

1. EIP-20 (ERC-20 Token Standard)

   Implementation:

2. VaultBearerToken.sol extends OpenZeppelin's ERC20

3. All bearer tokens (fixed, variable, claim) are ERC-20 compliant

4. Integration with any ERC-20 tokens for the variableAsset

   Intention:

5. Provides fungible representation of vault positions, allowing users to transfer, trade, or integrate their vault shares with DeFi protocols

6. Ensures compatibility with the broader Ethereum ecosystem (wallets, DEXes, etc.)

7. Enables fractional ownership and liquidity for fixed income positions

8. EIP-721 (ERC-721 Non-Fungible Token Standard)

   Implementation:

9. UniV3LimitedRangeAdapter.sol implements onERC721Received

10. Receives and manages Uniswap V3 position NFTs

    Intention:

11. Required for integration with Uniswap V3's Position Manager

12. Uniswap V3 represents liquidity positions as NFTs (ERC-721)

13. Adapter must be able to receive and hold these position NFTs to manage liquidity

14. EIP-173 (Contract Ownership Standard)

    Implementation:

15. VaultFactory.sol extends OpenZeppelin's Ownable

16. Implements owner-only functions with onlyOwner modifier

17. Overrides renounceOwnership() to prevent accidental loss

    Intention:

18. Provides administrative control over factory settings (fees, vault types, adapter types)

19. Ensures upgradability and parameter adjustments

20. Protection against ownership loss maintains protocol governability

21. Implicit Standards via OpenZeppelin:

    EIP-165 (Standard Interface Detection) - Implicitly via OpenZeppelin's ERC20 implementation

    SafeERC20 practices - Using OpenZeppelin's SafeERC20 library for safe token transfers

In summary, the codebase complies with:

• EIP-20 (ERC-20): For all bearer tokens (VaultBearerToken) to ensure fungibility and DeFi composability

• EIP-721 (ERC-721): For receiving Uniswap V3 position NFTs (required for liquidity management)

• EIP-173 (Ownable): For administrative control of the factory contract

  These standards are essential for:

• Allowing users to trade/transfer their vault positions

• Integrating with Uniswap V3's NFT-based liquidity system

• Maintaining protocol governance and upgradability

• Ensuring compatibility with wallets, explorers, and DeFi infrastructure

The protocol has NO off-chain mechanisms or keeper bots. All functions are user-triggered:

• Vault lifecycle is self-executing - starts automatically when capacity is reached, ends when first user withdraws after duration
• No keepers required - earnings settlement happens during normal user withdrawals
• No oracle dependencies - uses Uniswap V3 pool state directly via slot0()
• Events are emitted for optional monitoring by frontends or analytics services

Critical Protocol Invariants

1. Bearer Token Supply Invariants

Invariant: Bearer token supplies must match deposit accounting with fee adjustments

Before vault starts:
claimToken.totalSupply() == 1 (for UniV3Vault - only one fixed depositor allowed)
variableBearerToken.totalSupply() <= variableSideCapacity
variableBearerToken.totalSupply() == sum of all variable deposits

After vault starts (before claiming):
claimToken.totalSupply() == 1
fixedBearerToken.totalSupply() == 0

After fixed side claims:
claimToken.totalSupply() == 0
fixedBearerToken.totalSupply() == 1

After applyFee():
variableBearerToken.totalSupply() == variableSideDeposits × (10000 / (10000 - feeBps))
where additional tokens = variableSideDeposits × feeBps / (10000 - feeBps)

Why Critical: Even 1 wei discrepancy indicates accounting error that could compound over time

2. Vault State Transitions

   Invariant: Vault states must follow strict progression
   NOT_INITIALIZED → INITIALIZED → STARTED → ENDED

   isStarted can only transition from false → true (never back)
   earningsSettled can only transition from false → true (never back)
   endTime must be immutable once set (endTime > 0 only after start)

   Why Critical: State regression could allow double-claiming of funds

3. Single Position per Vault

   Invariant: Each adapter must have exactly 0 or 1 Uniswap V3 position
   tokenId == 0 (before deployCapital) XOR tokenId > 0 (after deployCapital)
   Once tokenId > 0, it cannot be changed until burned
   After burn, tokenId must return to 0

   Why Critical: Multiple positions would break fee distribution logic

4. Capacity Constraints

   Invariant: Deposits must never exceed defined capacities
   variableBearerToken.totalSupply() <= variableSideCapacity
   claimToken.totalSupply() <= 1 (for UniV3Vault)
   fixedBearerToken.totalSupply() <= 1 (for UniV3Vault)

   Why Critical: Over-deposits could break vault economics and premium calculations

5. Token Conservation

   Invariant: No tokens should be created or destroyed except through mint/burn
   For any ERC20 token:
   sum(all user balances) == totalSupply()
   totalSupply() == totalMinted - totalBurned

   Why Critical: Lost tokens indicate a vulnerability or accounting error

6. Fixed Side Claim Token Exchange

   Invariant: Claim tokens must be exchangeable for bearer tokens + premium payment

The claim token exchange is atomic - burning claim tokens must simultaneously mint bearer tokens and transfer the variable side's deposit as the fixed side's guaranteed payment.

When claim() is called after vault starts:
claimToken.burn(1) triggers:
- fixedBearerToken.mint(1)
- transfer of (variableAsset balance × claimTokens / claimToken.totalSupply())

After all claims processed:
claimToken.totalSupply() == 0
fixedBearerToken.totalSupply() == (original claimToken supply)

Why Critical: Broken exchange would lock fixed depositor funds or prevent premium payment

7. Earnings Distribution

   Invariant: Earnings tracking and distribution must be consistent

Fee distribution uses pro-rata allocation: each withdrawer receives (their tokens / total tokens) × total fees. The system maintains a settlement snapshot (earnings0, earnings1) that represents the maximum distributable amount. Each withdrawal decrements these values, ensuring sum(withdrawals) never exceeds the original snapshot. Post-settlement fees intentionally go to the fixed side despite product specs, simplifying implementation.

First collection (settleEarnings):
(earnings0, earnings1) = collect(tokenId) // Snapshot at settlement time
earningsSettled = true (one-way transition)

Variable side distribution:
For each variable withdrawer:
amount0 = (bearerBalance / totalBearerSupply) × earnings0
amount1 = (bearerBalance / totalBearerSupply) × earnings1

sum(all variable withdrawals) <= earnings0 and <= earnings1
earnings0 and earnings1 decrease after each withdrawal

Post-settlement fees:
Fees collected during removeLiquidity() after settlement go to fixed side
This intentionally breaks the "all fees to variable" product design to reduce complexity. See more elaboration in the design section

Why Critical: Fee leakage or creation violates user expectations; post-settlement fees create unfair advantage

8. Liquidity Bounds

   Invariant: Actual liquidity must remain within tolerance of target

Actual liquidity must stay within tolerance bands calculated as: target × (1 - tolerance%) < actual ≤ target × (1 + tolerance%). The asymmetric bounds (strict greater-than on lower, inclusive less-than on upper) prevent liquidity from dropping below minimum requirements while allowing exact target matching. With 2% tolerance on $100k target: $98k < actual ≤ $102k.

At position creation:
targetLiquidity × invDepositTolerance / 10000 < actualLiquidity
actualLiquidity <= targetLiquidity × (10000 + upperDepositTolerance) / 10000

where:
invDepositTolerance = 10000 - depositTolerance
upperDepositTolerance = depositTolerance

Why Critical: Exceeding bounds could enable economic attacks or unfair pricing

9. Time Monotonicity

   Invariant: Time-based checks must respect blockchain time
   block.timestamp > endTime required for normal withdrawals
   endTime == block.timestamp + duration (once vault starts)
   endTime == 0 (before vault starts)
   vault can only start when: claimToken.totalSupply() == 1 AND variableBearerToken.totalSupply() == variableSideCapacity

   Why Critical: Time manipulation could enable premature withdrawals

10. Fee Basis Points

    Invariant: Protocol fee must remain within valid range
    0 <= feeBps < 10000
    feeDivisor == 10000 - feeBps (always)

    Why Critical: Invalid fees could brick withdrawals or steal funds

11. Adapter-Vault Binding

    Invariant: Each adapter must be bound to exactly one vault
    adapter.vaultAddress() == address(0) (before setVault)
    adapter.vaultAddress() == vaultAddress (after setVault, immutable)
    adapter can only be used by its bound vault (onlyVault modifier)

    Why Critical: Adapter reuse could mix funds between vaults

12. NFT Ownership

    Invariant: Adapter must own the Uniswap V3 NFT position when it exists
    When tokenId > 0:
    positionManager.ownerOf(tokenId) == address(adapter)

    After position is burned:
    tokenId == 0
    position no longer exists

    Why Critical: Lost NFT means lost liquidity

    13. Early Withdrawal Fee Distribution
        Invariant: If vault never starts, all accrued fees go to fixed side
        If !isStarted and fixed side calls withdraw():
        Fixed depositor receives: principal + all accrued Uniswap fees
        Variable depositors receive: only their original deposits (no fees)

    Why Critical: Defines risk/reward allocation when vault doesn't

Design Choices and Trade-offs

1. Deflationary Token Rejection

   Choice: Explicitly block deflationary/fee-on-transfer tokens with balance checks in UniV3Vault.sol:62-66
   // Transfer (restricted to non-deflationary tokens)
   uint256 oldBalance = IERC20(variableAsset).balanceOf(address(this));
   IERC20(variableAsset).safeTransferFrom(msg.sender, address(this), amount);
   uint256 newBalance = IERC20(variableAsset).balanceOf(address(this));
   require(amount == newBalance - oldBalance, "NDT");
   Rationale: This simplifies accounting and prevents exploitation through token mechanics. Supporting deflationary tokens would require complex adjustments throughout the
   protocol.
   Risk: None - this is a protective measure.

2. Single Position per Vault

   Choice: Each vault manages exactly one Uniswap V3 position (tokenId)
   Rationale: Simplifies liquidity management and earnings distribution. Multiple positions would complicate fee collection and proportional distributions.
   Trade-off: Less flexibility in liquidity management strategies but much simpler to audit and reason about.

3. Auto-Start Mechanism

   Choice: Vaults automatically start when both sides reach capacity (no keeper needed)
   if (claimToken.totalSupply() == 1 && variableBearerToken.totalSupply() == variableSideCapacity) {
   start();
   }
   Rationale: Eliminates need for external triggers or admin intervention
   Risk: Potential for griefing if someone deposits 99.9% of variable capacity, preventing vault start

4. Fee Collection Timing

   Choice: Protocol fees are minted as bearer tokens to the vault itself, claimed later by feeReceiver
   // Mint bearer tokens for protocol fee to the vault itself to avoid feeReceiver address drift
   variableBearerToken.mint(address(this), fee);
   Rationale: Prevents issues if feeReceiver address changes between vault start and end
   Trade-off: Requires extra step for fee collection but ensures fees go to current fee receiver

5. Liquidity Tolerance Bands

   Choice: Allow ±1% deviation between target and actual liquidity minted (configurable via depositTolerance)

   Implementation:
   // Lower bound: actual must be > 99% of target
   require(uint256(l) * invDepositTolerance / 10000 < _liquidity, "L");

   // Upper bound: actual must be ≤ 101% of target
   require(_liquidity <= uint256(l) * (10000 + upperDepositTolerance) / 10000, "Excessive liquidity");

   Example with default 1% tolerance:

6. Target liquidity: 1000

7. Allowed range: 990 < actual ≤ 1010

   Rationale:
   Uniswap V3 price can move between when the fixed depositor calculates required token amounts and when the transaction executes. This price movement causes the actual liquidity minted to differ slightly from the target. Tolerance bands account for this while still protecting both parties.

   Risk: On large vaults, 1% tolerance allows meaningful deviations (e.g., $50 on a $5,000 deposit). Could potentially enable sandwich attacks or price manipulation within the tolerance window.

8. No Partial Withdrawals

   Choice: Users must withdraw their entire position at once
   Rationale: Simplifies accounting and prevents gaming of the fee distribution mechanism
   Trade-off: Less flexibility for users but ensures fair distribution of earnings

9. Claim Token Design

   Choice: Fixed side gets claim tokens that must be exchanged for bearer tokens after vault starts
   Rationale: Ensures fixed depositors receive their premium payment (variable deposits) before getting liquidity tokens
   Risk: Additional transaction required, but ensures atomic premium payment

10. No Emergency Withdrawal

    Choice: No admin functions to pause or emergency withdraw
    Rationale: Fully decentralized operation, no admin risk
    Trade-off: Cannot recover from extreme scenarios (e.g., Uniswap V3 exploit), but eliminates centralization risk

11. Fixed Capacity Limits

    Choice: Vault capacities are immutable once initialized
    Rationale: Provides certainty to depositors about vault economics
    Trade-off: Cannot adjust for market conditions after deployment

12. Ownership Cannot Be Renounced

    Choice: Override renounceOwnership() to prevent accidental loss
    function renounceOwnership() public override {}
    Rationale: Prevents permanent loss of admin capabilities
    Risk: None - purely protective

13. No Slippage Protection in Vault

    Choice: Slippage parameters passed through to Uniswap but not validated by vault
    Rationale: Users are responsible for their own slippage tolerance
    Risk: Users could submit transactions with poor slippage settings, but this is their choice

14. Rounding Ignored in Fee Calculations

    Choice: Use simple multiplication/division for fees without rounding considerations
    uint256 fee = FullMath.mulDiv(variableBearerToken.totalSupply(), feeBps, feeDivisor);
    Rationale: Dust amounts are negligible for fee calculations
    Risk: Minimal - maximum loss is 1 wei per calculation

    Critical Assumptions

15. Uniswap V3 Pools are Genuine: Pool validation only checks against factory, assumes factory is legitimate

16. Users Will Claim: No automatic distribution mechanism - relies on economic incentive

17. Price Movements Are Reasonable: Deposit tolerance assumes normal market conditions

18. No Token Upgrades: Doesn't handle upgradeable tokens that might change behavior

    13. Pre-Start and Post-Maturity Fee Distribution

    Uniswap V3 fees accrue continuously from the moment liquidity is deployed until it's removed. However, our vault has three distinct time periods:

19. Pre-Start Period: Between fixed side deployCapital() and vault start()

20. Vault Duration: From start() until endTime

21. Post-Maturity Period: Between endTime and when settleEarnings() is called

    Our design choice: All fees from all three periods are collected in a single snapshot at settlement time and distributed to the variable side, except for fees that accrue between the
    settlement snapshot and the actual removeLiquidity() call, which go to the fixed side.

    The Rationale

    We chose this simplified approach because:

22. Complexity Avoidance: Tracking and distributing fees separately for each time period would require:

    • Multiple collect() calls with snapshots
    • Complex accounting to attribute fees to specific periods
    • Pro-rata distribution logic for variable depositors who can enter/leave at will before start
    • Additional storage for tracking each period's fees
    • Significantly more gas costs

23. Variable Side Flexibility: Variable depositors can:

    • Deposit at any time before vault starts
    • Withdraw at any time before vault starts (early withdrawal)
    • Each receives proportional bearer tokens
    • Tracking individual contribution periods for fee allocation would be prohibitively complex

24. Efficient Market Assumption: In practice, we expect:

    • Pre-start period to be short: Variable side will fill quickly after fixed side deposits
    • Post-maturity period to be short: Users are incentivized to settle/withdraw promptly after endTime
    • Rational actors will manage their positions efficiently

25. Fair Risk Allocation:

    • Pre-start fees: If vault never starts, fixed side can withdraw and receives all fees - this is fair because they took on price risk without the vault activating
    • Post-maturity fees: Fixed withdrawer receives fees between settlement and liquidity removal

26. Fixed Side Responsibility:

    • The fixed side deposits first and their capital is immediately deployed to Uniswap
    • They take on price risk from the moment of deployment
    • It is the fixed side's responsibility to monitor the vault and withdraw if it takes too long to fill
    • They can call withdraw() at any time before start to recover their principal + any accrued fees
    • This gives them full control over their risk exposure during the pre-start period

    Known Edge Cases

    Edge Case 1: Long Pre-Start Period

27. Fixed side deposits and adds liquidity to Uniswap

28. Variable side takes days/weeks to fill

29. Fees accrue during this time

30. Result: If vault eventually starts, variable side gets these fees; if not, fixed side can withdraw and keep them

31. Impact:

    • Variable side APR will be higher than estimated if pre-start is long (bonus for variable depositors)
    • Fixed side bears IL (impermanent loss) risk from price movements during this entire period
    • Fixed side mitigation: Can withdraw at any time to exit and claim accrued fees

    Edge Case 2: Post-Settlement Fees

32. settleEarnings() is called, snapshotting fees for variable side

33. Time passes before fixed side calls removeLiquidity()

34. Additional fees accrue in the Uniswap position

35. Result: Fixed side receives these additional fees when they remove liquidity

36. Impact: Fixed side gets slightly more than their guaranteed return

    Edge Case 3: Delayed Settlement

37. Vault reaches endTime

38. Days/weeks pass before anyone calls withdraw (triggering settlement)

39. Fees continue accruing

40. Result: Variable side gets all these post-maturity fees in the settlement snapshot

41. Impact: Variable side APR will be higher than estimated

    Responsibility Allocation

    Fixed Side Responsibilities:

42. Monitor vault filling progress

43. Withdraw early if vault takes too long to start (protecting against extended price risk)

44. Decide when to remove liquidity post-maturity (affects post-settlement fees)

    Variable Side Responsibilities:

45. Fill vault capacity to activate it

46. Withdraw post-maturity to claim earnings (triggering settlement if needed)

    Market Incentives:

47. Fixed side is incentivized to withdraw if vault doesn't fill (avoid prolonged price exposure)

48. Variable side is incentivized to fill vaults with attractive terms quickly

49. Both sides are incentivized to settle/withdraw promptly after maturity

Quantstamp https://certificate.quantstamp.com/full/saffron/e75728bd-278c-4651-b84a-1ee7b8488cb2/index.html
Halborn https://drive.google.com/file/d/1GkokNq5zDe8kgSTK1gU-bmJIYror2ql2/view?usp=sharing
Pashov https://github.com/pashov/audits/blob/master/team/pdf/Saffron-security-review_2025-07-31.pdf

Whitepaper: https://github.com/saffron-finance/papers/blob/main/SaffronFixedIncomeVault.pdf
Layman article: https://medium.com/saffron-finance/saffron-fixed-income-vault-calculator-83218596dfa3
Generated Docs: https://gist.github.com/psykeeper/442f17e1c6d686b63e5d56bc2d9e80f2
Error Codes: https://gist.github.com/psykeeper/fe7cf420303e3442f3c1fc06da12c61b

Pashov Audit Fixes PR https://github.com/saffron-finance/fixed-income/pull/89
Previous Audit Fixes PR https://github.com/saffron-finance/fixed-income/pull/71

VaultFactory won't be deployed separately as a standalone contract, while the RestrictedVaultFactory will be deployed, which inherits VaultFactory.