Enable Recovery of Native SOL from Mint Accounts with Private Key Access

[anunknowngithubuser]

Problem Statement

When a user's address (for which they hold the private key) is initialized as a Mint account and the mint authority is later discarded, users can inadvertently transfer native SOL to this address. Since this address belongs to the user, it's easy to mistakenly send SOL to it, resulting in lost funds that cannot be recovered through standard methods.
Furthermore, this vulnerability can be exploited in phishing attacks where users are tricked into signing transactions that convert their addresses into Mint accounts with the attacker holding the mint authority. In such cases, users lose access to any native SOL in those accounts.

This is a common issue that occurs when:
Users reuse addresses for different purposes
Users interact with UI/dApps that don't properly warn about these limitations
Users don't fully understand the implications of initializing an address as a Mint

Proposed Solution

I propose implementing a recovery mechanism that allows the private key holder of a Mint address to rescue any native SOL exceeding the rent exemption amount:
Add a new instruction to the Token Program that enables the signer of a Mint account (the holder of the private key) to transfer excess SOL from the Mint account to their wrapped SOL Associated Token Account (ATA)

This operation would:
Maintain the minimum rent exemption amount in the Mint account
Only transfer the excess SOL to the signer's wrapped SOL ATA
Require a valid signature from the private key holder of the Mint address
Not modify any other properties or data of the Mint account

This approach preserves the security model of the Token Program while providing a practical recovery path for users who have mistakenly lost access to their SOL. Since the funds are transferred to wrapped SOL in the user's own ATA, they maintain full control over these recovered assets.

Implementation Considerations
This solution is similar to the RecoverLamports instruction proposed in PR #2741 but specifically addresses the Mint account use case. It respects the authority principle since only the original address owner (with the private key) can initiate the recovery.

[anunknowngithubuser]

I can submit a specific implementation. I would like to know if the community would support this PR.

[metasal1]

Sounds like a useful solution

[buffalojoec]

Some of the work you mention later in the description (like PR 4094) led to this feature being supported in Token-2022.
https://github.com/solana-program/token-2022/blob/d073cb89dbcd430387b5c6fb4b7157911351e4a3/program/src/instruction.rs#L696-L704

WithdrawExcessLamports lets you withdraw excess lamports from a token account if you're the owner, a mint account if you're the mint authority and a multisig account if fully authorized. However, it does not support withdrawals on mints with no mint authority.
https://github.com/solana-program/token-2022/blob/d073cb89dbcd430387b5c6fb4b7157911351e4a3/program/src/processor.rs#L1591

We are actually lobbying for this same instruction to land in the legacy SPL-Token program as part of the program's in-place upgrade to a more efficient version.
solana-foundation/solana-improvement-documents#266

The main concern I have here is the support for mints with no mint authority. It looks like that was intentionally left out in the Token-2022 implementation. I'm assuming it's mostly because the common workflow for apps that create tokens is to generate a keypair then immediately throw it away, and this would place the onus on them to figure out a way to keep it around, otherwise they'd be intentionally burning the only means to recover lamports in such a case. Do you have some more context on that bit @joncinque?

[anunknowngithubuser]

Once the owner of an address with an on-curve private key (isOnCurve) is modified, they immediately lose all control over the native SOL held within that address. However, that signer retains the ability to sign operations involving ATA addresses, including those holding wrapped SOL (wSOL). At this stage, the native SOL's sole function becomes paying rent (though specific business needs might require controlling it).

Therefore, I believe that any SOL beyond what's required for rent should, in the absence of explicit agreements otherwise, remain under the control of the mint address's original signer. Consequently, providing such an instruction within the token program is entirely reasonable. Furthermore, unless a program has very specific business requirements, most programs that convert isOnCurve addresses into PDAs should offer a similar mechanism. As highlighted in solana-foundation/solana-improvement-documents#266 (comment), this situation leads to a considerable amount of native SOL being unnecessarily frozen.

[joncinque]

Do you have some more context on that bit @joncinque?

For who should own the SOL on a mint account, it didn't go much further than, "Uh, I guess the mint authority?" so we can certainly refine it. We went with the mint authority because it should be a key that's still actively maintained, and most likely not thrown away, otherwise the user would have just removed the authority entirely.

The problem comes with people who might have exposed their mint private key publicly, because the protocol explicitly didn't allow for anything to be done with that key afterwards.

My recommendation would be to allow for the mint signer to withdraw the excess lamports only if there's no mint authority. What do you think?

[joncinque]

cc @febo

[buffalojoec]

My recommendation would be to allow for the mint signer to withdraw the excess lamports only if there's no mint authority. What do you think?

Yep, makes sense to me!

[febo]

My recommendation would be to allow for the mint signer to withdraw the excess lamports only if there's no mint authority. What do you think?

Agree, this makes sense.