Pay3 L1 is in active development — a single-node testnet prototype runs today, see Run It Yourself.
Pay3Pay3Docs
/
WebsiteLaunch Wallet
Architecture

Transaction Lifecycle

A wallet doesn't hold a persistent connection to 'the blockchain' — it talks to one RPC node, the same way ethers.JsonRpcProvider talks to Alchemy today. Here's the full path a transaction takes from there to finality.

Wallet to finality

01
Wallet
Builds the transaction — to, value, data, nonce, gas/fee — and signs it locally. The private key never leaves the device.
02
RPC node
Verifies the signature, nonce, balance, and format of the incoming transaction.
03
Mempool
The node's local pending-transaction pool, sorted by fee. The transaction sits here until it's picked up for a block.
04
Network
The node gossips the transaction to peers so every other node's mempool converges on the same pending set.
05
Block proposal
A validator for the current slot packs transactions from the mempool into a block.
06
Execution
The execution engine runs each transaction in the block, producing new account/contract state.
07
Consensus voting
The proposed block and its resulting state root are broadcast; validators sign off once enough stake agrees.
08
Finality
Once agreement is reached, the block is final — it cannot be reverted.
09
Wallet
Polls or subscribes for the receipt, and shows the transaction as confirmed.
Nothing here is unique to Pay3 — it's the same request/response and pub-sub pattern any wallet uses against any RPC-based chain today, including the Pay3 Wallet talking to Alchemy right now. The only thing that changes is which node is on the other end of the call.

What this looks like in code

Because Pay3's RPC mirrors the standard EVM eth_* methods, connecting to it is exactly as unglamorous as connecting to any other EVM chain:

js
// This is *all* "connecting to a blockchain" means at the code level
const provider = new ethers.JsonRpcProvider("https://rpc.pay3.space");

// Reading state — a stateless HTTPS call, nothing "live" about it
const balance = await provider.getBalance(address);

// Submitting a transaction
const signedTx = await wallet.signTransaction(txRequest);
const txHash = await provider.send("eth_sendRawTransaction", [signedTx]);

// Waiting for confirmation — either polling or a WebSocket subscription
const receipt = await provider.waitForTransaction(txHash);

On today's testnet prototype, the same idea is exercised with a much smaller surface — a CLI wallet talking to a single node's RPC rather than a full ethers.js provider. See Run It Yourself to try that flow directly.

Design decisions this shapes

  • EVM-compatible RPC — mirroring eth_* methods means every existing EVM wallet and ethers.js-style code works against Pay3 with little to no client-side changes.
  • Full node vs. light client vs. archive node — wallets typically talk to a full node with current state, not an archive node holding all historical state. What light clients look like on Pay3 affects how accessible it is to run infrastructure at all.