#Network and RPC

#Chain details

On a phone, open vyrechain.com/add in your wallet app (MetaMask and Trust Wallet open it from a link on that page), or copy the details from there.

#VYRE (mainnet)

#VYRE Testnet

#The public RPC

Both networks have a public RPC (https://rpc.vyrechain.com and https://testnet-rpc.vyrechain.com) that takes JSON-RPC over HTTPS POST. The methods and limits below are written from the testnet's; mainnet's is the same program, but its numbers can differ, so check a live answer before relying on a limit. Two that differ: the most execution gas an eth_call or eth_estimateGas may use (the node's limit for a call) and the chain's own limit for one transaction, which counts execution only; both are 64 million on mainnet, against the testnet's 32 million.

https://testnet-rpc.vyrechain.com takes JSON-RPC over HTTPS POST. It's shared by everyone, so it has limits:

• Methods: the read-only and sending eth_, net_ and web3_ methods (including eth_sendRawTransaction). Not served: eth_simulateV1, wallet and signing methods (eth_sendTransaction, eth_sign*, eth_accounts), the filter family (eth_newFilter, eth_getFilterChanges, eth_getFilterLogs, eth_uninstallFilter and the block and pending-transaction filters) and eth_subscribe. The node itself doesn't have net_listening, net_peerCount or eth_protocolVersion (a client that probes them, such as web3.js's isListening, gets "does not exist"), and eth_accounts and eth_coinbase are refused here rather than answered empty (ethers' listAccounts fails). No debug_, trace_, txpool_, admin_ or arb_ namespaces. There is no WebSocket endpoint and no filters: poll with eth_blockNumber and eth_getLogs, or use the explorer's API for history.
• Batches of 1 to 20 calls (21 or more is refused, each call answered with error -32600 under its own id and HTTP 200, so a library shows the reason; a request that holds sends has its own rules, below); bodies up to 512 KB. Every call in a batch gets its own answer under its own id: a call the RPC refuses (a method it doesn't serve, a call with no method, a log range that is too wide) is answered with its error and the other calls are served. While a body is arriving, at most 1 MB of yours past the first 8 KB of each, and at most 8 of your bodies, can be arriving at once (more is refused with HTTP 429); a body that sends nothing for 3 seconds is cut (HTTP 408); when many large bodies arrive together a large one can be refused with HTTP 503 (try again). An ordinary call is never near these. The bytes you send are also a budget of their own, 512 KB a second with a burst of 2 MB, taken before a body is parsed (HTTP 429 when it is used up); an ordinary call is a few hundred bytes. A request nested more than 32 levels deep, or a list of more than 1,000 calls, is refused with HTTP 400 and -32600 before it is parsed. Bodies larger than 4 KB also draw on a budget shared by all callers (2 MB a second); when many large bodies arrive together one can be refused with HTTP 429 (too much is being sent to this server): wait and send it again.
• Sending transactions (eth_sendRawTransaction, its Sync form, eth_sendRawTransactionConditional) has a lane of its own, apart from reads, so a read is never kept waiting by someone's sends. A request that has a send in it may hold, besides sends, only simple lookups of stored values (eth_blockNumber, eth_chainId, net_version, eth_gasPrice, eth_maxPriorityFeePerGas, eth_getBalance, eth_getTransactionCount, eth_getTransactionReceipt, eth_getTransactionByHash), and at most 2 sends: a request that mixes a send with any other call (an eth_call, a log query), or has more than 2 sends, is refused whole with error -32600 (HTTP 200), each call under its own id. Send a transaction in a request of its own. (viem's http() sends a transaction on its own unless you turn batching on and a read is made in the same instant. ethers v6 batches by default: every call made within 10 ms goes in one request, so a send and a read made together are refused whole, and ethers fails both with the refusal's -32600 error. A client that sends transactions should send them from a viem client with batch: false, or from an ethers provider made with batchMaxCount: 1, or from a second provider used only for sends; batchMaxCount: 10 still batches. Nothing of a refused request reaches the node, so asking again is safe.) A send costs 20 points (see the budget below). The lane has 16 places for sends in progress; when all are taken a send waits up to 2 seconds and is then refused busy, try again; nothing was sent (HTTP 503; the SDK reads those words as a send that never reached the node), and the node is given 5 seconds to answer a send.
• Budget per IP address: 20 points a second, bursts up to 60 (the testnet's public RPC gives each address a larger budget than this). Most calls cost 1 point; eth_call, eth_estimateGas, eth_createAccessList and eth_getLogs cost 10; eth_getBlockReceipts costs 5; each send call (eth_sendRawTransaction and its variants) costs 20 (the node can hold a send for about a second, so a send is priced like a second of your budget; three in a row fit the burst, and a wallet that sends an approval and then a trade is far inside it); a call the RPC answers itself (eth_chainId, net_version, a refused call) costs a quarter of a point. A batch costs the sum of its calls; eth_feeHistory costs 1 point plus 1 for every 100 blocks it covers, doubled when it asks for percentiles (a wallet's few-block call is 1; 1,024 blocks with percentiles is 21); eth_getProof and eth_getStorageValues cost 1 point plus 1 for every 50 storage keys (1,000 keys is 21). Every answer also costs 1 point for each 64 KB of it, taken after the answer is read (a 1 MB answer is 16 points; your next request waits it off). A request that costs more than the burst (seven eth_calls are 70 points, twenty are 200) is served once, from a full bucket, and leaves the bucket in debt that the rate pays off: your next request waits for it (200 points is ten seconds of budget), and the refusal's Retry-After header says how long.
• Bytes per IP address: 512 KB a second, bursts up to 2 MB, counted on the size of each request body before it is parsed. An ordinary call is a few hundred bytes and a contract deployment about 50 KB, so only a caller sending very large bodies one after another meets it: that request is refused with HTTP 429 (too much sent, slow down, with no call id, since the body was not parsed) and Retry-After.
• One request at a time per IP address, with a short line. A request that arrives while yours (or others') is being served waits its turn, up to 2 seconds; up to 32 of yours can wait, but the budget above is taken first: 30 one-point reads at once are served, and 30 eth_calls (10 points each) are not, since a full bucket holds 6 of them and the rest are refused at once with HTTP 429 (rate limited), about 2 more served each second. Send reads that cost 10 points (eth_call, eth_estimateGas, eth_getLogs) as one batch (served once from a full bucket) or through Multicall3. The 34th request waiting at the same moment is refused with HTTP 429 (too many requests waiting). Batching your reads is still the fastest. Behind a shared address (an office or a mobile carrier) everyone shares that one line.
• Request ids are strings (up to 256 characters), integers no larger than 9007199254740991 (a bigger one cannot be read back exactly in JSON, so it is refused rather than answered under another number) or null. A call has jsonrpc, id, method and params and nothing else: another member, or an id of another kind, is refused with -32600 (invalid request) and the reason, under id null when the id is the fault. "params": null is read as no params.
• eth_call and eth_estimateGas may use at most 32 million gas of execution on the testnet (the node's limit for a call). With no gas in the request the node adds the data part of the fee on top, so leave gas out of an estimate: a gas you set is cut to 32 million and the data part counts against it, and at a high data price an estimate sent that way can be refused ("gas required exceeds allowance") for a transaction the chain would take. The chain's own limit for one transaction (32 million on the testnet) counts execution only: a transaction sent with enough gas for its data part goes through however large that part is.
• eth_getLogs covers at most 50,000 blocks a call, or 500,000 when it names an address (the SDK's pages are 50,000 blocks: LOG_PAGE_BLOCKS). A wider range is answered with JSON-RPC error -32602 ("block range too large ... ask in pages") and never reaches the node. The filter takes only the five standard keys, spelled exactly address, topics, fromBlock, toBlock and blockHash; any other key or another letter case is refused, and a key given twice counts once, as its last value (as the node reads it: the call that reaches the node carries that value only). Bounds are hex block numbers or the tags latest, earliest, safe, finalized and pending; the tags are measured at their worst (earliest as block 0, safe and finalized as the node reports them, which can trail the newest block); a number past the newest block counts as the newest block, so toBlock: "0x7fffffff" on a short chain is the whole chain, not two billion blocks. A filter lists at most 200 addresses, has at most 4 topic positions and lists at most 200 alternatives in a position (more is refused with -32602); a list of more than 50 addresses gets the 50,000-block cap, not the 500,000.
• An answer can be at most 16 MB (all of a batch's answers together). A call whose answer would be larger is refused with JSON-RPC error -32005, answer too large: narrow the filter, at HTTP 200, and its request at the node is ended: ask in smaller pieces (a shorter block range, fewer addresses or topics), and don't retry the same call. (The code is the one rate limits use, so a plain viem or ethers client retries it by itself: stop when the message is this one, or use the SDK's vyreHttp, which doesn't.) A batch that is too large as a whole gets the refusal for every call in it, under each call's own id: ask the big call in pieces and the others again.
• Take each answer before asking for the next. An address has one answer on its way out at a time: a request that arrives while your previous answer is still being sent waits its turn (up to 2 seconds) like any other. A client that stops reading an answer is disconnected after 30 seconds. Answers up to 256 KB have room of their own, so big answers held for someone else don't crowd them out.

Past a limit the RPC answers with JSON-RPC error -32005: HTTP 429 (rate limited, slow down or too many requests waiting, slow down) when your own budget or line is used up, HTTP 503 (busy, try again; nothing was sent when the line was full and your call never reached the node, plain busy, try again for the room for answers) when the whole line is full or the server's room for answers being sent is used up (only for answers over 256 KB). Wait and retry: both carry Retry-After (seconds) when waiting helps. Every refusal comes back under the id of the call it refuses, except a refusal made before the body is read (a body over 512 KB, too many bodies arriving, the bytes budget), which has no call to name and carries id null. viem's http() transport retries these by itself. ethers v6 batches every call made within 10 ms into one request of up to 100 calls, which this RPC refuses past 20: create a provider that only reads with new JsonRpcProvider(url, undefined, { batchMaxCount: 10 }); a provider that also sends transactions needs { batchMaxCount: 1 } (batching off), since a send batched with a read is refused whole (see Sending transactions above). Keep one provider, and don't fire many calls at once.

Need more? Batch your reads, or run your own node: ask team@vyrechain.com for the node setup.

#Gas

• Gas is paid in USDC. On mainnet the base fee is 3.14 gwei (0.00000000314 USDC per gas unit) when the chain is quiet; it is set by the chain's owners and can change, so read the current figure from eth_gasPrice, not from this page. On the testnet it is 0.01 gwei.
• Every transaction also pays a small data fee, counted in gas units and added to its gas estimate. The data fee is converted to gas units by dividing it by the base fee, so the lower the base fee the more units it adds. The testnet's base fee is tiny (0.01 gwei), so there a plain transfer estimates at about 1.2 to 1.5 million gas, depending on the day's data price, and a large contract deployment at tens of millions. On mainnet the base fee is far higher, so the same data fee is a small number of gas units and an estimate lands close to the execution gas. A plain transfer carries about 2,500 data units, and the data price follows the parent chain's gas price, which is at least 20 gwei there: at the launch base fee of 3.14 gwei that comes to about 37,000 gas (the transfer's own 21,000 plus about 16,000 for its data fee, 2,500 x 20 / 3.14), worked out from those numbers and not yet measured on mainnet; the same call estimates about 1.2 to 1.5 million at the testnet's 0.01 gwei, depending on the day's data price. That figure is an estimate for one moment, not a promise: the data part grows with the data price (which follows what posting to the parent chain costs, so it can rise when the parent chain is busy) and shrinks in proportion each time the base fee steps up. Read the number from eth_estimateGas rather than expecting either figure. That's expected; only the gas actually used is charged. Always use eth_estimateGas (every library does by default); don't hard-code 21,000.
• Price a transaction with some room above the base fee: at least 1.2 times what eth_gasPrice returns (or the newest fee in eth_feeHistory, whose extra last entry is that same figure, not a forecast). While the chain is busy past its speed limit the base fee can rise about 1% a block, so a transaction priced at exactly the figure you read a moment ago can be refused with max fee per gas less than block base fee. Libraries that add room themselves (viem 1.2 times, ethers 2 times plus a tip) are covered; a wallet or script that sends at the bare eth_gasPrice is not.
• The explorer has no Gas tracker: Blockscout's widget prints any price under 0.1 gwei as "< 0.1 Gwei" and its base and priority lines as whole numbers, and the testnet's base fee is 0.01 gwei. Read the exact figure from eth_gasPrice, or from any transaction page, which prints it in full. A transaction page's "Confirmed within" is the explorer's average gap between blocks (a block is made only when a transaction arrives), not how long that transaction waited: its receipt comes back in under a second.
• Priority fees (tips) are ignored: the sequencer orders transactions first come, first served, and charges only the base fee.
• The explorer's /api/v2/stats shows gas_prices at the floor (rounded: the figure is the explorer's own estimate of the next base fee, which can sit a little below the floor; the testnet's read 0.01 for slow, average and fast on 2026-10-09), so set fees from eth_gasPrice or eth_feeHistory, not from it. Its transactions_today and gas_used_today fields are not reliable (they have read 0, null and a partial day's count, depending on the explorer's settings and restarts); for daily figures use the stats service's charts.

On mainnet a Pad trade costs about a twentieth of a cent at today's base fee (the execution gas of a trade, about 159,000 gas, times the base fee, plus a small data fee; measured every day from real transactions, each one linked: vyrechain.com/gas).

#Blocks and confirmation

• The sequencer makes a block as soon as transactions arrive, in about a quarter of a second; a quiet chain makes no blocks, so block numbers don't measure time. Use block.timestamp.
• A transaction is confirmed once the sequencer includes it (its receipt comes back), usually in under a second. Withdrawals wait longer, until VYRE's state is confirmed on Arc: see Bridge.
• block.number inside a contract is not VYRE's block number (it follows Arc's, the chain VYRE's bridge runs from); use ArbSys(0x64).arbBlockNumber() for VYRE's own.
• Sending back to back from one key: for a moment after a receipt (about 200 ms), eth_getTransactionCount can still return the count from before that transaction, so a library that asks for the nonce again right away (ethers, viem, a script of your own) reuses it and the node refuses the next transaction ("nonce too low", or ethers' "nonce has already been used"). Keep the nonce yourself (the last one sent plus 1, never less than the node's count), or wait a moment and ask again when you see that refusal. Before you sign again with a new nonce, ask the node for the refused transaction's own hash (eth_getTransactionByHash): a transport that sent the same bytes twice (a retry, or a fallback to a second RPC after an answer was lost) gets "nonce too low" for a copy the chain already took, and signing again would send it twice. The SDK does all of this for a key in your script (0.5.9 and later); a browser wallet keeps its own nonces.