SIMD-0312: Solana crea en una sola instrucción cuentas con saldo previo
La instrucción CreateAccountAllowPrefund crea la cuenta aunque la dirección ya tenga lamports. La feature lleva activa en mainnet desde el 29 de mayo de 2026.
Solana activó el 29 de mayo de 2026 la feature create_account_allow_prefund, que añade al programa de sistema la instrucción CreateAccountAllowPrefund. Su función: crear una cuenta aunque la dirección de destino ya tenga lamports. Hasta ahora eso fallaba y obligaba a un rodeo de tres instrucciones que la mayoría de programas no implementaba. El cambio llega vía SIMD-0312.
Qué fallaba antes
CreateAccount hace tres cosas de golpe: reserva espacio, asigna un programa propietario y transfiere los lamports iniciales desde quien financia. Exige una precondición estricta: que el destino esté vacío, con cero lamports, cero datos y propietario system. Si alguien mandó SOL antes de tiempo, la comprobación falla y la instrucción devuelve error, porque no se puede crear algo que ya tiene saldo.
Esa precondición tiene sentido: impide que una parte precargue una cuenta que otra espera inicializar. El problema es que el acto humano de enviar dinero un poco antes deja el camino de creación roto. El apaño consistía en encadenar Allocate, Assign y Transfer, y exigía que el programa creador previera el caso. Casi ninguno lo hacía.
La instrucción nueva hace lo obvio: si la dirección ya está financiada, ese saldo cuenta para la cantidad solicitada y quien financia solo aporta la diferencia, si la hay.
Detalles que importan si vas a integrarla
Dos cosas de la implementación conviene tener delante. La primera: el orden de las cuentas se invierte respecto a CreateAccount, con la cuenta nueva en el índice 0 y quien financia en el 1. Un par de cuentas traspuesto compila, pasa el test de camino feliz y revienta con la primera dirección con saldo previo en producción. La segunda: si los lamports solicitados son 0, solo hace falta una cuenta, el propio destino, porque no hay nada que transferir.
La feature quedó activa en mainnet el 29 de mayo de 2026, época 979, slot 422.928.004.
A quién arregla el problema y a quién no
Es una herramienta para programas y wallets, no un botón que pulse el usuario. Los sistemas de depósito, exchanges, procesadores de pago, cualquiera que reparta direcciones antes de crear la cuenta, pueden crearla después de que llegue el dinero con una sola instrucción, sin camino especial. Las direcciones derivadas de programa (bóvedas, escrows, cuentas de estado por usuario) admiten financiación previa y su init puede salir bien igualmente.
Quien tiene SOL parado en una dirección sin crear sigue dependiendo de quien controle esa ruta. La diferencia es que el arreglo de su lado ahora es trivial.
También cambia un invariante: la garantía de cuenta fresca se debilita. Un programa que use CreateAccountAllowPrefund tiene que tolerar un saldo previo y no asumir que los lamports que ve los puso su financiador. Si su lógica depende del saldo inicial exacto, mejor leer el saldo después de crear y no la cantidad pedida. CreateAccount mantiene su comportamiento estricto para quien lo prefiera.
Y no hace tres cosas: no recupera SOL enviado a una dirección equivocada, no toca las cuentas de token (las asociadas ya toleran el prefinanciado desde hace tiempo) y no se dispara sola. Si el programa no la usa, la dirección con saldo previo sigue igual de atascada que antes.
