QUIVER

Use cases

Team vesting

Every launch says the team allocation is locked. Almost none of them can show it. This is the pattern that turns a promise into something a stranger can verify before they buy.

The problem with saying it

A team wallet holding 20% of supply with a screenshot of a spreadsheet is not a lock. It is a claim. The holder can move the whole bag in one transaction, and the only thing standing between the market and that transaction is intent.

Burned LP solved this for liquidity, and it worked because it is checkable: anyone can read the burn and stop worrying. The team allocation, which is the part that actually rugs people, never got the same treatment.

The pattern

Stream your own allocation to yourself, then give up the right to cancel. You end up with exactly what you had, released on a schedule, and a permanent on-chain fact that says you cannot take it early.

  1. Create the stream to yourself

    The sender and the recipient are both you. This is not a trick, it is the normal use of the contract: you are moving your own tokens into an escrow with a clock, and minting yourself the claim.

  2. Create it cancelable, at first

    Sounds backwards for a trust exercise, and it is deliberate. It gives you a window to check the schedule is what you meant before you make it permanent. A wrong end date on an irrevocable stream is wrong forever.

  3. Verify the stream, then renounce

    Read it back from the chain, confirm the numbers, then call renounceCancel. From that block on, cancel reverts forever and the tokens are only reachable through the schedule.

  4. Publish the id

    Anyone can now read the stream and check it themselves. That is the point of the exercise: the claim stops depending on you being honest.

The standard shape

Four years with a one year cliff is the default for a reason: it is the shape the market already understands, so it needs no explaining. The app ships it as the Team vesting preset.

Duration
4 years from start to end.
Cliff
1 year. Nothing withdrawable before it.
At the cliff
25% of the grant unlocks in one lump, because it accrued all year behind the gate.
After the cliff
The remaining 75% releases second by second over three years.
One stream per contributor
Not one for the whole team. Each person's schedule is theirs, and each can be handled independently.

Cancelable per contributor, not per team

A contributor still proving themselves is a reason to keep the stream cancelable. A founder asking the market for trust is a reason to renounce. These are different questions, and one stream per person lets you answer them separately.

Doing it from a terminal

The full sequence, with a four year schedule and a one year cliff. Timestamps are absolute, so they are computed from the current block rather than passed as durations.

bash · a 4 year stream with a 1 year cliff
RPC=https://rpc.mainnet.chain.robinhood.com
QUIVER=0x2866D49f364a70383591a958354A89F6BDf050f2
TOKEN=0xYourToken
ME=0xYourTeamWallet

AMOUNT=$(cast to-wei 10000000)     # your allocation, 18 decimals
START=$(cast block latest --field timestamp --rpc-url $RPC)
CLIFF=$((START + 31536000))        # +1 year
END=$((START + 126144000))         # +4 years
FEE=$(cast call $QUIVER "creationFee()(uint256)" --rpc-url $RPC)

cast send $TOKEN "approve(address,uint256)" $QUIVER $AMOUNT \
  --rpc-url $RPC --private-key $KEY

# cancelable: true, for now. You verify first, then renounce.
cast send $QUIVER \
  "createStream(address,address,uint128,uint40,uint40,uint40,bool)(uint256)" \
  $TOKEN $ME $AMOUNT $START $CLIFF $END true \
  --value $FEE --rpc-url $RPC --private-key $KEY

Then verify, and only then renounce

Read the stream back and check every field against what you meant to sign. The id is in the StreamCreated event of the transaction above.

bash · check, then close the door
# read it back: sender, start, cliff, cancelable, canceled,
# token, end, deposited, withdrawn
cast call $QUIVER \
  "getStream(uint256)((address,uint40,uint40,bool,bool,address,uint40,uint128,uint128))" \
  $ID --rpc-url $RPC

# nothing withdrawable until the cliff
cast call $QUIVER "withdrawableOf(uint256)(uint128)" $ID --rpc-url $RPC

# one way door: after this, cancel() reverts forever
cast send $QUIVER "renounceCancel(uint256)" $ID \
  --rpc-url $RPC --private-key $KEY

What a stranger can check

This is the part that matters. Someone who has never met you, and has no reason to believe anything you say, can read all of this without asking you for anything:

  • cancelable == false means you cannot take it back. Not with a multisig, not with an upgrade, not by asking us.
  • deposited is what the contract actually holds for that stream, measured on receipt rather than taken on trust from a parameter.
  • start, cliff and end are the real schedule, and nothing can rewrite them.
  • withdrawn shows exactly how much you have taken so far, so nobody has to guess.

It is the burned LP argument, applied to the part of the supply that actually rugs people, and it costs one transaction to make permanent.

The honest caveats

A stream proves one thing, not everything

It proves that this allocation unlocks on this schedule. It says nothing about the rest of the supply. A team that streams 5% and keeps 40% liquid has proven very little, and a reader who checks the stream should also check what was never streamed.

Two more things worth being straight about. Vesting is not a lockup once the tokens vest: whatever has vested can be withdrawn and sold, which is the intended behaviour, not a hole. And the NFT is transferable, so a team can sell the claim to the future allocation even while it cannot touch the tokens early. Renouncing cancellation proves you cannot take it early. It does not promise you will never sell it at all.

No third party has audited this contract, though it carries 129 tests and two security reviews. Read Security and limits before you commit a real allocation to it.