Lifecycle of an Automated Vault

Let's trace the lifecycle of a Delta-Neutral Yield Vault built on Matador. This vault earns fees on Uniswap V3 while hedging price exposure on Aave.

Phase 1: Definition (The Prospectus)

The vault creator defines the strategy constraints. This is the "contract" with the user.

• Strategy: Provide Liquidity on ETH/USDC.
• Hedge: Borrow ETH on Aave to neutralize the ETH exposure from the LP position.
• Constraints:
  • Max Leverage: 3x.
  • Delta Range: +/- 5%.
  • Slippage Limit: 1%.

This is compiled into a Matador Policy.

Phase 2: Deployment

1. Deploy Safe/Kernel: The vault is just a standard smart account (Gnosis Safe or Kernel).
2. Install Matador: The Matador module is enabled on the Safe.
3. Install Policy: The Policy bytecode is uploaded, and the "Manager Bot" address is authorized to execute it.

Status: The Vault is open for deposits. The Manager Bot has keys, but can only do what the Policy allows.

Phase 3: Execution (The Loop)

Step A: The Rebalance Trigger

The price of ETH moves. The vault is no longer delta-neutral. The Manager Bot calculates the necessary trades:

1. Withdraw some liquidity from Uniswap.
2. Repay some ETH debt on Aave.

Step B: The Transaction

The Bot constructs a batch transaction:

// Off-chain code
const tx = batch([
  uniswap.decreaseLiquidity(...),
  uniswap.collectFees(...),
  aave.repay(...)
]);

Step C: The Enforcement

The Bot submits the transaction to the Vault. Matador Intercepts:

1. Check: Is the caller the authorized Bot? (Yes)
2. Simulate: Does this sequence of trades violate the Policy?
   • Did it reduce leverage? (Yes)
   • Is the new delta within +/- 5%? (Yes)
   • Did it try to transfer funds to an unknown address? (No)
3. Result: APPROVED. The transaction executes.

Phase 4: The "Attack" (Defense)

The Bot operator's server is hacked. The attacker tries to drain the vault.

The Attack Transaction

The attacker constructs a transaction:

const tx = batch([
  uniswap.decreaseLiquidity(...),
  token.transfer(attacker_address, all_funds) // THEFT!
]);

The Enforcement

Matador Intercepts:

1. Check: Is the caller the authorized Bot? (Yes - key is stolen).
2. Simulate:
   • Opcode: CALLDATA_CHECK on transfer.
   • Policy Rule: allow target == Aave_Pool OR Uniswap_Router.
   • Actual Target: USDC_Contract.
   • Actual Calldata: transfer(attacker...).
3. Result: DENIED. Revert PolicyViolation.

Outcome: The attacker has the private key, but cannot steal the funds. The vault remains secure.

The Unlock

This lifecycle demonstrates the power of Matador:

• High Frequency: The bot can rebalance every block if needed.
• Low Risk: A compromised bot key is an annoyance (need to rotate keys), not a catastrophe (loss of funds).