How to Extend or Transfer a Token Lock on Arc

A lock isn't a set-and-forget artifact — it's a live commitment with an expiry date, and managing it well is part of a project's ongoing credibility. Two operations exist for that management: extending the duration (always possible) and transferring the lock's ownership (for real organizational changes). Shortening is not an operation, by design — and that asymmetry is the entire reason locks are worth anything.

Works on Arc testnet today; mainnet September 16, 2026.

Why can locks extend but never shorten?

Because a lock's value is exactly the set of things its owner cannot do. When a buyer verifies your lock (as they will), the expiry date is a promise with teeth only if no path exists to break it early — a lock that could be shortened is a promise that could be unmade, which is to say no promise at all. So Team Finance's contracts enforce the asymmetry: duration moves in one direction. Extending strengthens the commitment and is always available; early release doesn't exist, for anyone, in any circumstance, including yours. If that feels constraining while you're setting a duration, that's the feature working — pick a duration you can honor, knowing you can lengthen but not escape it (why the commitment matters more on this chain).

When should you extend a lock?

The strategic answer: before anyone asks. An expiry date is public, and diligent holders read an approaching one as a countdown to decision — the projects that extend months early convert a looming question into a demonstrated answer, while projects that let expiry arrive un-extended get treated as unlocked from that day forward (what expiry actually means). Natural extension moments: well ahead of expiry as routine hygiene (a quarter out is comfortable); at milestones, where extending alongside good news compounds both signals; during raises or listings, where a longer lock is cheap credibility exactly when scrutiny peaks; and whenever your own roadmap extends — liquidity commitment should outrun the promises made on top of it. Extension is also the honest response to a wobbly market: supply certainty is one of the few reassurances a team can provide that costs nothing but optionality.

How do you extend, step by step?

Step 1 — Open your lock. Team Finance → your locks, with the wallet that owns the lock connected, on Arc. Your active locks are listed with expiries.

Step 2 — Choose Extend and set the new date. The new expiry must be later than the current one — the interface won't accept anything else, which is the one-way property enforced in software. [SCREENSHOT: lock extension flow on Arc testnet showing current vs new expiry]

Step 3 — Confirm. A flat USDC-quoted fee plus cents of Arc gas; the extension is final in under a second and your public lock page updates immediately — same certificate URL, new date, so every link you've already published now shows the stronger commitment.

Step 4 — Announce it. An extension nobody hears about wastes half its value. One line with the lock page link is enough; the page is the proof.

When is transferring ownership legitimate — and when is it a red flag?

Lock ownership means control of the owner-side operations: extending, and receiving the assets at expiry. Transferring it is the right tool for real structural changes: moving from a founder's wallet to a multisig or treasury as a project matures (the most common and healthiest case), handing over during an acquisition or formal team transition, or consolidating several early locks under one operational wallet. The flow mirrors extension: open the lock, choose transfer, enter the new owner address, confirm — with the care that step deserves, since lock ownership is not something you recover from a typo. [SCREENSHOT: ownership transfer confirmation showing new owner address]

Read it from the holder's side too: a transfer changes who will control the liquidity at expiry, and it's visible on-chain. Transfer to a published multisig alongside an announcement reads as maturation; a quiet transfer to an unknown fresh wallet near expiry reads as pre-positioning for an exit, and holders running rug-pattern checks treat it accordingly. Projects should therefore announce transfers with the same prominence as the original lock — the transparency is the point.

FAQ

Can I shorten a Team Finance lock or unlock early? No — under any circumstances. Duration extends only. This is enforced by the contract, not policy, and it's what makes the lock meaningful to holders.

Does extending change my lock's certificate URL? No — the same public lock page updates with the new expiry, so previously shared links show the extension automatically.

What does extending or transferring cost? A flat fee quoted in USDC before confirming, plus Arc gas at cents (testnet averaged ~$0.004).

Can vesting schedules be extended the same way? Lock-style duration rules apply across Team Finance products — durations lengthen, never shorten. Deployed vesting schedules' release terms can't be quietly rewritten either; plan them carefully upfront.

Is a lock transfer visible to holders? Yes — ownership changes are on-chain and visible from the lock page and Arcscan. Announce transfers proactively; discovered-not-disclosed is a bad look for a good action.