FeeVest — Public Fee-to-Vesting on Bitcoin L1

How it works

Permissionless vesting in 5 steps

FeeVest combines public vesting creation with Synthetix-style revenue sharing — entirely on Bitcoin L1. No owner required for the core flow.

01

⚙️

Deploy & Initialize

Deploy the WASM contract. Owner calls initialize(revenueToken) once to set the single OP_20 token used for both vesting and revenue distribution.

02

🔓

Anyone Deposits & Vests

No owner needed. Any address calls depositAndVest(amount, beneficiary, cliff, duration). Tokens pulled via transferFrom and locked immediately.

03

💰

Deposit Protocol Revenue

Any address (fee router, DAO, individual) deposits revenue tokens. The global rewardPerToken accumulator updates in O(1) — zero iteration over beneficiaries.

04

⏳

Cliff Passes

Once the cliff block is reached, tokens begin vesting linearly. getPendingRelease = vested − already released. Computed per-block from immutable block height.

05

🎯

Release & Claim Revenue

Beneficiary calls release() for vested tokens and claimRevenue() for their proportional revenue share. CEI enforced. Reentrancy-protected.

Architecture

Built for correctness

Every design decision in FeeVest prioritizes safety, permissionlessness, and mathematical correctness on Bitcoin L1.

🔓

Permissionless Creation

Any address can fund a vesting schedule for any beneficiary. No owner restriction on depositAndVest(). Griefing mitigated by single-schedule-per-beneficiary guard.

depositAndVest(amount, beneficiary, cliff, dur)

📊

Synthetix Accumulator

Revenue distributed via rewardPerToken global accumulator. Each deposit is O(1). Claims computed instantly from stored debt snapshots — no loops ever.

rewardPerToken += (amount × 1e18) / totalLocked

🛡️

Persistent Reentrancy Guard

Lock flag is a StoredBoolean in blockchain persistent storage — not in-memory. Survives per-call class re-instantiation unique to OPNet's execution model.

StoredBoolean(_locked, false)

⏳

Block-Based Vesting

Cliff + linear release computed purely from block numbers — no timestamps, no oracle. Deterministic and manipulation-resistant on Bitcoin L1.

Blockchain.block.numberU256

✅

Strict CEI Pattern

State written before every external Blockchain.call(). Checks (including computeReleasable) → Effects (updateReward + state) → Interactions. Audited line-by-line.

checks → updateReward() → state → callTransfer()

🔢

SafeMath Everywhere

All arithmetic uses SafeMath.add/sub/mul/div. Zero floating point. No raw u256 operators. Rounding truncates toward zero, favoring the protocol.

SafeMath.mul(amount, PRECISION)

Mathematics

Revenue distribution — verified

Example: Alice 70% locked, Bob 30% locked. Two revenue deposits of 1 000 and 700 tokens.

Alice & Bob — end-state snapshot

Participant	Locked	Share	Deposit 1 (1 000)	Deposit 2 (700)	Total earned
🟠 Alice	7 000	70%	700	400 (4000 locked)	1 100 ✓
🔵 Bob	3 000	30%	300	600 (3000 locked)	600 ✓
Σ Total	10 000	100%	1 000	700	1 700 ✓

Initial Deposit

rewardPerToken += 1000 × 10¹⁸ / 10000 = 10¹⁷

Global accumulator updated in O(1). No loops over beneficiaries.

Claim (Alice — 7 000 locked)

earned = 7000 × 10¹⁷ / 10¹⁸ = 700 ✓

Bob earns 300. Total = 1 000. No dust left.

After partial release (Alice releases 3 000)

stored pending = 700 (captured first) lockedBalance = 7000 − 3000 = 4000 rewardDebt = currentRpt

Next deposit of 700 tokens:

rewardPerToken += 700 × 10¹⁸ / 7000 = 10¹⁷ Alice new earn = 4000 × 10¹⁷ / 10¹⁸ = 400 Alice total = 700 + 400 = 1100 ✓ Bob total = 3000 × 2×10¹⁷ / 10¹⁸ = 600 ✓ Grand total = 1700 = deposited ✓

Result: 1100 + 600 = 1700 — perfectly balanced.

Live Dashboard

Interact with FeeVest

Connect your OP Wallet to vest tokens, release vested amounts, claim revenue, or deposit protocol fees.

Contract Configuration

FeeVest Contract Vault

Token Address OP_20

Your Wallet Auto-filled

⚡

Connect your OP Wallet

View your vesting schedule, pending revenue, and interact with FeeVest directly from your browser.

Total Locked

—

Revenue Deposited

—

Your Releasable

—

Pending Revenue

—

Release Vested Tokens

Claim your linearly vested tokens. Nothing released until cliff block passes. Reentrancy-protected, CEI-enforced.

Available: —

Claim Revenue Share

Claim your proportional share of all protocol revenue deposited since your last claim. Computed via O(1) reward-per-token accumulator.

Pending: —

Deposit & Vest Public

Permissionless. Approve tokens, then lock them for any beneficiary with cliff + linear vesting. You pay the tokens, beneficiary receives the vesting.

Beneficiary Address

Amount (tokens, e.g. 1 or 1.5)

Cliff (blocks before vesting starts)

Duration (total blocks to vest 100%)

Vesting parameters

Cliff: blocks from now before anything vests
Duration: total blocks for 100% to vest
Formula: vested = amount × (block − start) / duration

Example: cliff=10, duration=100
→ After 10 blocks: 0 releasable
→ After 55 blocks: 55% releasable
→ After 100 blocks: 100% releasable

Note: one active schedule per beneficiary.
New schedule allowed only if previous is not present.

Deposit Protocol Revenue Public

Anyone deposits revenue tokens for proportional distribution to locked-token holders. The increaseAllowance + depositRevenue flow runs in sequence automatically.

Amount (tokens, e.g. 1 or 1.5)

How revenue flows

1. You call increaseAllowance(vault, amount)
2. Vault pulls tokens via transferFrom
3. rewardPerToken accumulates globally
4. Each beneficiary's pendingRevenue grows
5. No loops — O(1) per deposit ✓

⚙️ Initialize FeeVest (one-time, owner only)

Must be called once by owner right after deployment. Sets the OP_20 token address used for both vesting and revenue distribution. Uses the Token Address from the config panel above. Cannot be changed after initialization.

🪙 Mint FEE Tokens (deployer only)

Mint FEE tokens to any address for testing. Only the contract deployer can call this.

After initialization all core functions are permissionless — no further owner actions required for normal protocol operation.

Activity

Wallet connected. Waiting for actions…

Security

AI-assisted audit — 0 critical findings

All 29 critical vulnerability patterns and 20 OPNet-specific attack surfaces checked. Audited by OPNet Bob MCP.

0

Critical

0

High

0

Medium

1

Low (design)

2

Info

✅

SafeMath — all u256 arithmetic ops

✅

StoredBoolean — persistent reentrancy guard

✅

Strict CEI — computeReleasable before updateReward

✅

tx.sender — never tx.origin

✅

No loops — O(1) accumulator pattern

✅

No floats — pure integer arithmetic

✅

Block height — no timestamp oracle

✅

BytesWriter — buffer sizes match writes

✅

increaseAllowance — ATK-05 mitigated in frontend

✅

AddressMemoryMap — no unsafe built-in Map

Permissionless Fee-to-Vestingon Bitcoin L1