ckSOL renames withdrawal endpoints to withdraw_sol before launch

DFINITY engineer Gregory Demay opened a ckSOL design thread on the Internet Computer forum on October 9, 2026. The thread names the minter's public API as deposit_sol and withdraw_sol, following PR #262, which merged on October 8. If you test against the ckDevnetSOL staging deployment, update your endpoint names now, before the production minter on Solana mainnet goes live.

This follows our October 5 article on the new ckSOL deposit pipeline. Since then, the team has described the full user flow in one place and renamed the withdrawal and status endpoints. It also said it is "now about to launch the production version".

What changed in ckSOL

ckSOL is a chain-key token that represents SOL on the Internet Computer. According to the thread, a canister smart contract holds all SOL that backs ckSOL using "threshold Schnorr over Ed25519". The matching private key is never derived. The token follows the "ICRC-1, ICRC-2, and ICRC-3" standards.

The system has two parts:

• ckSOL Ledger: a standard ICRC ledger canister.
• ckSOL Minter: converts between SOL and ckSOL and holds all backing SOL. It reaches Solana through the SOL RPC canister. That canister sends each query to several independent JSON-RPC providers and only accepts an answer they agree on.

The thread says the design "closely follows ckETH". Two design points matter most for integrators:

1. The minter credits deposits from address balances, not from single transfers. Each ICP account (principal plus subaccount) gets its own Solana deposit address. After sending SOL, the user calls deposit_sol. The minter moves the full balance of that address into its main account (a sweep). When the sweep is finalized, it mints ckSOL for the amount the sweep actually moved. You don't need a Solana transaction signature, so deposits from centralized exchanges work. If several transfers are each too small on their own, the minter credits them together once their total is large enough. Automatic deposit discovery, where the user does not call anything, will come in a later upgrade after launch.
2. Withdrawals never expire. The user gives the minter an ICRC-2 approval and calls withdraw_sol with a destination address and amount. The minter burns the ckSOL and sends the same amount of SOL, minus a withdrawal fee. Withdrawals are sent as "durable-nonce transactions". With a durable nonce, the minter can check on-chain whether a transaction landed. It does not have to guess from a missing status in an RPC provider's response.

PR #262 in dfinity/cksol is titled "refactor(minter)!: name the withdrawal and status endpoints after the asset". It merged on October 8. The ! in the title marks a breaking change. The PR renames:

deposit_sol already had this name and did not change. The PR renames the other Candid types the same way: WithdrawalOk, WithdrawalError and WithdrawalStatus become WithdrawSolOk, WithdrawSolError and WithdrawSolStatus.

Who is affected

• Wallet and dapp developers who wrote against older staging builds. Calls to withdraw, deposit_status or withdrawal_status will fail against a minter built after PR #262.
• Teams that used a transaction signature for deposits. Earlier README examples showed a process_deposit call that took a Solana signature. The flow in the thread uses deposit_sol and reads the balance of the deposit address instead. Check the current Candid file before you port old code.
• Exchanges and custodians. Each account has its own deposit address, so no memo field is needed. The team gives this as the reason for the design.

The repository README lists these canister IDs:

On October 9, NNS proposals 144313 and 144314 upgraded lh22c-kyaaa-aaaar-qb5nq-cai and ls5lp-lqaaa-aaaar-qb5oa-cai to new wasm hashes. The forum post still says production is about to launch. Treat mainnet ckSOL as closed to users until the team announces the launch.

In the same thread, a community member asked whether ckSOL could be removed if few people use it. The NNS has already agreed to wind down ckDOGE for that reason. The original poster replied with a link explaining why the team expects ckSOL to be useful, and the community member said this answered the concern. The thread contains no usage commitment or policy.

What to do now

1. Search your code for calls to withdraw, deposit_status and withdrawal_status on the ckSOL minter. Rename them to withdraw_sol, deposit_sol_status and withdraw_sol_status.
2. Regenerate your Candid bindings from the minter interface in dfinity/cksol so that type names such as WithdrawSolArgs match.
3. If you have a deposit flow based on transaction signatures, replace it with these steps: get the deposit address, send SOL, call deposit_sol, then poll deposit_sol_status.
4. For withdrawals, call icrc2_approve on the ckSOL ledger to approve the minter before you call withdraw_sol.
5. Test on ckDevnetSOL first. The repository README uses icp-cli, with -e staging or -e prod to choose the environment. The two read calls below come from the README. PR #262 did not rename these endpoints:

# Fees, minimum amounts and minter balance
icp canister call -e staging cksol_minter get_minter_info '()'

# Your Solana deposit address (owner = null uses your calling principal)
icp canister call -e staging cksol_minter get_deposit_address \
  '(record { owner = null; subaccount = null })' --query

6. Read fees and minimum amounts from get_minter_info instead of hardcoding them. The thread says the design document explains the fee model and parameter choices.

Caveats

The team has announced the production deployment, but it is not live yet. PR #262 is a breaking API change. A review comment on that PR pointed out that a README withdrawal example still used the old withdraw name, so trust the Candid file over older docs. Automatic deposit detection is not part of the first release.