feat(cct-sdk): Add set rebalancer op solana

[mervin-link]

What

• Add Solana lock-release token pool setRebalancer unsigned and signed CCT operations
• Expose the operations through SolanaTokenManager
• Document 11111111111111111111111111111111 as the default/zero rebalancer address that disables rebalancing

Why

• Enable pool owners to configure or disable the liquidity rebalancer through the SDK

[vercel]

You must have Developer access to commit code to Chainlink Labs on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes.

Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles

[aelmanaa]

✅ APPROVE — 0 blockers, 0 majors. Doc-polish nits only.

This op is a faithful structural twin of the already-approved setCanAcceptLiquidity, correctly grounded on-chain, and live-proven end-to-end (including the rebalancer gate).

---

Verification: Green + On-Chain Grounded + Live Devnet Proven

TypeScript: tsc 0 diagnostics (net-new/changed files)

On-Chain/bs58 Grounded — CORRECT:

• Instruction: matches set_rebalancer(ctx: SetConfig, rebalancer: Pubkey) exactly
• Accounts: SetConfig = { state(mut PDA), mint(ro), authority(Signer, owner) } — matches
• PDA seed ccip_tokenpool_config = on-chain POOL_STATE_SEED ✓
• Default address disables rebalancing (permissive on-chain, correctly NOT rejected) ✓

@throws Attribution: Correct (no early state reads; not-owner surfaces as CCTTxFailedError at simulation)

✅ LIVE Devnet — Full lifecycle proven (real lock-release pool; rebalancer gating verified):

Operation	Proof	Result
Set rebalancer → fresh address B	tx 489hkmYX…	✅ Read-back: rebalancer == B
Unauthorized gate: payer (no longer rebalancer) calls withdrawLiquidity(100)	Simulation rejects	✅ AnchorError: account: authority · Unauthorized · err 6002
Disable → Pubkey::default() (zero address)	tx 2Sm1ntVK…	✅ Read-back: rebalancer == 11111111111111111111111111111111
Restore → payer	tx vKSEUCwJ…	✅ Read-back: rebalancer == payer
Same withdrawLiquidity(100) with rebalancer=payer	tx 28gMb4dc…	✅ Succeeds (balance transferred)

The only variable between blocked and successful withdraw is the rebalancer field — proving both that the op writes it and the field gates who may move liquidity.

---

Cross-Family Note: EVM has setRebalancer in the LockRelease ABI but no EVM CCT op wraps it. Solana-only is correct here (flag for future parity if needed).

[aelmanaa]

Comment 1 — Nit 1 (DX): Add @example for the disable path

Both facade @examples pass a real rebalancer; disabling (the special, semi-destructive path) has no copy-pasteable snippet. Precedent: setTokenAuthority has a dedicated @example for the revoke path.

Suggested fix: Add an @example to the setRebalancer facade:

* @example Disable rebalancing
* ```ts
* const cct = SolanaTokenManager.fromChain(chain)
* await cct.setRebalancer({
*   tokenAddress: mint,
*   poolType: 'lock-release',
*   rebalancer: PublicKey.default.toBase58(), // disable
*   wallet,
* })
* ```

---

Comment 2 — Nit 2 (DX): Add @see cross-link to setCanAcceptLiquidity

The two ops jointly gate lock-release liquidity:

• rebalancer = WHO may move it
• canAcceptLiquidity = WHETHER the pool accepts it

The @see sections only link generate ↔ execute within each op. Precedent exists for cross-linking related ops (e.g., configureAllowlist ↔ removeFromAllowlist).

Suggested fix: Add reciprocal @see links:

• On generateUnsignedSetRebalancer and setRebalancer: @see {@link setCanAcceptLiquidity}, {@link generateUnsignedSetCanAcceptLiquidity}
• (Reciprocal link on the twin outside this delta)

[aelmanaa]

Comment 3 — Nit 3 (DX): Spell out the consequence in @remarks

Current doc: "disables rebalancing" (states how — zero address).
Missing: what happens — until a new rebalancer is set, no account can provide or withdraw pool liquidity (proven live above).

Sibling ops spell such consequences out in @remarks (e.g., setRateLimitAdmin).

Suggested fix: Add a @remarks to both facade methods:

* @remarks
* ⚠️ **Consequence:** Rebalancer is the address allowed to provide or withdraw liquidity.
* Setting the zero address (`11111111111111111111111111111111`) removes the rebalancer; until a new one
* is set, **no account can provide or withdraw liquidity**, even liquidity already in the pool.
* This does not affect whether the pool accepts liquidity — see {@link setCanAcceptLiquidity}.

---

Comment 4 — Nit 4 (DX): Disambiguate authority vs rebalancer roles

• rebalancer: data written to pool state (NOT a transaction signer)
• authority: pool owner who signs this transaction

Suggested fix: Add a half-clause to the rebalancer parameter doc:

* @param rebalancer Address authorized to provide or withdraw pool liquidity (stored on the pool; not a transaction signer).

---

Comment 5 — Nit 5 (Arch): Cosmetic parse field order

set-rebalancer.ts:parse resolves payer before tokenAddress/rebalancer/poolProgram, whereas set-can-accept-liquidity.ts resolves poolProgram first. Only affects which CCTParamsInvalidError.param surfaces first if multiple params are invalid (harmless). For byte-for-byte twin symmetry, align the order.

[aelmanaa]

Summary: ✅ APPROVE

Status: 0 blockers, 0 majors. Five optional doc polish nits (Comments 1–5 above).

This is a structural twin of setCanAcceptLiquidity. It correctly:

• ✅ Matches on-chain set_rebalancer(ctx: SetConfig, rebalancer: Pubkey) exactly
• ✅ Scopes to lock-release via compile-time type checking + runtime validation
• ✅ Implements the gating correctly (rebalancer address gates provideLiquidity/withdrawLiquidity)
• ✅ Proven live end-to-end on devnet (4 devnet txs showing the full lifecycle and cascade)
• ✅ Proper error handling (@throws correct, no state-read before build)
• ✅ Naming/pairing, defaults, barrels, registration all mirror the twin

Non-Issues (verified):

• ✅ Lock-release scoping enforced at compile-time (burn-mint rejected)
• ✅ Authority validation in execute (wallet must sign)
• ✅ Zero address is permissive on-chain (correctly NOT rejected)
• ✅ Cross-family: EVM has no CCT wrapper — Solana-only is correct

---

Recommendation: The op is correct, on-chain/bs58 grounded, and live-proven. The five nits are optional doc polish:

• Nit chore: ccip-data as codeowners #3 (add @remarks spelling out the consequence of disabling) is highest-value
• Nits Chore/publish ci #1–2 improve discoverability and cross-linking
• Nits feat: parseBytes #4–5 are low-priority cosmetics

Ready to ship after optional nits are applied.

[mervin-link]

Summary: ✅ APPROVE

Status: 0 blockers, 0 majors. Five optional doc polish nits (Comments 1–5 above).

This is a structural twin of setCanAcceptLiquidity. It correctly:

• ✅ Matches on-chain set_rebalancer(ctx: SetConfig, rebalancer: Pubkey) exactly
• ✅ Scopes to lock-release via compile-time type checking + runtime validation
• ✅ Implements the gating correctly (rebalancer address gates provideLiquidity/withdrawLiquidity)
• ✅ Proven live end-to-end on devnet (4 devnet txs showing the full lifecycle and cascade)
• ✅ Proper error handling (@throws correct, no state-read before build)
• ✅ Naming/pairing, defaults, barrels, registration all mirror the twin

Non-Issues (verified):

• ✅ Lock-release scoping enforced at compile-time (burn-mint rejected)
• ✅ Authority validation in execute (wallet must sign)
• ✅ Zero address is permissive on-chain (correctly NOT rejected)
• ✅ Cross-family: EVM has no CCT wrapper — Solana-only is correct

Recommendation: The op is correct, on-chain/bs58 grounded, and live-proven. The five nits are optional doc polish:

• Nit chore: ccip-data as codeowners #3 (add @remarks spelling out the consequence of disabling) is highest-value
• Nits Chore/publish ci #1–2 improve discoverability and cross-linking
• Nits feat: parseBytes #4–5 are low-priority cosmetics

Ready to ship after optional nits are applied.

@aelmanaa Addressed all your comments.