# Transactions

### Transaction Overview

On the 1Money Network, **transactions** are the core mechanism for moving value and interacting with the protocol. Every payment, mint, burn, account cancellation, and recovery operation is handled as a transaction—processed individually, instantly, and securely through the network’s innovative consensus design.

### Payment Transaction Lifecycle

1. **Sign:**\
   The sender creates and cryptographically signs a payment message, specifying the recipient(s), amount(s), and incrementing their account nonce for uniqueness.
2. **Broadcast:**\
   The signed payment is either submitted directly to all validators or relayed via wallets or special relayer services, ensuring wide and reliable message delivery.
3. **Validator Check:**\
   Each validator independently verifies that:

   * The payment message is correctly formatted.
   * The nonce is correct (one higher than the previous).
   * The sender’s account has sufficient balance (including the projected transaction fee).

   Validators only accept and sign the payment if it is valid and no other pending transaction with the same nonce exists.
4. **Certification (Finality):**\
   Once a quorum (majority) of validator signatures is collected, the sender or relayer aggregates them into a **payment certificate**. This certificate serves as an irrefutable proof of consensus—the transaction is now *final* and cannot be reverted.
5. **Acceptance:**\
   Validators update their state to reflect the effects of the transaction (such as adjusting balances and nonces), and remove any previously “pending” versions of the message.

### Specialized Transaction Types

* **Mint & Burn:**\
  Creating (minting) or destroying (burning) tokens uses the same transaction flow, with protocol rules ensuring only the special “mint wallet” can issue or burn assets. These transactions incur no fees and are always valid (the mint wallet is never limited by balance).
* **Pause:**\
  Issuers can also due to extenuating circumstances, pause operations on their token. This immediately freezes all activity on the token, until the token is upaused. 
* **Cancellations:**\
  If a payment has not yet reached quorum or the sender wants to revoke a pending transaction, they can initiate a cancellation message. Cancellations supersede pending payments with the same nonce, and typically incur a slightly higher fee due to their additional network traffic.
* **Recovery:**\
  In cases of conflicting transactions (e.g., double-spending attempts resulting in account locks), a recovery transaction can be submitted. This proves, with evidence, that no payment can reach quorum for the given nonce, allowing the account state to advance and resume normal operation. Recovery fees reflect their extra operational cost.

### Instant Finality and Fair, Simple Fees

* Transactions achieve **instant finality**: once a payment certificate is formed, it is globally accepted, with no blocks or confirmation delays.
* **Fees** are always collected in the token being transferred—no separate “gas token” is needed. The sender pays the fee, except in rare cases (e.g., specialized fee delegation), making payment flows simple and predictable. Enterprises and Issuers have the option to zero out fees for their Users and pre-pay fees (to be covered in detail in the Fee section). 

### Why This Matters

This transaction model delivers a user experience more like traditional digital payments than legacy blockchains: **fast, final, secure, and easy to use**. Developers and users can rely on transactions processing in real time, with clear outcomes and no guesswork about network fees or confirmation waiting periods.

<br>


---

# 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://developer.1moneynetwork.com/introduction/what-is-1money-network/transactions.md?ask=<question>
```

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.