Transaction Types
Armchain introduces Type 3 transactions for post-quantum cryptography. If you're using the Armchain Ethers SDK, this is handled automatically. The SDK creates and signs Type 3 transactions for you. This page is for developers who want to understand the format details or build custom tooling.
Transaction Type Summary
0
Legacy
Pre-EIP-2718
ECDSA
No
1
Access List
EIP-2930
ECDSA
No
2
EIP-1559
EIP-1559
ECDSA
No
3
PQC (Armchain)
-
ML-DSA44
Yes
Armchain only supports Type 3 transactions. ECDSA-signed transactions (Types 0, 1, 2) are rejected by the network.
Type 3 Transaction Format
Fields
type
uint8
Always 0x03
chainId
uint64
Chain ID (55 devnet)
nonce
uint64
Sender account nonce
maxPriorityFeePerGas
uint256
Tip for the validator (EIP-1559)
maxFeePerGas
uint256
Maximum total gas price (EIP-1559)
gasLimit
uint64
Maximum gas for execution
to
address
Recipient (null for contract creation)
value
uint256
ARM amount in wei
data
bytes
Calldata or constructor bytecode
accessList
[]tuple
Storage access list (EIP-2930)
signatureBlob
bytes
ML-DSA44 signature + public key
Signature Blob
The signatureBlob field contains the concatenation of the ML-DSA44 signature and the public key:
ML-DSA44 does not support public key recovery, so both the signature and the public key are included in the blob.
RLP Encoding
Type 3 transactions use typed transaction envelopes (EIP-2718):
The signing payload (hash that is signed) is:
The signature is computed over the sigHash, then the signatureBlob (signature + public key) is appended to the transaction fields.
Creating Type 3 Transactions
Using the Ethers SDK
Manual Transaction Construction
Contract Deployment
Contract Interaction
JSON-RPC Representation
When queried via JSON-RPC (eth_getTransactionByHash), Type 3 transactions include:
Note: Type 3 transactions do NOT have
v,r,sfields. They have a singlesignatureBlobfield instead.
Size Comparison
Transaction fields
~45 bytes
~45 bytes
Signature
65 bytes (v, r, s)
2,420 bytes (raw ML-DSA44)
Public key
0 bytes (recovered from signature)
1,312 bytes (appended to signature)
Signature blob total
65 bytes
3,732 bytes
Total (simple transfer)
~110 bytes
~3,930 bytes
The ~36x increase in transaction size is the cost of quantum resistance. Impact:
Bandwidth: More data to propagate between nodes
Storage: Larger blocks on disk
Intrinsic gas: Higher data-related gas costs
However, it does NOT impact:
Execution gas: EVM computation costs are identical
Finality time: Still instant (Lachesis aBFT)
Throughput: Block gas limits accommodate the larger transactions
Validation Rules
When a Type 3 transaction arrives at a node, the following checks are performed:
Type check: Transaction type must be
0x03Chain ID check: Must match the node's chain ID
Signature blob size: Must be exactly 3,732 bytes (2,420 + 1,312)
ML-DSA44 verification: Verify the signature over the signing hash using the public key from the signature blob
Address derivation: The sender address (
from) is derived from the public key:Keccak256(pubkey)[12:]Nonce check: Must match the sender's current nonce
Balance check: Sender must have sufficient ARM for
value + gas * maxFeePerGasGas limit check: Must be at least the intrinsic gas
If any check fails, the transaction is rejected and not propagated.
Further Reading
ML-DSA44 Deep Dive: Algorithm details
PQC Overview: Why post-quantum cryptography
Ethers SDK: Working with transactions in code
Last updated