Introduction
ArcFlows is a token distribution protocol on Arc. Launchpads create supply. ArcFlows decides when that supply can move. After a token is created, a project deposits an ERC-20 amount into an immutable vault under a schedule. Holders verify the position from a public URL. The beneficiary claims when the clock allows. Nobody else can.
The product is built for the minutes after a pad create, when a deployer still holds a leftover allocation or a dev buy, and for the slower work of team and investor vesting. It is not a launchpad, a DEX, a chart, or an LP locker. Those jobs stay with the pad and the market.
Gas on Arc is USDC. There is no second gas token to acquire before a lock. Confirmations finalize in under a second, so the preview you sign is the position that appears.
Concepts
Every ArcFlows position is an on-chain record: token, beneficiary, creator, credited amount, claimed amount, start, cliff, and end. Tokens leave the creator wallet at creation. They sit in the vault until claim.
| Type | Release | Typical use |
|---|---|---|
| Hard lock | Nothing until end, then the remainder is claimable in full. | Dev buy, leftover allocation, “do not dump” proof. |
| Linear vest | Zero until cliff, then per-second unlock until end. | Team, investors, advisors. |
A hard lock is a vest whose cliff equals its end. The same contract stores both. Each position still gets its own proof page.
Connect a wallet
- Open Launch app.
- Connect MetaMask, Rabby, or another injected browser wallet.
- Switch the wallet to Arc if it is not already there.
- Hold USDC for gas and for the lock fee. Native gas and the USDC ERC-20 are the same asset with two decimal views. Never add those balances together.
After connect, the app opens the dashboard: overview, locks, vesting, streams, airdrops, escrow, and staking. You do not create an account. The wallet is the identity.
If the wallet is on the wrong network, the auth screen asks you to switch to Arc before it opens the console.
Create a hard lock
A hard lock seals an ERC-20 amount until a fixed unlock time. Nothing releases early. When that time is reached, only the beneficiary can claim what remains.
- Go to Locks.
- Pick a token from the connected wallet. The list is the set of ERC-20 balances that wallet holds on Arc.
- Set the amount. Percent chips and the slider leave enough USDC for the protocol fee and gas when you press MAX, so the last dollars are not drained by accident.
- Set duration with days, hours, and minutes, or with the calendar. Those controls stay in sync. Unlock time is stored and displayed in UTC.
- Choose who receives the unlock: yourself, another wallet, or a split across several addresses.
- Read the preview. Type, unlock time, duration, destination, amount, and fee must match the wallet prompt.
- Approve the token if the vault does not already have allowance, then sign the lock.
After the transaction confirms, the schedule cannot be cancelled, shortened, or redirected. Not by you. Not by an admin key. The vault does not store a draft. The signed payload is the schedule that exists on-chain.
If the token charges a transfer fee, the position is credited with what actually arrived in the vault, never more than that. A lock that would already be fully unlocked at confirm is rejected. A start time in the past is also rejected, so a backdated vest cannot look locked on a proof page while most of the bag is already claimable.
Beneficiaries and splits
The beneficiary is the only address that can claim. It is set at creation and cannot be changed. Default is the connected wallet.
A split creates one position per destination, each with its own proof URL and its own fee. Amounts are allocated by the percentages you enter. The last row receives the remainder so units are not lost to rounding.
| Action | Creator | Beneficiary | Anyone else |
|---|---|---|---|
| Create the lock | Yes | If they are also the creator | No |
| View the proof page | Yes | Yes | Yes |
| Claim unlocked tokens | No | Yes | No |
| Cancel or shorten | No | No | No |
Linear vesting
Vesting is for allocations that should unlock over time rather than on a single date. Create it from Vesting.
- Start. The clock for the linear portion. If omitted, the contract uses the block timestamp at creation.
- Cliff. Nothing is claimable before this timestamp, even if the linear formula would already have released some amount.
- End. At this timestamp the full credited amount is released.
After the cliff, released amount grows every second from start to end:
released = amount × (now − start) / (end − start), then clamped so that nothing is released before the cliff and everything is released at end.
The beneficiary can claim as often as they want. Each claim pays only what has accrued since the last claim. Restaking, streaming, or other modules do not rewrite this schedule.
Proof pages
Every position publishes at /lock/{id}. The page reads live contract state: amount, token, beneficiary, creator, countdown, claimed, claimable, and whether the schedule is a hard lock or a vest.
Holders do not connect a wallet to read it. Paste the URL next to the token contract. The rule is simple: if it is not on this page, it is not locked.
The beneficiary can claim from the same page once the clock allows. Copy proof link copies the canonical URL for that id.
Claiming
Only the beneficiary set at creation can call claim. The creator cannot pull early. Anyone can open the proof page; nobody else can move the tokens.
- Hard lock: after end, claim the full remaining balance.
- Vesting: claim whatever has accrued since the last claim. Repeat as it unlocks.
Claim from the proof page or from Your positions in the dashboard. If nothing is unlocked yet, the button stays disabled. A claim that would pay zero reverts.
Explorer
The Explorer lists public lock activity. Search by lock id, wallet, token, or transaction hash. It is a read surface, not a place to create positions.
Use it when a holder has a contract address and wants to know whether any ArcFlows positions exist for that token, without needing a tweeted URL.
Streams
Streams are continuous unlocks for payroll, grants, and other flows that should move every second rather than sit behind a single cliff. Create them from the dashboard with a token, recipient, amount, and duration. CSV batch create is supported for many recipients in one sitting.
Streams can be topped up and, where the module allows, transferred. They do not rewrite an existing hard lock. A lock that has already unlocked stays unlocked if the same wallet later opens a stream.
Airdrops
Airdrops are merkle campaigns. Recipients claim against a root, either instantly or into a vest/stream so the drop does not hit the market in one block. After the claim window, leftover unclaimed tokens can be clawed back. Claimed balances cannot.
An airdrop is not an ArcFlows token event. It is a distribution of whatever ERC-20 the campaign funded.
Escrow
Escrow funds a two-party deal on-chain. The buyer deposits. On delivery the funds release to the seller. If the deal fails, they refund. Both sides stay on the contract until that outcome. Escrow is not a time-lock of a meme allocation; it is a commercial hold.
Staking
Staking pools are permissionless. A publisher funds rewards. Stakers deposit and earn. Restake does not relock lots that already unlocked from a separate ArcFlows position. Staking yield is not a substitute for a hard lock, and a hard lock is not a stake.
Fees and USDC
Creating a lock pays a flat $10 USDC protocol fee, plus network gas in USDC. A split lock charges $10 per destination. The fee is pulled at creation, paid to the treasury, and never sits inside totalLocked. It cannot be claimed out of a position.
On Arc, USDC has two interfaces that share one balance. The native view uses 18 decimals and is for gas. The ERC-20 view uses 6 decimals and is for transfers, approvals, and the lock fee. Display a single USDC figure from the ERC-20 view. Do not convert, wrap, or double-count.
Protocol rules
- Tokens move into the vault at lock. They do not stay in the creator wallet.
- Valid schedule:
start ≤ cliff ≤ end, end in the future, duration at least the protocol minimum. - No cancel, no shorten, no reassignment after confirm.
- Only the beneficiary can claim.
- Fee and treasury logic cannot seize locked principal.
- If parameters change later, they apply to future creates, never to existing vault balances.
What a lock does not do
A lock is not a guarantee the token is safe. Honeypot, mint, tax, blacklist, and proxy upgrades on the token itself still exist. ArcFlows only enforces the time schedule on the balance it received.
It is not custody beyond the contract. You keep your wallet. There is no support process that can move someone else’s position. Canonical domain only. ArcFlows never asks for a signature that is not approve, create, claim, or an equivalent module action.
FAQ
Can a lock be cancelled?
No. Once the transaction confirms, amount and schedule are immutable. There is no admin cancel path over existing vault positions.
Is this the same as an LP lock?
No. LP lock belongs to the launchpad. ArcFlows locks wallet tokens so they cannot be sold until the schedule allows.
What pays for gas?
USDC on Arc. Native gas uses 18 decimals; the USDC ERC-20 uses 6. Same asset, two views. Never double-count.
Who can claim?
Only the beneficiary set at creation.
Is ArcFlows custodial?
The contract holds tokens until claim. No human key can redirect them. You keep your wallet.
Does a lock stop the team from minting more tokens?
No. It only covers the amount deposited. If the token can mint, that supply is outside the vault.
What if I lock the wrong amount or the wrong beneficiary?
You cannot edit it after confirm. Read the preview against the wallet prompt before you sign.
Is there an ArcFlows token?
No. Fees are USDC. There is no protocol coin and no promised airdrop of one.