Transactions

A transaction is a digitally signed, atomic message initiated by an Externally-Owned Account (EOA) — an account controlled by a human via a private key, not by smart contract code.

Analogy: Think of an EGC transaction as a signed order slip that is submitted to the blockchain network, requesting a state change (e.g., moving EGC, deploying contracts, or executing code).

Example: If Alice sends Bob 10 EGC:

• Alice’s balance → decreases by 10 EGC plus applicable transaction fees.

• Bob’s balance → increases by 10 EGC.

• This state change is permanently recorded on-chain once included in a block.

Prerequisites

• Accounts – Understanding the difference between Externally-Owned Accounts (EOAs) and Contract Accounts.

• Introduction to EGC Blockchain – A high-level overview of network architecture, consensus, and core components.

Transaction Validity Rules Any transaction that changes blockchain state must:

1

Be signed

Be signed using the sender’s private key with ECDSA over the secp256k1 curve.

References:

• EIP-155 (Replay protection)

• Bitcoin’s BIP-62 (Canonical Signatures) influences signature format.

2

Be broadcast

Be broadcast to the peer-to-peer network for inclusion in the mempool.

3

Be validated and added to a block

Be validated and added to a block by a consensus validator.

Transaction Structure An EGC transaction generally conforms to Ethereum’s Legacy Transaction model (EIP-2718 type 0x0) but omits EIP-1559 fields, using a single gas price model.

Field	Description	Standards Reference
from	Sender’s EOA address. Follows EIP-55 (Checksummed Address).	EIP-55
to	Recipient’s address (EOA or Contract). Empty when deploying contracts.	EIP-1014 (address derivation for CREATE2)
gasPrice	Fee per unit of gas, in Wei.	Legacy model per Yellow Paper §6.2.1
gasLimit / gas	Max gas units allowed for transaction execution.	Ethereum Yellow Paper
nonce	Number of transactions sent from this address (prevents replay).	EIP-155
value	Amount of EGCs to transfer (in Wei).	Same as Ethereum
data	Optional field for contract bytecode or ABI-encoded function calls.	EIP-20, EIP-721, EIP-1155 depending on usage
v, r, s (signature)	Signature components from ECDSA signing.	BIP-66 (DER signatures) conceptually influences canonicalization

Gas Gas represents the computational effort required to process a transaction.

• Fee calculation:

fee = gasUsed × gasPrice

• Validators receive the full gas fee.

• Any unused gas is refunded to the sender (EIP-150 gas reduction rules apply).

Example Transaction Object

Example transaction

{
  "from": "0x92a8f3d4a5b8c1d05d1fa35b6c1d6f8af8f7c88a",
  "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
  "gasPrice": "20000000000",
  "gas": "21000",
  "nonce": "0",
  "value": "1000000000000000000",
  "data": "0x",
  "v": "0x25",
  "r": "0x5f6e...",
  "s": "0xa91c..."
}

Transaction Types in EGC EGC Blockchain supports the following transaction types:

1

Standard Transfers

EGC from one EOA to another (EIP-20 style EGC handling).

2

Contract Deployments

to is empty; data contains compiled bytecode.

3

Contract Interactions

to is a deployed contract; data encodes function selector & parameters.

• ABI encoding follows the Ethereum Contract ABI specification (Solidity).

Note: Unlike Ethereum post-London Upgrade (EIP-1559), EGC uses only the legacy gasPrice model — no base fee or priority tip.

Smart Contract Interactions

• Function Selector: First 4 bytes of data are the Keccak-256 hash of the function signature.

• Parameters: ABI-encoded following the Ethereum ABI specification.

• Unused Gas: Refunded per EIP-150 rules.

Transaction Lifecycle

1

Creation & Signing

• The sender’s wallet constructs the transaction fields.

• The transaction is hashed with Keccak-256 and signed with ECDSA (secp256k1).

2

Broadcast to Mempool

• Transaction is propagated to peers via EGC's P2P gossip protocol.

3

Inclusion in Block

• Validators select transactions from the mempool, order them, and execute them according to the Yellow Paper rules.

4

Finalization

• Once the block reaches consensus and sufficient confirmations, the transaction is irreversible without a network-wide attack.

Relevant Standards & References

• Ethereum Yellow Paper – Core transaction execution model. https://ethereum.github.io/yellowpaper/paper.pdf

• EIP-55 – Checksummed addresses. https://eips.ethereum.org/EIPS/eip-55

• EIP-150 – Gas cost changes & refund rules. https://eips.ethereum.org/EIPS/eip-150

• EIP-155 – Replay protection. https://eips.ethereum.org/EIPS/eip-155

• EIP-1014 – CREATE2 for address generation. https://eips.ethereum.org/EIPS/eip-1014

• EIP-20, EIP-721, EIP-1155 – Token and NFT interaction standards. https://eips.ethereum.org/EIPS/eip-20 https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-1155

• EIP-2718 – Typed transaction envelopes (MST currently uses legacy type). https://eips.ethereum.org/EIPS/eip-2718

• BIP-32, BIP-39, BIP-44 – Wallet derivation standards (HD wallets). https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki

• BIP-66 – DER signature enforcement principles. https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki