Transactions & addresses

SciChain transactions come in two families — classical and post-quantum — but they share one address space and one mempool. A ML-DSA account and an ECDSA account look identical on-chain, hold the same kind of balance, and can freely transact with each other. Only the way a transaction is authenticated changes.

Transaction types

SciChain resolves the signature scheme for a transaction through a signature-type registry. Classical transactions are the familiar Ethereum ones; post-quantum transactions carry an explicit type ID that tells every node which algorithm to verify against.

ECDSA vs. post-quantum: what changes

The important thing to internalize is how little changes. A transaction's payload and EVM semantics are identical across every type: the same to, value, data, nonce, and gas fields drive the same EVM execution at the Shanghai fork level. A contract call behaves the same whether the caller authenticated with ECDSA or ML-DSA.

What differs is authentication — the signature over the transaction's signing hash and the public key used to recover or verify the sender. That single swap is what makes a transaction quantum-safe.

There is a real trade-off, and it is about size. Compare the cryptographic material each scheme attaches to a transaction:

An ML-DSA-44 transaction is physically larger than an ECDSA one — roughly 3.7 KB of extra key and signature material. That means a post-quantum transaction consumes more block space and carries higher intrinsic cost than its classical counterpart. For most workloads this is a comfortable price for quantum resistance, but it is worth budgeting for in high-throughput or calldata-heavy applications. When cost matters more than quantum safety for a given account, classical ECDSA remains available on the same chain.

How a PQC transaction is structured

A post-quantum transaction reuses every classical field and adds three: the signatureType selector, the ML-DSA publicKey, and the ML-DSA signature. The signature is computed over the transaction's signing hash — the transaction fields RLP-encoded and hashed, exactly as in Ethereum — so replay protection via chainId (481) still applies.

// Conceptual shape of an ML-DSA-44 (type 0x01) transaction
{
  nonce:          7,
  maxFeePerGas:   2000000000,      // classical gas fields, unchanged
  gas:            21000,
  to:             "0x8a2f…b19c",     // any 20-byte address (ECDSA or PQC)
  value:          1000000000000000000,
  data:           "0x",
  chainId:        481,               // SciChain — EIP-155 replay protection

  // ---- post-quantum authentication ----
  signatureType:  "0x01",            // DILITHIUM2 / ML-DSA-44
  publicKey:      "0x…",             // 1312 bytes, ML-DSA-44 public key
  signature:      "0x…"              // 2420 bytes, ML-DSA-44 signature over signingHash
}

Because the public key is carried explicitly (ML-DSA does not support the public-key recovery trick ECDSA uses), a node verifies the transaction by hashing the signing fields, then checking the ML-DSA signature against the attached public key. If it verifies, the sender address is derived from that same public key — see below.

Address derivation

SciChain derives addresses with the same 20-byte scheme as Ethereum, applied uniformly to both key types: hash the public key with Keccak-256 and take the last 20 bytes.

// Classical (ECDSA)
address = keccak256(ecdsaPublicKey)[12:32]      // last 20 bytes

// Post-quantum (ML-DSA)
address = keccak256(mldsaPublicKey)[12:32]      // same rule, 1312-byte key in

The consequence matters: addresses are indistinguishable by shape. You cannot tell from a 0x… address alone whether it is backed by an ECDSA or an ML-DSA key — and you do not need to. A post-quantum account can send to and receive from a classical account with no bridge, no wrapping, and no conversion. The address space is one space.

Sending a PQC transaction (conceptual)

The end-to-end flow for a post-quantum transaction mirrors a classical one, with a post-quantum keypair in place of the secp256k1 one:

1. Generate an ML-DSA-44 keypair (secret key + 1312-byte public key).
2. Derive the account address as keccak256(publicKey)[12:32].
3. Fund the address — any account, classical or post-quantum, can send it SCI.
4. Build the transaction with signatureType: 0x01 and the usual fields.
5. Sign the signing hash with the ML-DSA secret key.
6. Attach the public key and signature, then submit via eth_sendRawTransaction.

The following is illustrative pseudo-code — it sketches the steps with a hypothetical scichain.pqc helper, not a fixed SDK API:

// Illustrative — shows the flow, not a fixed SDK surface
import { scichain } from "scichain-sdk";

// 1. Generate an ML-DSA-44 keypair
const keypair = await scichain.pqc.generateKeypair("ml-dsa-44");

// 2. Derive the address (keccak256(pubkey)[12:32])
const from = scichain.pqc.addressFromPublicKey(keypair.publicKey);

// 3. Build the transaction
const tx = {
  from,
  to:    "0x8a2f…b19c",
  value: scichain.parseEther("1.0"),
  nonce: await provider.getTransactionCount(from),
  gas:   21000,
  chainId: 481,
  signatureType: "0x01"          // DILITHIUM2 / ML-DSA-44
};

// 4. Sign with the ML-DSA secret key + serialize
const raw = await scichain.pqc.signTransaction(tx, keypair.secretKey);

// 5. Submit — same JSON-RPC method as any raw tx
const hash = await provider.send("eth_sendRawTransaction", [raw]);
console.log(`submitted ${hash}`);

The submission itself is a stock JSON-RPC call — the raw payload already carries the signatureType, public key, and signature, so nodes know how to verify it:

curl https://rpc.scimatic.net \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0x…"],"id":1}'

# => {"jsonrpc":"2.0","id":1,"result":"0x<transaction hash>"}