Transaction Submission

Submitting a transaction is the initial step in interacting with the Celestium blockchain. This process involves creating a signed transaction that reflects the user's intention, whether it is sending native tokens (CLT), interacting with a smart contract, or deploying a new contract.

Understanding the transaction submission process is essential for both developers building applications on Celestium and users seeking to conduct secure and efficient blockchain operations.

---

1. Preparing a Transaction

A transaction in Celestium adheres to the Ethereum transaction format, following standards such as:

• EIP-2718: Typed Transaction Envelope.

• EIP-2930: Optional Access Lists for Gas Optimization.

Key fields in a transaction:

Field	Description
nonce	Sequence number for the account.
to	Recipient address (or empty for contract deployment).
value	Amount of native token (CLT) to transfer.
gasLimit	Maximum gas units the transaction can consume.
gasPrice	Fee per gas unit in native token.
maxFeePerGas	Maximum fee per gas (used in EIP-1559 transactions).
maxPriorityFeePerGas	Maximum priority fee per gas for miners/validators.
data	Optional data payload (e.g., contract interaction).
signature	ECDSA signature authorizing the transaction.

The transaction is serialized using RLP (Recursive Length Prefix) encoding.

---

2. Gas Estimation

Before submitting, users often estimate gas consumption by calling:

eth_estimateGas

This simulates transaction execution without broadcasting it, helping the user set a suitable gasLimit and avoid out-of-gas failures.

---

3. Signing the Transaction

A transaction is signed using the account's private key. Wallets such as MetaMask or hardware wallets handle signing securely.

The signature covers the transaction fields, ensuring authenticity and preventing tampering.

---

4. Submitting the Transaction

After signing, the transaction is broadcast to the Celestium network through an RPC node:

RPC Call Example:

eth_sendRawTransaction

The node validates the transaction structure and the user's balance before propagating it to the network.

---

5. Validation at Submission

To prevent spam and invalid transactions, Celestium nodes check:

• Sufficient Balance: Ensuring the account can cover value + gasLimit * maxFeePerGas.

• Nonce Matching: The nonce must align with the account's next expected nonce.

• Signature Validity: The ECDSA signature must match the sender's address.

If any check fails, the transaction is rejected with an error message.

---

6. Mempool Propagation

Once validated, the transaction enters the mempool, a temporary pool of pending transactions. Validators select transactions from the mempool during block proposal, prioritizing those with higher fees.

Celestium optimizes mempool management:

• Transactions are sorted by effective gas price (base fee + priority fee).

• Transactions exceeding the available balance are not admitted.

• Replacement Transactions: Users can speed up or cancel pending transactions by submitting a new transaction with the same nonce and higher gas fees.

---

7. Tracking the Transaction Status

Users can track their transaction's status via:

• eth_getTransactionReceipt: Retrieves execution results (success, failure, gas used).

• Block Explorer: http://testnet.celestium.network

Receipt Example:

{
  "transactionHash": "0x...",
  "status": "0x1", // Success (0x0 = Failure)
  "blockNumber": "0x...",
  "gasUsed": "0x...",
  "logs": [ ... ]
}

---

8. Common Errors

Error	Cause
nonce too low	A transaction with a higher nonce has already been sent.
out of gas	Gas limit was insufficient to cover computation.
insufficient funds	Balance is too low for the transaction’s value and fees.
invalid signature	Signature does not match the transaction data.

---

9. Example Using Web3.js

Here is an example of submitting a transaction using Web3.js in Node.js:

const Web3 = require('web3');
const web3 = new Web3('http://rpc-private-testnet.celestium.network');

// Sender's private key and address
const privateKey = '0xYOUR_PRIVATE_KEY';
const senderAddress = '0xYOUR_ADDRESS';

async function sendTransaction() {
  const nonce = await web3.eth.getTransactionCount(senderAddress, 'latest');
  const tx = {
    from: senderAddress,
    to: '0xRecipientAddress',
    value: web3.utils.toWei('0.1', 'ether'),
    gas: 21000,
    gasPrice: web3.utils.toWei('10', 'gwei'),
    nonce: nonce,
    chainId: 252525 // Celestium Testnet
  };

  const signedTx = await web3.eth.accounts.signTransaction(tx, privateKey);
  const receipt = await web3.eth.sendSignedTransaction(signedTx.rawTransaction);

  console.log('Transaction receipt:', receipt);
}

sendTransaction();

---

10. Summary of Transaction Submission Flow

1. Create Transaction: Specify to, value, gasLimit, data, and fee fields.

2. Estimate Gas (Optional): Simulate execution to set an optimal gas limit.

3. Sign Transaction: Use a wallet or library to sign.

4. Submit Transaction: Call eth_sendRawTransaction via RPC.

5. Validate: Node checks balance, nonce, and signature.

6. Propagate: Transaction enters the mempool.

7. Inclusion: Validator includes the transaction in a block.

8. Query Status: Retrieve execution results via RPC or block explorer.

---

Related RPC Endpoints

Method	Description
eth_estimateGas	Estimate gas usage for a transaction.
eth_sendTransaction	Send an unsigned transaction (requires unlocked account).
eth_sendRawTransaction	Submit a signed transaction.
eth_getTransactionReceipt	Retrieve transaction result after execution.

---

Final Notes

Understanding the transaction lifecycle ensures that developers can efficiently interact with Celestium, prevent common submission issues, and optimize fee spending. Proper handling of nonce, gas estimation, and mempool behavior is crucial for seamless on-chain operations.