Modelo de Programación

Nonce Account

A special account managed by the System Program that stores a durable nonce value, enabling transactions with extended or indefinite lifetimes. Normally, transactions reference a recent blockhash and expire after ~60-90 seconds. Nonce accounts replace the blockhash with a stored nonce that remains valid until explicitly advanced, enabling offline signing workflows, scheduled transactions, and custodial operations where signing and submission happen at different times.

IDnonce-account

Lectura rápida

Empieza por la explicación más corta y útil antes de profundizar.

A special account managed by the System Program that stores a durable nonce value, enabling transactions with extended or indefinite lifetimes. Normally, transactions reference a recent blockhash and expire after ~60-90 seconds. Nonce accounts replace the blockhash with a stored nonce that remains valid until explicitly advanced, enabling offline signing workflows, scheduled transactions, and custodial operations where signing and submission happen at different times.

Modelo mental

Usa primero la analogía corta para razonar mejor sobre el término cuando aparezca en código, docs o prompts.

Piensa en esto como una de las piezas centrales que tu programa lee, escribe o invoca durante la ejecución.

Contexto técnico

Ubica el término dentro de la capa de Solana en la que vive para razonar mejor sobre él.

Accounts, instrucciones, PDAs, transacciones y flujo de ejecución.

Por qué le importa a un builder

Convierte el término de vocabulario en algo operacional para producto e ingeniería.

Este término desbloquea conceptos adyacentes rápido, así que funciona mejor cuando lo tratas como un punto de conexión y no como una definición aislada.

Handoff para IA

Handoff para IA

Usa este bloque compacto cuando quieras dar contexto sólido a un agente o asistente sin volcar toda la página.

Nonce Account (nonce-account)
Categoría: Modelo de Programación
Definición: A special account managed by the System Program that stores a durable nonce value, enabling transactions with extended or indefinite lifetimes. Normally, transactions reference a recent blockhash and expire after ~60-90 seconds. Nonce accounts replace the blockhash with a stored nonce that remains valid until explicitly advanced, enabling offline signing workflows, scheduled transactions, and custodial operations where signing and submission happen at different times.
Relacionados: Durable Nonce, Programa del Sistema, Blockhash (Recent)
Glossary Copilot

Haz preguntas de Solana con contexto aterrizado sin salir del glosario.

Usa contexto del glosario, relaciones entre términos, modelos mentales y builder paths para recibir respuestas estructuradas en vez de output genérico.

Abrir workspace completa del Copilot
Explicar este código

Opcional: pega código Anchor, Solana o Rust para que el Copilot mapee primitivas de vuelta al glosario.

Haz una pregunta aterrizada en el glosario

Haz una pregunta aterrizada en el glosario

El Copilot responderá usando el término actual, conceptos relacionados, modelos mentales y el grafo alrededor del glosario.

Grafo conceptual

Ve el término como parte de una red, no como una definición aislada.

Estas ramas muestran qué conceptos toca este término directamente y qué existe una capa más allá de ellos.

Rama

Durable Nonce

A mechanism that replaces the short-lived recent blockhash in a transaction with a nonce value stored in a dedicated on-chain nonce account, allowing the transaction to remain valid indefinitely until it is used or the nonce is advanced. The nonce account stores the current nonce hash and an authority; the first instruction of any durable-nonce transaction must be AdvanceNonceAccount, which updates the nonce and invalidates the old one. Durable nonces are essential for workflows requiring offline signing, hardware security modules, or multi-party approval over extended time periods.

Rama

Programa del Sistema

The built-in native program (address: 11111111111111111111111111111111) responsible for creating new accounts, transferring SOL between accounts, allocating account data space, and assigning account ownership to programs. It is the only program that can create new accounts and is invoked in nearly every transaction.

Rama

Blockhash (Recent)

A 32-byte hash derived from the bank's state at a given slot, included in every Solana transaction to prove the transaction was created recently and to prevent replay attacks. A blockhash remains valid for approximately 150 slots (~60–90 seconds at normal slot times); transactions submitted with an expired blockhash are rejected outright. Clients must fetch a fresh blockhash before signing and ideally reuse it for as short a window as possible to maximize landing probability.

Siguientes conceptos para explorar

Mantén la cadena de aprendizaje en movimiento en lugar de parar en una sola definición.

Estos son los siguientes conceptos que vale la pena abrir si quieres que este término tenga más sentido dentro de un workflow real de Solana.

Red

Durable Nonce

A mechanism that replaces the short-lived recent blockhash in a transaction with a nonce value stored in a dedicated on-chain nonce account, allowing the transaction to remain valid indefinitely until it is used or the nonce is advanced. The nonce account stores the current nonce hash and an authority; the first instruction of any durable-nonce transaction must be AdvanceNonceAccount, which updates the nonce and invalidates the old one. Durable nonces are essential for workflows requiring offline signing, hardware security modules, or multi-party approval over extended time periods.

Modelo de Programación

Programa del Sistema

The built-in native program (address: 11111111111111111111111111111111) responsible for creating new accounts, transferring SOL between accounts, allocating account data space, and assigning account ownership to programs. It is the only program that can create new accounts and is invoked in nearly every transaction.

Red

Blockhash (Recent)

A 32-byte hash derived from the bank's state at a given slot, included in every Solana transaction to prove the transaction was created recently and to prevent replay attacks. A blockhash remains valid for approximately 150 slots (~60–90 seconds at normal slot times); transactions submitted with an expired blockhash are rejected outright. Clients must fetch a fresh blockhash before signing and ideally reuse it for as short a window as possible to maximize landing probability.

Modelo de Programación

Par de Claves

A pair of a 32-byte Ed25519 private key and its corresponding 32-byte public key. Keypairs are used to sign transactions and derive account addresses. They are stored as 64-byte arrays (private + public concatenated) in JSON files by the Solana CLI. The private key should never be shared or exposed.

Comúnmente confundido con

Términos cercanos en vocabulario, acrónimo o vecindad conceptual.

Estas entradas son fáciles de mezclar cuando lees rápido, haces prompting a un LLM o estás entrando en una nueva capa de Solana.

Modelo de Programaciónaccount-data

Account Data

The byte array stored in an account that holds program-specific state. Data is typically serialized using Borsh and must be explicitly allocated at account creation. The maximum data size is 10MB. Programs are responsible for defining and managing their own data layout, including discriminators for type identification.

Modelo de Programaciónbuffer-account

Buffer Account

A temporary account used during Solana program deployment to hold the program's ELF binary before it is written to the program data account. The deployer creates a buffer account, uploads the compiled SBF binary in chunks via the Upgradeable BPF Loader's Write instruction, and then issues a Deploy or Upgrade instruction that copies the buffer contents to the final program data account. Buffer accounts can be closed after deployment to reclaim rent.

Modelo de Programaciónclose-account

Close Account

The process of reclaiming an account's lamports and marking it for deletion. To close an account: transfer all lamports to a recipient, zero out the data, and (in Anchor) set the discriminator to a closed sentinel. The runtime garbage-collects zero-lamport accounts. Failing to zero data enables revival attacks.

Términos relacionados

Sigue los conceptos que realmente le dan contexto a este término.

Las entradas del glosario se vuelven útiles cuando están conectadas. Estos enlaces son el camino más corto hacia ideas adyacentes.

Reddurable-nonce

Durable Nonce

A mechanism that replaces the short-lived recent blockhash in a transaction with a nonce value stored in a dedicated on-chain nonce account, allowing the transaction to remain valid indefinitely until it is used or the nonce is advanced. The nonce account stores the current nonce hash and an authority; the first instruction of any durable-nonce transaction must be AdvanceNonceAccount, which updates the nonce and invalidates the old one. Durable nonces are essential for workflows requiring offline signing, hardware security modules, or multi-party approval over extended time periods.

Modelo de Programaciónsystem-program

Programa del Sistema

The built-in native program (address: 11111111111111111111111111111111) responsible for creating new accounts, transferring SOL between accounts, allocating account data space, and assigning account ownership to programs. It is the only program that can create new accounts and is invoked in nearly every transaction.

Redblockhash

Blockhash (Recent)

A 32-byte hash derived from the bank's state at a given slot, included in every Solana transaction to prove the transaction was created recently and to prevent replay attacks. A blockhash remains valid for approximately 150 slots (~60–90 seconds at normal slot times); transactions submitted with an expired blockhash are rejected outright. Clients must fetch a fresh blockhash before signing and ideally reuse it for as short a window as possible to maximize landing probability.

Más en la categoría

Quédate en la misma capa y sigue construyendo contexto.

Estas entradas viven junto al término actual y ayudan a que la página se sienta parte de un grafo de conocimiento más amplio en lugar de un callejón sin salida.

Modelo de Programación

Cuenta

The fundamental data storage unit on Solana. Every piece of state is stored in an account identified by a 32-byte public key. Accounts hold a lamport balance, an owner program, a data byte array (up to 10MB), and an executable flag. Only the owning program can modify an account's data, but anyone can credit lamports to it.

Modelo de Programación

Programa

Executable code deployed on-chain, equivalent to a smart contract on other blockchains. Programs are stateless—they store no data themselves but read/write data in separate accounts they own. Programs are compiled to SBF bytecode and loaded via the BPF Loader. Every program has a unique Program ID (its account's public key).

Modelo de Programación

Instrucción

A single operation within a transaction that invokes a program. An instruction specifies: (1) the program ID to call, (2) an array of account metas (pubkey, is_signer, is_writable), and (3) an opaque data byte array. Programs decode the instruction data to determine which operation to perform.

Modelo de Programación

Transacción

An atomic unit of execution containing one or more instructions, a recent blockhash, and one or more signatures. All instructions in a transaction execute sequentially and atomically—if any instruction fails, the entire transaction reverts. Transactions have a 1,232-byte size limit (matching IPv6 MTU) and a default 200,000 CU budget.