Transactions on the CROSS Network

A transaction on the CROSS network is a cryptographically signed instruction from an account that updates the state of the blockchain. The most basic transaction involves transferring CROSS Coin from one account to another.

Prerequisites

To better understand this topic, it is recommended to first review the concepts of Accounts and the CROSS Network basics.

What is a Transaction?

A transaction on CROSS is an operation initiated by an Externally Owned Account (EOA)—a user-controlled account, not a contract. For example, if Bob sends 10 CROSS Coins to Alice:

• Bob's account is debited
• Alice's account is credited

This state change is encapsulated in a transaction.

Transactions that modify EVM state must propagate across the network. Validators execute and confirm the transaction, broadcasting the resulting state changes to all nodes.

Each transaction requires a fee (gas) and must be included in a valid block.

The table below summarizes the data fields included in a submitted transaction:

Gas refers to the computational effort needed to process the transaction. Users must pay a fee based on gasLimit × (baseFee + maxPriorityFeePerGas).

Example: Transaction Object

{
  "from": "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  "to": "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  "gasLimit": "21000",
  "maxFeePerGas": "300",
  "maxPriorityFeePerGas": "10",
  "nonce": "0",
  "value": "10000000000"
}

Signing a Transaction

A transaction must be signed using the sender’s private key.

Here is an example JSON-RPC call to sign a transaction:

{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "account_signTransaction",
  "params": [
    {
      "from": "0xd1a9C60791e8440AEd92019a2C3f6c336ffefA27",
      "to": "0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192",
      "gas": "0x33333",
      "maxPriorityFeePerGas": "0x174876E800",
      "maxFeePerGas": "0x174876E800",
      "nonce": "0x0",
      "value": "0x10",
      "data": "0x4401a6e40000000000000000000000000000000000000000000000000000000000000012"
    }
  ]
}

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "raw": "0x02f891018085174876e80085174876e80083033333948a8eafb1cf62bfbeb1741769dae1a9dd4799619210a44401a6e40000000000000000000000000000000000000000000000000000000000000012c080a0c8b59180c6e0c154284402b52d772f1afcf8ec2d245cf75bfb3212ebe676135ba02c660aaebf92d5e314fc2ba4c70f018915d174c3c1fc6e4e38d00ebf1a5bb69f",
    "tx": {
      "type": "0x2",
      "nonce": "0x0",
      "gasPrice": null,
      "maxPriorityFeePerGas": "0x174876e800",
      "maxFeePerGas": "0x174876e800",
      "gas": "0x33333",
      "value": "0x10",
      "input": "0x4401a6e40000000000000000000000000000000000000000000000000000000000000012",
      "v": "0x0",
      "r": "0xc8b59180c6e0c154284402b52d772f1afcf8ec2d245cf75bfb3212ebe676135b",
      "s": "0x2c660aaebf92d5e314fc2ba4c70f018915d174c3c1fc6e4e38d00ebf1a5bb69f",
      "to": "0x8a8eafb1cf62bfbeb1741769dae1a9dd47996192",
      "chainId": "0x956D7",
      "accessList": [],
      "hash": "0x8e096eb11ea89aa83900e6816fb182ff0adb2c85d270998ca2dd2394ec6c5a73"
    }
  }
}

Transaction Use Cases Based on to Field

1. to is an EOA (Externally Owned Account)

This case represents a basic transfer between user-controlled addresses. It is primarily used for straightforward token transfers such as sending CROSS Coins.

• The data field is generally empty but may optionally contain arbitrary data (e.g., a message).
• Since EOAs do not have associated contract code, no computation or code execution occurs.
• Minimal or no gas is consumed by the data field.
• Main use case: transferring tokens or embedding a message with no execution logic.

2. to is a Contract Address

This triggers a function call to a smart contract deployed on the network.

• The data field must comply with the Application Binary Interface (ABI):
  • The first 4 bytes are the function selector, derived from the function signature.
  • The remaining bytes are ABI-encoded parameters for the function.
• The contract logic is executed during the transaction, potentially modifying the contract's state.
• Gas is consumed based on the complexity of the contract execution.

3. to is null (Contract Creation)

When the to field is omitted or explicitly set to null, the transaction is interpreted as a request to deploy a new smart contract.

• The data field must contain the contract bytecode, also referred to as initcode.
• The network recognizes the transaction as a contract creation operation and executes the initcode.
• A new contract address is deterministically generated based on the sender’s address and their nonce.
• The result of executing the initcode becomes the deployed contract's code and is permanently stored on-chain.
• Gas is consumed throughout the deployment process, and the total cost depends on the complexity and size of the contract.

Gas Fees on the CROSS Network

Gas is required to execute a transaction. A simple transfer requires 21,000 units of gas.

For example, If Bob sends 10 CROSS Coins with:

• baseFeePerGas = 100 gwei
• maxPriorityFeePerGas = 5 gwei

Then:

(100 + 5) × 21000 = 2,205,000 gwei

As a result, the following occurs:

• Bob's account is debited by -10.002205 CROSS Coin
• Alice's account is credited with +10 CROSS Coin
• The validator receives the tip and base fee (In Ethereum, the entire base fee is burned and only the tip goes to the validator)

Transaction Lifecycle

After a transaction is submitted, it follows these steps:

1. A cryptographic transaction hash is generated.
2. The transaction is propagated through the network and added to the pending transaction pool.
3. A validator selects the transaction, includes it in a block, and performs validation.
4. Over time, the block containing the transaction is upgraded from "justified" to "finalized."

Typed Transaction Envelopes

CROSS supports multiple transaction formats, allowing protocol upgrades without breaking compatibility with existing formats.

Transactions follow this structure:

TransactionType || TransactionPayload

Where:

• TransactionType: Identifies the type (e.g., 0x0 to 0x7)
• TransactionPayload: The data corresponding to the transaction logic

Supported Transaction Types

Type 0: Legacy Transaction (0x0)

• Original Ethereum format
• No support for EIP-1559 features
• Simple gas price field only (gasPrice)

Type 1: Access List Transaction (0x1)

• Introduced in EIP-2930
• Adds an accessList to pre-declare addresses and storage slots
• Reduces gas for accessing frequently used contracts/state

Type 2: EIP-1559 Dynamic Fee Transaction (0x2)

• Replaces gasPrice with maxFeePerGas and maxPriorityFeePerGas
• Introduces dynamic base fee mechanism for better fee estimation

Type 3: Blob Transaction (0x3)

• Proposed in EIP-4844 (proto-danksharding)
• Includes large binary data blobs
• Optimized for layer-2 and rollup data availability

Type 7: Fee Delegation Dynamic Transaction (0x7)

• CROSS-specific extension
• Builds on Type 2 format
• Allows third party (e.g., game or DApp) to cover gas costs
• Adds an extra signature from the fee payer
• Enables seamless onboarding and gasless UX

CROSS may support additional future transaction types beyond these as the protocol evolves.

The CROSS network is fully compatible with standard EVM behavior while introducing enhanced models for efficiency, scalability, and developer flexibility.