A time-lock layer for tokens on Arc

01 Abstract

Crypto markets still treat “tokens are locked” as a social claim. Teams post screenshots. Spreadsheets stand in for contracts. Holders cannot independently verify amount, beneficiary, or unlock time. Launchpads often lock liquidity. Developer wallets remain liquid. Duplicate tickers make a tweet an unreliable identifier. The contract address is the only one that matters, and it is rarely paired with a page that reads a vault.

ArcFlows is an immutable ERC-20 vault on Arc. A creator deposits tokens under a schedule. After the transaction confirms, nobody can cancel, shorten, or redirect the position. Only the named beneficiary can claim, and only when the clock allows. Every position has a public proof URL that reads live state. When that URL is shared, the card unfurls the same fields.

Arc is Circle’s stablecoin-native chain. Gas is USDC. Finality is deterministic and sub-second. A lock can feel like a receipt rather than a multi-block wait. Fees are USDC. There is no ArcFlows coin, no emission schedule, and no promised airdrop of a protocol token.

02 Introduction

Token distribution is a time problem. A team that intends not to sell still has to prove it. Investors who accepted a cliff still have to receive only what has accrued. A community that was told “dev locked” still has to check. Existing rails solve this on other networks: Streamflow on Solana, Sablier on several EVM chains. Arc needed a native one that treats USDC gas and public proof as product, not as an afterthought port.

ArcFlows is that rail. The first job is narrow on purpose: seal an amount, publish a page, let anyone verify without permission. Vesting, streams, airdrops, escrow, and staking extend the same surface without weakening the rule that existing vault principal cannot be moved by an admin.

This litepaper is a product and protocol description. It is not a securities offering, not investment advice, and not a token whitepaper.

03 The problem

On a new chain, pads ship quickly. Liquidity lock is often included. Wallet lock is not. Three failures repeat.

Unlocked developer supply

An LP lock stops a pool from being pulled. It does not stop tokens sitting in a deployer wallet from hitting the market. Holders who equate “LP locked” with “team locked” are reading the wrong primitive. If a pad sent 100% of supply into LP, the remaining risk is the dev buy. That balance needs its own vault.

Proof as theater

Duplicate tickers are common. A tweet is not an identifier. A PNG of a dashboard is not state. Without a URL that reads a contract, “team locked until Q3” is unverifiable and therefore cheap to fake. The market then discounts all such claims, including honest ones.

Manual transfers do not scale

Team, investors, payroll, and community drops need schedules. Ad-hoc sends create operational error and no public record. Cliff-then-linear release is a known pattern. It should exist as a contract, not as a calendar reminder.

04 Design principles

The vault is designed around five constraints.

1. Immutability after write. A position that can be cancelled by the creator is not proof of anything. ArcFlows does not offer that path on vault principal.
2. Pull, then hold. Tokens leave the creator at creation. A lock that left tokens in the deployer wallet would be a promise, not a position.
3. Beneficiary exclusivity. Only the address set at creation can claim. Visibility is public. Control is not.
4. Proof as a default. If holders cannot open a page without signing in, the lock exists only for the creator. Every position publishes.
5. Fees cannot seize principal. Protocol revenue is charged at creation in USDC. It never sits in the locked balance and cannot be claimed out of it.

05 Position model

A position is a fixed tuple written once. The contract stores token, beneficiary, creator, credited amount, claimed amount, start, cliff, and end. Credited amount is what the vault actually received. For tokens that take a transfer fee, that may be less than the amount the caller intended. The position is never credited more than arrived.

Indexes exist by creator, beneficiary, and token so a wallet or a contract address can list its positions without an off-chain indexer. The explorer and proof pages can read the same arrays.

06 Schedules

Two shapes cover the jobs that matter on day one.

Hard lock

Cliff equals end. Nothing is claimable until the unlock timestamp. Then the remaining credited amount can be claimed in full. This is the anti-dump primitive: a public, dated commitment over a specific balance.

Linear vest

After the cliff, released amount grows every second between start and end:

released(t) = amount × (t − start) / (end − start)

Before the cliff, released is zero even if t has passed start. At or after end, released is the full amount. Claim pays the difference between released and claimed. Repeat claims are allowed. A vest whose start is already in the past is rejected at creation so a proof page cannot advertise a lock while most of the bag is already liquid.

A schedule that would already be fully unlocked at confirm is also rejected. A lock that is already over is not proof of anything.

07 Lifecycle

The path is short on purpose.

1. The creator approves the ERC-20 and USDC fee spend.
2. lock pulls the fee to treasury, pulls the token into the vault, writes the position, and emits Locked and FeePaid.
3. The proof page and share card read that record.
4. When the schedule allows, the beneficiary calls claim. Tokens move to that address. Claimed is emitted. Claimable of zero reverts.

There is no pause on existing principal, no upgrade hook that rewrites a position, and no admin function that changes beneficiary. Reentrancy on claim is blocked. If protocol parameters ever change, they apply only to future creates.

08 Why Arc

ArcFlows is written for Arc’s accounting model, not copied from an ETH-gas chain and patched.

USDC as gas

Users already hold the fee asset. There is no second token to source before a lock. Native USDC (18 decimals, gas) and the USDC ERC-20 (6 decimals, application transfers) share one balance. Applications must display a single figure and must never sum the two views. The lock fee is charged in the ERC-20 view. Gas is paid in the native view. Same asset.

Sub-second finality

Arc finalizes in well under a second. The preview a user signed is the position that appears. Proof pages do not wait extra blocks to know the vault already holds the tokens. That matters when the lock itself is the public signal, posted next to a contract address within minutes of a create.

Stable fees

Denominating gas in dollars makes the cost of locking predictable. A team deciding whether to prove a schedule is not also taking a volatile gas-token view. Predictable cost is part of making proof a habit rather than a trade.

09 Public proof

A lock that only the creator can see is a private diary. ArcFlows publishes every position at a stable path. The page shows amount, token, beneficiary, countdown, claimed, and claimable, read from the contract. No account is required to view it.

Sharing that URL is the distribution layer. When it is posted, the open-graph card is rendered from the same fields, including unlock time and share of total supply. Investors stop asking for screenshots. Duplicate tickers stop hiding behind a PNG. The operational rule for the market is: if it is not on the proof page, it is not locked.

An explorer lists activity by lock id, wallet, token, and transaction so a holder who was never sent a link can still search.

10 Modules

Locks and vesting are the core. Adjacent modules reuse the same rule: they must not create an admin path over vault principal that already exists.

11 Fee design

ArcFlows charges a flat USDC fee at lock creation, currently ten dollars in the ERC-20 six-decimal view, plus network gas in USDC. A split create charges that fee once per destination. The fee is pulled to treasury before the position is written. It never enters totalLocked.

Later modules may price per recipient, per streamed dollar, or per reward. None of those fees can move tokens that are already locked. Protocol revenue is not a backdoor into the vault.

There is no protocol token that captures fees, no vote-escrow, and no emission. Users pay USDC. That is the entire commercial surface described here.

12 Security

The vault is intentionally small. Positions are immutable after write. Claim is non-reentrant. Token amounts use a width that fits real supplies without wasting storage. External token calls require a successful return; fee-on-transfer tokens are credited by balance delta, not by the amount the caller specified.

Minimum duration and “end must be in the future” exist so a confirmed lock is actually a lock. Start-in-the-past is rejected for vests that would otherwise present as locked while already largely claimable.

Treasury is set at construction and is not rotatable through an owner. There is no owner on the lock vault that can retarget principal. Users should still treat unaudited bytecode with caution and should verify the canonical deployment they are asked to approve.

13 Trust boundaries

ArcFlows trusts the chain’s clock, the ERC-20 it received, and the user’s wallet. It does not trust the token’s future mint, tax, blacklist, or upgrade. A lock covers the deposited balance. It does not cap total supply. It does not make a honeypot sellable. It does not freeze a malicious admin on the token contract.

The interface never asks for a signature that is not approve, create, claim, or an equivalent module action. Canonical domain only. Pages that impersonate ArcFlows to run “airdrop checkers” are outside the protocol and should be treated as hostile.

Software, not a custodian beyond the contract. Not investment advice. A public proof page is evidence of a schedule, not of a project’s quality.

14 What this is not

• Not a launchpad, AMM, or chart.
• Not an LP lock. That is the pad.
• Not a custodian beyond the smart contract.
• Not a guarantee that a token is safe.
• Not a protocol token. There is no ArcFlows coin, no tokenomics, and no promised airdrop. Fees are USDC.

The job stays narrow: time-lock a balance, publish the proof, let holders verify without asking permission.

15 Closing

Markets discount claims they cannot check. ArcFlows makes the check cheap: a URL, a vault, a clock. Arc makes the act of writing that vault cheap and final. Together they turn “dev locked” from a caption into a position.

Operational detail lives in the product documentation. To open a position, launch the app on Arc.