VotingEscrow¶
ELI5: Deposit TARE for a chosen lock period (up to 4 years). Longer lock = more voting power that slowly decreases until unlock.
What you can do¶
| Function | Effect |
|---|---|
create_lock(amount, unlock_time) |
New lock |
increase_amount |
Add TARE to lock |
increase_unlock_time |
Extend lock |
withdraw |
After unlock, retrieve TARE |
Flywheel fit¶
Governance input token for gauge votes → Keep allocations + bribe eligibility.
Contract walkthrough¶
VotingEscrow.vy — Curve-style ve mechanics:
- Linear decay of voting power from lock time to unlock
MAXTIMEbounded[1 week, 4 years]at deploycheckpoint()updates global and user vote bias/slopecreate_lock_with_permitforwards ERC-2612 permit on TARE — VE does not implement its own permit
def create_lock(_value: uint256, _unlock_time: uint256):
# Pull TARE, update slopes, mint ve balance
...
balanceOf(addr, t) — voting power at timestamp t via slope integration.
flowchart LR
TARE[TARE token] --> VE[VotingEscrow]
VE --> vePower[veTARE voting power]
vePower --> GC[GaugeController.vote]
What can go wrong¶
Risks
- Locked TARE illiquid until unlock (no early exit).
- TARE price risk while locked.
- Fee-on-transfer / rebasing TARE not supported.
Source: khomdev-veforge/src/VotingEscrow.vy