ckSOL’s New Deposit Pipeline Treats Solana Sweep Metadata as the Minting Gate

The most consequential recent change in ICP’s Solana integration is not a new signature algorithm. It is a stricter decision about when a deposit is allowed to become ckSOL.

Recent changes in the dfinity/cksol repository move deposits toward a sweep-based lifecycle. A user calls deposit_sol, the minter queues the deposit, and a timer sweeps funds from deposit addresses into the minter’s main Solana address. The sweep can batch as many as 10 deposits, while the source addresses retain the Solana rent-exemption balance.

The important boundary arrives after the transaction is finalized. In merged PR #222, the minter fetches the finalized transaction, compares the executed message with the plan it recorded, checks the deposit-address balance changes, confirms that the source accounts remain rent-exempt, and verifies that the main address received the expected amount. Only then does it record the credited sweep and queue the corresponding mints.

That design makes transaction metadata part of the accounting path. The minter does not treat a submitted signature as proof that the intended transfer happened. It uses the finalized transaction’s execution data to reconcile what actually arrived before minting an ICP-side token backed by SOL.

The change also addresses a subtle Solana failure mode. A deposit address cannot simply be drained below the minimum balance needed to remain on-chain. The ckSOL design therefore leaves the rent-exemption amount behind and uses the sweep fee model to calculate what can safely move. Solana’s documentation describes this minimum balance as a refundable storage requirement tied to account size.

The repository’s error handling is equally notable. Open PR #218 proposes dropping deposits from failed or expired sweeps so they can be queued again, while quarantining finalized sweeps whose metadata contradicts the minter’s model. In that case, nothing is minted and the deposit requires manual intervention. This is a deliberate preference for a visible operational exception over silent accounting.

There is also a key security correction in merged PR #227: the minter’s main Solana address is separated from user-derived deposit addresses. The change prevents the treasury address from being mistaken for a user deposit account and avoids a self-sweep that could double-count funds.

For Chain Fusion developers, the lesson is practical. Cross-chain minting should be treated as a reconciliation problem, not merely a signing problem. The remote chain’s finalized state, fee behavior, rent rules, and address-derivation scheme all belong inside the canister’s accounting contract.

At verification time, these are repository developments rather than a production launch: PR #218 remains open, PR #221 remains a draft, and the repository states that the production minter and ledger are not yet deployed. The direction is nevertheless clear: ckSOL is making the Solana transaction itself the evidence required before ICP credits value.