Stakr Protocol

Stakr Protocol — Agent Overview

This skill gives agents the context to interact with the Stakr protocol: ERC-4626 tokenized vaults with multi-reward staking for any ERC-20 token. Use it when building integrations, scripts, or tooling that create vaults, add rewards, modify reward schedules, or let an agent operate its "own" vault.

Protocol at a Glance

• StakrVault: Single-asset ERC-4626 vault. Users deposit underlying, get shares; they can lock shares to earn multiple reward tokens over configurable windows.
• StakrVaultFactory: Deploys vaults and holds protocol fee configuration. One factory per chain.
• Rewards: Up to 25 reward tokens per vault. Each reward has startTime, endTime, and total amount. Distribution is linear over the window; logic is Masterchef-style (accumulated rewards per share).
• Ownership: A vault can have an owner (address that can add/modify rewards) or address(0) for permissionless reward addition.

When an agent is said to have its "own vault", it means: the agent (or a controlled EOA/contract) is the vault owner, so it can call addRewardToken and modifyRewardToken to fund and adjust rewards without third-party permission.

Emphasis: Adding and Modifying Rewards (Agent-Owned Vaults)

Agents that operate their own vault will use these two functions most:

1. addRewardToken(token, amount, settings)

Purpose: Start a new reward program for a given ERC-20 token.

• Caller: Vault owner (or anyone if owner() == address(0)).
• Parameters:
  • token: ERC-20 reward token address. Cannot be the vault’s share token address(vault).
  • amount: Total amount of token to distribute. Tokens are pulled from msg.sender; protocol may take a fee (see factory feeOnAddReward).
  • settings: Settings{ startTime, endTime }. Distribution is linear from startTime to endTime; both must be in the future and startTime < endTime.
• Effects: Registers the reward, pulls tokens (minus fee) into the vault, and emits AddReward. Rewards cannot be withdrawn once added; they can only be modified (extended or topped up) via modifyRewardToken.
• Limits: No duplicate reward token; vault cannot have more than 25 active rewards.

Use this when the agent wants to create a new reward (e.g. launch an incentive program on its vault).

2. modifyRewardToken(token, amount, settings)

Purpose: Add more amount and/or extend (or reschedule) an existing reward.

• Caller: Same as addRewardToken (vault owner or permissionless if owner is zero).
• Parameters:
  • token: Address of an already active reward token.
  • amount: Additional amount of token to add. Pulled from msg.sender; fee may apply. Cannot reduce existing amount.
  • settings: Settings{ startTime, endTime }. Rules:
    • If the reward has not yet ended (currentTime <= reward.settings.endTime): you can only extend endTime (and add more amount). startTime cannot be changed.
    • If the reward has ended (currentTime > reward.settings.endTime): you can set a new window (startTime, endTime) and add amount; accRewardsPerShare is reset.
• Effects: Increases remainingAmount (and total amount) by amount, updates endTime (and possibly startTime if reward had ended), pulls tokens from msg.sender, and emits ModifyReward.

Use this when the agent wants to top up an existing reward or extend the distribution period (or reschedule after it has ended).

Summary for agents:

• New reward → addRewardToken(token, amount, settings).
• More reward or longer duration (or new window after end) → modifyRewardToken(token, amount, settings).
• Ensure the vault has been created via the factory and the agent (or its controlled address) is the vault owner to call these.

Executing Transactions via Bankr

To submit any Stakr call (vault creation, addRewardToken, modifyRewardToken), first encode calldata, then submit the transaction via the Bankr wallet API.

Use a natural-language Bankr agent prompt:

bankr agent prompt "Call addRewardToken on vault 0x... with token 0x... amount 1000 USDC starting tomorrow for 7 days"

Or submit raw encoded calldata directly:

bankr wallet submit --to <vault-address> --data <encoded-calldata> --chain base

For calldata encoding help, see the vault API reference.

3. Streaming rewards (continuous incentives)

Agents can stream rewards over time instead of funding one large window up front:

• Pattern: Call addRewardToken once to start a reward (short amount if desired). Then call modifyRewardToken repeatedly to add more amount and extend endTime. Each call tops up the reward and pushes the end of the distribution window forward.
• Why: This avoids locking a huge amount for a long period. The agent (or a script/cron) can fund the vault in chunks and extend the window as needed, effectively creating a continuous reward stream.
• Rules: While the reward is active (currentTime <= reward.settings.endTime), modifyRewardToken only allows extending endTime and adding amount; startTime cannot be changed. After the reward has ended, the agent can set a brand‑new window with modifyRewardToken (new startTime and endTime) and keep streaming.

Use streaming when the agent wants to fund incentives on an ongoing basis (e.g. weekly top‑ups, or extending the program as budget allows) rather than committing to a single long window.

Creating an Agent-Owned Vault

1. Get the StakrVaultFactory address for the chain.
   • On Base mainnet, the factory is deployed at 0x7Ef55108fa37472296DA59D2287FdA92cd21A0d0 (view on BaseScan).
   • For an example Stakr vault implementation on Base, see 0x93125009209e23fBAFf2B78712029F7A7CdD23cD (example vault on BaseScan).
2. Call createStakrVault(underlying, name, symbol, description, owner):
   • underlying: ERC-20 underlying asset.
   • name, symbol: Vault share token name/symbol.
   • description: Short metadata (e.g. "Agent incentive vault").
   • owner: Set to the agent’s address (or the EOA/contract the agent controls). Use address(0) for permissionless reward add/modify by anyone.
3. Use the returned vault address for all subsequent calls (addRewardToken, modifyRewardToken, etc.).

Core User Flows (for completeness)

• Deposit only: deposit(assets, receiver) (ERC-4626).
• Deposit and lock: depositAndLock(assets, user).
• Lock existing shares: lock(shares, user) (vault must be approved for the shares).
• Harvest: harvest(user) to send pending rewards to user.
• Unlock: unlock(shares, user); then optionally unlockAndRedeem(shares, receiver) to redeem shares for underlying.

Settings and Types

• Settings: struct Settings { uint256 startTime; uint256 endTime; }
• Validation: block.timestamp <= startTime and startTime < endTime for new or rescheduled rewards.
• Token: Any ERC-20 except the vault’s share token. The underlying can be used as a reward.

For exact function signatures, revert reasons, and events, read the vault API in this skill when implementing calls or debugging.