# Transactions Each submitted transaction includes the standard fields required for validation, including (at minimum) the sender address, recipient address (or contract identifier), nonce or sequence value (if applicable), payload, fee parameters, and a cryptographic signature authorizing the action.
After execution, the network may emit associated execution metadata (for example, a transaction receipt), which can include fields such as confirmation status, execution result codes, resource usage, and any applicable fee breakdown. This metadata is recorded separately from the signed transaction payload.
### Broadcasting Fees The node or gateway that accepts and relays a transaction for inclusion may earn a broadcasting fee, subject to network policy. Different transaction types may be handled with different priority classes (for example, value transfers versus contract calls), depending on the network’s congestion-control rules. ### Priority Fees Users may optionally specify an additional priority fee intended to increase a transaction’s relative ordering in the pending transaction pool. Actual execution time remains dependent on network conditions and validator policy. ### ZK Proof-Backed Privacy Zero-knowledge proofs can be used to allow a party to prove specific statements about data or computation without revealing the underlying data itself. For example, a transaction can include a proof that a rule was satisfied (or that certain inputs were valid) while keeping sensitive fields private, subject to the protocol’s verification rules. ### Wallet addressing and human-readable names Wallets can be represented by canonical cryptographic addresses (for example, a hash-derived address from a public key). Optionally, a human-readable name can be mapped to a canonical address through a name-resolution system (for example, a name like myname.crc resolving to a standard address at execution time). Names may also be mapped to smart contracts, allowing users to refer to contracts by a stable identifier rather than a raw address. --- # 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://circular-protocol.gitbook.io/whitepaper/circular-protocol-architecture/transactions.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.