# Cómo funcionan las transacciones
### Introducción
Las transacciones son la unidad fundamental de ejecución en Stacks. Cada transacción se origina desde una cuenta de Stacks y se conserva en la historia de la red Stacks para la eternidad. Esta guía te ayuda a entender las transacciones de Stacks.
### Ciclo de vida
Las transacciones pasan por fases antes de ser finalmente confirmadas.
{% stepper %}
{% step %}
**Generar**
Las transacciones se ensamblan según la especificación de codificación.
{% endstep %}
{% step %}
**Validar y firmar**
Las transacciones se validan para confirmar que tienen una estructura correcta. Las firmas requeridas se completan.
{% endstep %}
{% step %}
**Difundir**
Las transacciones se envían a un nodo.
{% endstep %}
{% step %}
**Registrar**
Un minero recibe transacciones, las verifica y las añade al mempool, un área de retención para todas las transacciones pendientes.
{% endstep %}
{% step %}
**Procesar**
Los mineros revisan el mempool y seleccionan transacciones para el siguiente bloque que se va a minar. Dependiendo del tipo de transacción, pueden ocurrir distintas acciones durante este paso. Por ejemplo, se podrían verificar las postcondiciones de una transferencia de tokens, acuñar tokens definidos por un contrato inteligente, o intentar llamar a un método de un contrato inteligente existente.
{% endstep %}
{% step %}
**Confirmar**
Los mineros proponen con éxito bloques con un conjunto de transacciones. Las transacciones contenidas se propagan correctamente a la red cuando los stackers las aprueban.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Una transacción puede tener uno de tres estados una vez que se registra: `pendiente`, `éxito`, o `fallida`.
{% endhint %}
### Tipos
Stacks admite un conjunto de diferentes tipos de transacciones:
| **Tipo** | **Valor** | **Descripción** |
| ------------------------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cambio de tenure | `TenureChange` | Un cambio de tenure es un evento en la cadena de bloques de Stacks existente cuando un minero asume la responsabilidad de crear nuevos bloques de Stacks desde otro minero. Un cambio de tenure ocurre cuando se descubre un bloque de Stacks a partir de una sortición criptográfica. Realizado por stackers. |
| Bloque de cambio de tenure encontrado | `TenureChange-BlockFound` | A `TenureChange-BlockFound` la transacción es inducida por una sortición ganadora. Esto hace que el nuevo minero empiece a producir bloques y detiene al minero actual de producir más bloques. |
| Extensión de cambio de tenure | `TenureChange-Extend` | A `TenureChange-Extend`, que es inducida por los Stackers, reinicia el presupuesto de ejecución en curso del tenure actual, permitiendo así que el minero continúe produciendo bloques. |
| Transferencia de tokens | `token_transfer` | Transferencia de activos de un remitente a un destinatario |
| Despliegue de contrato | `smart_contract` | Instanciación del contrato |
| Llamada al contrato | `contract_call` | Llamada al contrato para una función pública que no es de solo lectura |
## Comisiones
Las comisiones se utilizan para incentivar a los mineros a confirmar transacciones en la cadena de bloques de Stacks. La comisión se calcula en función de la tarifa de comisión estimada y del tamaño de la transacción en bruto en bytes. La tarifa de comisión es una variable determinada por el mercado. Para la testnet, se establece en 1 micro-STX.
## Nonces
Cada cuenta tiene una [propiedad nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) que indica el número de transacciones procesadas para la cuenta dada. Los nonces son códigos de un solo uso, que comienzan en `0` para las cuentas nuevas y se incrementan en 1 en cada transacción.
Los nonces se añaden a todas las transacciones y ayudan a identificarlas en orden para garantizar que las transacciones se procesen en secuencia y evitar el procesamiento duplicado.
{% hint style="info" %}
El mecanismo de consenso también garantiza que las transacciones no se "reproduzcan" de dos maneras. Primero, los nodos consultan sus salidas de transacciones no gastadas (UTXOs) para satisfacer sus condiciones de gasto en una nueva transacción. Segundo, los mensajes enviados entre nodos revisan los números de secuencia.
{% endhint %}
Cuando se construye una nueva transacción de transferencia de tokens, se necesita obtener y establecer el nonce más reciente de la cuenta.
### Cómo se detectan y resuelven los huecos de nonce
Las transacciones de Stacks deben ejecutarse **estrictamente en orden de nonce**. Cuando se envía una transacción con un nonce superior al esperado, la red **no** la rechaza de inmediato; en su lugar, rastrea el hueco y espera a que lleguen los nonces que faltan.
A continuación se muestra un recorrido conceptual, con respuestas visuales de la API, de cómo se comporta el sistema cuando los nonces se envían fuera de orden.
{% stepper %}
{% step %}
**Estado inicial (sin transacciones pendientes)**
```json
{
last_mempool_tx_nonce: null,
last_executed_tx_nonce: 241,
possible_next_nonce: 242,
detected_missing_nonces: [],
detected_mempool_nonces: []
}
```
**Interpretación**
* Todas las transacciones hasta el nonce `241` se han ejecutado
* La red espera el nonce `242` siguiente
* No hay transacciones esperando actualmente en el mempool
* No existen huecos de nonce
{% endstep %}
{% step %}
**Envío de un nonce futuro (`245`)**
```json
{
last_mempool_tx_nonce: 245,
last_executed_tx_nonce: 241,
possible_next_nonce: 246,
detected_missing_nonces: [244, 243, 242],
detected_mempool_nonces: []
}
```
**Interpretación**
* Una transacción con nonce `245` ahora está en el mempool
* Nonces `242`, `243`, y `244` faltan
* La ejecución no puede continuar hasta que se envíen esos nonces
* `possible_next_nonce` refleja el nonce más alto observado + 1
{% endstep %}
{% step %}
**Envío de un hueco parcial (`243`)**
```json
{
last_mempool_tx_nonce: 245,
last_executed_tx_nonce: 241,
possible_next_nonce: 246,
detected_missing_nonces: [244, 242],
detected_mempool_nonces: [243]
}
```
**Interpretación**
* Nonce `243` ahora está presente en el mempool
* Nonces `242` y `244` siguen faltando
* La ejecución sigue bloqueada
* La API distingue entre:
* `detected_mempool_nonces` → presentes pero no ejecutados
* `detected_missing_nonces` → requeridos pero aún no vistos
{% endstep %}
{% step %}
**Rellenando más huecos (`244`)**
```json
{
last_mempool_tx_nonce: 245,
last_executed_tx_nonce: 241,
possible_next_nonce: 246,
detected_missing_nonces: [242],
detected_mempool_nonces: [243, 244]
}
```
**Interpretación**
* Nonces `243` y `244` están ambos esperando en el mempool
* Nonce `242` sigue faltando
* La ejecución permanece en pausa en `241`
{% endstep %}
{% step %}
**Todos los nonces requeridos presentes (`242`)**
```json
{
last_mempool_tx_nonce: 245,
last_executed_tx_nonce: 241,
possible_next_nonce: 246,
detected_missing_nonces: [],
detected_mempool_nonces: [242, 243, 244]
}
```
**Interpretación**
* Todos los nonces requeridos (`242–245`) ya están disponibles
* No quedan huecos
* La red puede ejecutar transacciones secuencialmente
{% endstep %}
{% step %}
**Después de que la ejecución se completa**
```json
{
last_mempool_tx_nonce: null,
last_executed_tx_nonce: 245,
possible_next_nonce: 246,
detected_missing_nonces: [],
detected_mempool_nonces: []
}
```
**Interpretación**
* Todas las transacciones pendientes se han ejecutado
* El nonce de la cuenta ha avanzado a `245`
* El siguiente nonce válido ahora es `246`
* El estado del mempool vuelve a estar limpio
{% endstep %}
{% endstepper %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.stacks.co/learn/es/transactions/how-transactions-work.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.