Skip to content

Remove no-lockbox LockReleaseTokenPool in favour of the lockbox variant - #888

Merged
krebernisak merged 8 commits into
mainfrom
feat/tp-lockbox-only
Sep 28, 2026
Merged

krebernisak merged 8 commits into
mainfrom
feat/tp-lockbox-only

Conversation

@krebernisak

Copy link
Copy Markdown
Collaborator

What

Removes the no-lockbox LockReleaseTokenPool so LockReleaseLockboxTokenPool
is the only lock/release variant.

The deleted variant duplicated the same lock/release semantics with a weaker
custody model — liquidity and fees held in the pool's own jetton wallet behind
an accruedFees ledger. That pins custody to a contract that cannot be
upgraded without migrating balances. lock_release_lockbox + JettonLockBox
separates long-lived custody from upgradable pool logic, matching EVM's
LockReleaseTokenPool + ERC20LockBox split, which is the parity target.

Changes

  • Contracts: delete contracts/ccip/pools/lock_release/**, its compile
    script, generated wrapper, and dedicated spec. Update registries
    (Acton.toml, wrappers/gen/index.ts, generateContractsPkg.ts).
  • Go bindings: delete pkg/ccip/bindings/tokenpool/lockrelease. Register
    LockReleaseLockboxTokenPool and JettonLockBox in pkg/bindings/index.go
    (the latter was previously unregistered despite the bindings existing).
  • Deployment: DeployTokenPoolForToken retargeted to the lockbox variant.
    The pool stores the lockbox address, so the lockbox is deployed first; the
    pool address is derived from its final storage and granted OPERATOR_ROLE
    before the pool itself is deployed. testadapter funds the lockbox wallet
    instead of the pool wallet.
  • Tests: shared tests/ccip/helpers/lockbox.ts; the OffRamp and e2e
    harnesses are repointed to the lockbox pool.
  • Docs: variant tables and references updated; historical audit findings
    kept with a removal note rather than rewritten.

Reviewer notes

deployment/ccip/1_6_0/sequences/tokens.go is the only file with new
production logic. Two non-obvious ordering constraints live there: the lockbox
is built before the pool because the pool stores its address, and the
OPERATOR_ROLE grant must follow init because onInit rebuilds the RBAC data.

@krebernisak
krebernisak requested a review from a team as a code owner September 15, 2026 16:56
duck-types
duck-types previously approved these changes Sep 21, 2026
Base automatically changed from feat/tp-only-router to main September 22, 2026 20:35
@krebernisak
krebernisak dismissed duck-types’s stale review September 22, 2026 20:35

The base branch was changed.

vicentevieytes
vicentevieytes previously approved these changes Sep 23, 2026
duck-types
duck-types previously approved these changes Sep 24, 2026
The standalone lock_release pool duplicated the lock/release semantics of
LockReleaseLockboxTokenPool with a weaker custody model: liquidity and fees
held in the pool's own jetton wallet behind an `accruedFees` ledger, which
pins custody to a pool that cannot be upgraded. The lockbox variant matches
EVM's LockReleaseTokenPool + ERC20LockBox split, so it is the one we ship.

Deployment now derives the pool address from its final storage, deploys the
JettonLockBox first, and grants OPERATOR_ROLE to the precomputed pool address
before deploying the pool. JettonLockBox is registered in pkg/bindings so the
deployment pipeline can resolve it. Test harnesses gain a shared lockbox
helper; liquidity is minted to the lockbox rather than the pool.
@krebernisak
krebernisak enabled auto-merge (squash) September 28, 2026 17:43
@krebernisak
krebernisak merged commit dbc5f1e into main Sep 28, 2026
39 checks passed
@krebernisak
krebernisak deleted the feat/tp-lockbox-only branch September 28, 2026 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants