Developers Forum for XinFin XDC Network: Daniel Liu

EIP-7702 is available on devnet now

Daniel Liu — Tue, 24 Feb 2026 03:36:49 +0000

EIP-7702 is available on XDC devnet now. It was activated together with EIP-2935 and EIP-7623 at block number 3000600. We sincerely invite you to test it on devnet.

Why roll back testnet

Daniel Liu — Fri, 11 Apr 2025 04:11:48 +0000

Why roll back the testnet

The function DeriveSha computes the transactionsRoot and receiptsRoot fields in each block. And it calls the function EncodeIndex for each item in the transactions list or receipts list during execution.

Our current code is as follows:

func (s Transactions) EncodeIndex(i int, w *bytes.Buffer) {
    tx := s[i]
    if tx.Type() == LegacyTxType {
        rlp.Encode(w, tx.inner)
    } else {
        rlp.Encode(w, tx)
    }
}

func (rs Receipts) EncodeIndex(i int, w *bytes.Buffer) {
    r := rs[i]
    if r.Type == LegacyTxType {
        data := &receiptRLP{r.statusEncoding(), r.CumulativeGasUsed, r.Bloom, r.Logs}
        rlp.Encode(w, data)
    } else {
        rlp.Encode(w, r)
    }
}

But the corresponding code in geth is as follows:

func (s Transactions) EncodeIndex(i int, w *bytes.Buffer) {
    tx := s[i]
    if tx.Type() == LegacyTxType {
        rlp.Encode(w, tx.inner)
    } else {
        tx.encodeTyped(w)
    }
}

func (tx *Transaction) encodeTyped(w *bytes.Buffer) error {
    w.WriteByte(tx.Type())
    return rlp.Encode(w, tx.inner)
}

func (rs Receipts) EncodeIndex(i int, w *bytes.Buffer) {
    r := rs[i]
    data := &receiptRLP{r.statusEncoding(), r.CumulativeGasUsed, r.Bloom, r.Logs}
    switch r.Type {
    case LegacyTxType:
        rlp.Encode(w, data)
    case AccessListTxType:
        w.WriteByte(AccessListTxType)
        rlp.Encode(w, data)
    case DynamicFeeTxType:
        w.WriteByte(DynamicFeeTxType)
        rlp.Encode(w, data)
    default:
    }
}

The above different codes will result in different root hashes. To avoid future accidents, we should use geth code to produce the same value. But the EIP-1559 feature has been actived on testnet from block number 71550000. That is to say, the transactionsRoot and receiptsRoot are inconsistent with geth algorithm from block number 71550000. Although we can introduce a block number parameter to identify old and new blocks, such as:

func (s Transactions) EncodeIndex(i int, w *bytes.Buffer, number *big.Int) {
    tx := s[i]
    if tx.Type() == LegacyTxType {
        rlp.Encode(w, tx.inner)
    } else {
        if number != nil && common.Eip1559TxHashBlock != nil && number.Cmp(common.Eip1559TxHashBlock) < 0 {
            rlp.Encode(w, tx)
        } else {
            tx.encodeTyped(w)
        }
    }
 }

We need to modify 21 files to complete similar modifications. The complex code can increase the risk of bugs. Additionally, since EIP-1559 has not been activated on the mainnet, these code changes are not actually required on the mainnet. So we suggest:

release a new version:
- change cancunBlock from 73425600 to 71550000 for testnet
- pick some commits about hash from PR #933
test new version on devnet
roll back the testnet to 71550000 or less
recreate snapshot for testnet after roll back

Test solidity v0.8.28 on testnet and devnet

Daniel Liu — Thu, 03 Apr 2025 06:00:55 +0000

We have already enabled solidity v0.8.28 on testnet and devnet now. Here is a test project example:

# install node and yarn first

git clone https://github.com/gzliudan/hardhat-project
cd hardhat-project
yarn

cp sample.env .env
# set DEPLOYER_PRIVATE_KEY in .env
# ensure your test account has some XDC token on devnet and testnet
vi .env

# test on XDC devnet
yarn test:xdcdev

# test on XDC testnet
yarn test:apothem

Here is my test result:

yarn run v1.22.22
$ hardhat test --network apothem test/v0.8.23/*.js test/v0.8.28/*.js


  BaseFee contract
Deploy contract BaseFee ...
Deploy contract BaseFee OK, times=1, address: 0xc7758e0E48873cBCC3254924c539750E046013e0
Running on XDC network, chainId=51
    All networks
      Test getChainId
        ✔ should return correct chain ID (299ms)
      Test getBaseFee
        ✔ should return current block number and base fee (652ms)
    XDC network
      ✔ should return expected base fee for XDC networks (754ms)

  Prevrandao contract
Deploy contract Prevrandao ...
Deploy contract Prevrandao OK, times=1, address: 0x66Bbb3fc27Bd8A20247D984a575f069B6A711BfA
    Test getPrevrandao
      ✔ should return current block number and contract value (695ms)

  Push0 contract
Deploy contract Push0 ...
Deploy contract Push0 OK, times=1, address: 0x4F700AD73a59F4Fa02B212Dbf77bB3780C4fA56D
    Test setNum
      ✔ should initialize to 0 (349ms)
      ✔ should set the number correctly (5127ms)
      ✔ should update the number multiple times (18103ms)
      ✔ should handle large numbers (5727ms)

  TestCoin contract
Deploy contract TestCoin ...
Deploy contract TestCoin OK, times=1, address: 0xD5eF8F2A930De17D51a84520808DDd73D4A3E5a8
    Test name
      ✔ should return correct name (257ms)
    Test symbol
      ✔ should return correct symbol (352ms)
    Test total supply
      ✔ should return correct total supply (349ms)
    Test transfer
      ✔ should transfer tokens between accounts (7307ms)
    Test mint
      ✔ should mint new tokens (7359ms)
    Test burn
      ✔ should mint and burn tokens (13139ms)
    Test permit
      ✔ should permit token transfer (7267ms)

  BlobBaseFee contract
Deploy contract BlobBaseFee ...
Deploy contract BlobBaseFee OK, times=1, address: 0x421e05263ac014bE686cAc8C0b7bB860d0e40D49
Running on XDC network, chainId=51
    All Networks
      Test getChainId
        ✔ should return correct chain ID (253ms)
      Test getBlobBaseFee
        ✔ Should return valid blob base fee (345ms)
      Test getBlobHashByIndex
        ✔ Should return valid blob hash for index 0 (365ms)
        ✔ Should return valid blob hash for random index (260ms)
        ✔ Should return valid blob hash for max index (462ms)
      Test getMultipleBlobHashes
        ✔ Should return valid multiple blob hashes starting from index 0 (363ms)
        ✔ Should return valid multiple blob hashes starting from non-zero index (357ms)
        ✔ Should handle zero count in getMultipleBlobHashes (358ms)
    XDC Network
      Test getBlobBaseFee
        ✔ Should return 0 for blob base fee (371ms)
      Test getBlobHashByIndex
        ✔ Should return 0 for blob hash with index 0 (326ms)
        ✔ Should return 0 for blob hash with random index (365ms)
        ✔ Should return 0 for blob hash with max index (341ms)
      Test getMultipleBlobHashes
        ✔ Should return array of zeros starting from index 0 (359ms)
        ✔ Should return array of zeros starting from non-zero index (492ms)

  CustomError contract
Deploy contract CustomError ...
Deploy contract CustomError OK, times=1, address: 0xDa79e4a4e15fcA7BBAb527F4e9cfFE92BC6e8987
    Test withdraw
      ✔ Should pass when amount is valid (401ms)
      ✔ Should revert with InvalidAmount error when amount is 0 (363ms)
      ✔ Should revert with InsufficientBalance error when amount exceeds balance (365ms)
    Test setOwner
      ✔ Should pass when new owner is valid (465ms)
      ✔ Should revert with InvalidAddress error when new owner is zero address (482ms)
      ✔ Should revert with InvalidAddress error when new owner is current owner (482ms)
    Test updateNumbers
      ✔ Should pass when array length matches (476ms)
      ✔ Should revert with ArrayLengthMismatch error when array length does not match (352ms)
    Test complexOperation
      ✔ Should pass when all parameters are valid (463ms)
      ✔ Should revert with InvalidAmount error when amount is 0 (349ms)
      ✔ Should revert with InsufficientBalance error when amount exceeds balance (375ms)
      ✔ Should revert with InvalidAddress error when target is zero address (355ms)

  MCopy contract
Deploy contract MCopy ...
Deploy contract MCopy OK, times=1, address: 0x77Fd93A888c8aF77f0c2A3B65244ee4100d873bd
    Test copyWord
      ✔ Should copy a word correctly (292ms)
      ✔ Should copy zero word correctly (349ms)
      ✔ Should copy max word correctly (357ms)
    Test copyByteArray
      ✔ Should copy a byte array correctly (368ms)
      ✔ Should copy empty array correctly (360ms)
      ✔ Should copy long byte array correctly (364ms)
    Test copyMultipleWord
      ✔ Should copy multiple words correctly (385ms)
      ✔ Should copy zero words correctly (445ms)
      ✔ Should copy multiple zero words correctly (384ms)
    Test copyWithOffset
      ✔ Should copy with offset correctly (488ms)
      ✔ Should copy from start correctly (360ms)
      ✔ Should copy to end correctly (486ms)
      ✔ Should revert when offset + length exceeds source length (387ms)

  TransientStorage contract
Deploy contract TransientStorage ...
Deploy contract TransientStorage OK, times=1, address: 0x8D3eA52bB46921Caee7B003ec548dD95Bcbd90ff
    Test readAndWrite
      ✔ should write and read value from transient storage (418ms)
    Test swapSlots
      ✔ should swap values between slots (363ms)
    Test addSlots
      ✔ should add values and store the result (357ms)


  57 passing (3m)

Test EIP-1559

Daniel Liu — Thu, 06 Feb 2025 07:30:35 +0000

Test EIP-1559 on testnet and devnet

1. RPC

1.1 Devnet

RPC="https://devnetstats.hashlabs.apothem.network/devnet"

1.2 Testnet(Apothem network)

RPC="https://erpc.apothem.network/"
RPC="https://earpc.apothem.network/"

1.3 Mainnet(Xinfin network)

The EIP-1559 feature is not available on the mainnet now. Please wait for 1-2 months.

2. Install foundry

We will use foundry to do some tests. Please install it according to the document, such as:

curl -L https://foundry.paradigm.xyz | bash
source ${HOME}/.bashrc
foundryup

Then create a sample project for test:

cd ${HOME}
rm -rf ${HOME}/counter/
forge init counter
cd counter
# our testnet and devnet support solidity v0.8.28 now
forge build --use solc:0.8.28

3. EIP-1559 block

devnet: 0
testnet(Apothem): 71550000 (14th Feb 2025)
mainet(Xinfin): TBD

4. Test cases

The following cases should be tested before and after EIP-1559 block.

4.1 api eth_getBlockByNumber

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC}  -d '{
  "jsonrpc": "2.0",
  "id": 1001,
  "method": "eth_getBlockByNumber",
  "params": [
    "latest",
    false
  ]
}' | jq

Verify baseFeePerGas field in response:

before EIP-1559 block: this field should not exist
after EIP-1559 block: the value should be 0x2e90edd00 (12500000000)

4.2 api eth_maxPriorityFeePerGas

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1002,
  "method": "eth_maxPriorityFeePerGas",
  "params": []
}' | jq

Verify the value of result field in response is reasonable:

before EIP-1559 block: should be the current gas price
after EIP-1559 block: should be non negative, such as 0x0

4.3 api eth_gasPrice

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1003,
  "method": "eth_gasPrice",
  "params": []
}' | jq

Verify the value of result field in response is right:

before EIP-1559 block: should equal to eth_maxPriorityFeePerGas
after EIP-1559 block: should equal to baseFeePerGas + eth_maxPriorityFeePerGas

4.4 api eth_feeHistory

Usage: https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_feehistory#parameters

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1004,
  "method": "eth_feeHistory",
  "params": [
    "0x3",
    "latest",
    [20,50]
  ]
}' | jq

Verify the value of baseFeePerGas field in response:

before EIP-1559 block: the value should equal to 0
after EIP-1559 block: the value should be 0x2e90edd00 (12500000000)

4.5 eth_getTransactionByHash

Submit 3 transactions to network and record their transaction id:

cd ${HOME}
export PRIVATE_KEY=<YOUR_PRIVATE_KEY>

# tx1: legacy tx, should fail
forge create --broadcast --use solc:0.8.28 --rpc-url ${RPC} --private-key ${PRIVATE_KEY} --gas-price 12499999999 --legacy src/Counter.sol:Counter

# tx2: legacy tx, should success
forge create --broadcast --use solc:0.8.28 --rpc-url ${RPC} --private-key ${PRIVATE_KEY} --gas-price 12500000000 --legacy src/Counter.sol:Counter

# tx3: EIP-1559 tx with parameter maxFeePerGas, should fail
forge create --broadcast --use solc:0.8.28 --rpc-url ${RPC} --private-key ${PRIVATE_KEY} --gas-price 12499999999 src/Counter.sol:Counter

# tx3: EIP-1559 tx with parameter maxFeePerGas, should success
forge create --broadcast --use solc:0.8.28 --rpc-url ${RPC} --private-key ${PRIVATE_KEY} --gas-price 12500000000 src/Counter.sol:Counter

# tx3: EIP-1559 tx with maxPriorityFeePerGas, should success
forge create --broadcast --use solc:0.8.28 --rpc-url ${RPC} --private-key ${PRIVATE_KEY} --priority-gas-price 0 src/Counter.sol:Counter

tx1: should be successful before and after EIP-1559 block
tx2: should be successful only after EIP-1559 block
tx3: should be successful only after EIP-1559 block

# eg: hash="0xc64985e6faccc11c96a8baef1d989888022b75c958095e69d5e30938142a0375"
hash=<TX_HASH_ID>

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1005,
  "method": "eth_getTransactionByHash",
  "params": [
    "'"${hash}"'"
    ]
}' | jq

Verify the following fields in the response:

type: should be 0 in tx1, be 2 in tx2 and tx3
gasPrice: exist in all transactions
maxFeePerGas: only exist in tx2 and tx3, the value in tx2 should be 12501000000
maxPriorityFeePerGas: only exist in tx2 and tx3, the value in tx3 should be 1000

4.6 eth_getTransactionReceipt

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1006,
  "method": "eth_getTransactionReceipt",
  "params": [
    "'"${hash}"'"
  ]
}' | jq

Verify tx's type and effectiveGasPrice in the response.

4.7 eth_getBlockReceipts

# eg: NUMBER="0x8"
NUMBER=<NUMBER>

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1007,
  "method": "eth_getBlockReceipts",
  "params": [
    "'"${NUMBER}"'"
    ]
}' | jq

Verify tx's type and effectiveGasPrice in the response.

4.8 eth_getLogs

Request:

FROM=<FROM_BLOCK_NUMBER>
TO=<TO_BLOCK_NUMBER>

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc":"2.0",
  "id": 1008,
  "method":"eth_getLogs",
  "params":[
    {
      "fromBlock":  "'"${FROM}"'",
      "toBlock":  "'"${TO}"'"
    }
  ]
}' | jq

Verify the result is right.

4.9 Test synchronization

Setup a node and sync with network.

4.10

Test with other tools, such as: MetaMask, Remix.

Deploy StableCoin on XDC by EIP-1559

Daniel Liu — Mon, 16 Dec 2024 03:21:26 +0000

The devnet of XDC supports EIP-1559 now. This article demonstrates how to setup stablecoin on devnet by EIP-1559.

install nvm

Please install nvm first:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

Then close your current terminal simply, open a new terminal to make nvm take effect.

install node and yarn

The stablecoin-evm project requires node v20.9.0 and yarn v1.22.19:

https://github.com/circlefin/stablecoin-evm/blob/master/package.json#L100-L101:

  "engines": {
    "node": "20.9.0",
    "yarn": "1.22.19"
  }

So we install node and yarn with the following commands:

nvm install v20.9.0
nvm use v20.9.0
npm install -g yarn@1.22.19

install stablecoin-evm

Install stablecoin-evm step by step according to the README. But we have to update the Foundry's version in the file setup.sh since nightly-f625d0fa7c51e65b4bf1e8f7931cd1c6e2e285e9 has problem to support EIP-1559.

git clone https://github.com/circlefin/stablecoin-evm
cd stablecoin-evm

# Use nightly-206dab285437bd6889463ab006b6a5fb984079d8 which is latest at 2024-12-16
VER="nightly-206dab285437bd6889463ab006b6a5fb984079d8"
sed -i "s/^FOUNDRY_VERSION=nightly.*/FOUNDRY_VERSION=${VER}/" setup.sh

yarn
yarn compile
yarn hardhat typechain

configure stablecoin-evm

Prepare 1 private key for deploy and 2 addresses for administration:

echo "[]" > blacklist.remote.json
cp .env.example .env
vi .env

Here is my .env file:

DEPLOYER_PRIVATE_KEY="0x1234......"
TOKEN_NAME=USDC
TOKEN_SYMBOL=USDC
TOKEN_CURRENCY=USD
TOKEN_DECIMALS=6
PROXY_ADMIN_ADDRESS="0x85f33E1242d87a875301312BD4EbaEe8876517BA"
OWNER_ADDRESS="0xD4CE02705041F04135f1949Bc835c1Fe0885513c"
MASTER_MINTER_OWNER_ADDRESS="0xD4CE02705041F04135f1949Bc835c1Fe0885513c"
GAS_MULTIPLIER=110
BLACKLIST_FILE_NAME=blacklist.remote.json

Notice:

PROXY_ADMIN_ADDRESS must be different with OWNER_ADDRESS
PAUSER_ADDRESS is optional, will be OWNER_ADDRESS if not set
BLACKLISTER_ADDRESS is optional, will be OWNER_ADDRESS if not set
LOST_AND_FOUND_ADDRESS is optional, will be OWNER_ADDRESS if not set

deploy on devnet

We can remove the --legacy flag in command line since the devnet supports EIP-1559 now:

forge script -vv --broadcast scripts/deploy/deploy-fiat-token.s.sol --rpc-url https://devnetstats.hashlabs.apothem.network/devnet/

[⠢] Compiling...
No files changed, compilation skipped
Script ran successfully.

== Return ==
0: contract FiatTokenV2_2 0xcFBFDe74F1C71a49EEC3050ca3a0CB0A5de92F8E
1: contract MasterMinter 0x7bdb6EaB59864eE77C256cA3ca76533d28e8D143
2: contract FiatTokenProxy 0x1e1fEAa7c2C1Be60f3F4b864A4389Cd99f00a9dd

== Logs ==
  TOKEN_NAME: 'USDC'
  TOKEN_SYMBOL: 'USDC'
  TOKEN_CURRENCY: 'USD'
  TOKEN_DECIMALS: '6'
  FIAT_TOKEN_IMPLEMENTATION_ADDRESS: '0x0000000000000000000000000000000000000000'
  PROXY_ADMIN_ADDRESS: '0x85f33E1242d87a875301312BD4EbaEe8876517BA'
  MASTER_MINTER_OWNER_ADDRESS: '0xD4CE02705041F04135f1949Bc835c1Fe0885513c'
  OWNER_ADDRESS: '0xD4CE02705041F04135f1949Bc835c1Fe0885513c'
  PAUSER_ADDRESS: '0xD4CE02705041F04135f1949Bc835c1Fe0885513c'
  BLACKLISTER_ADDRESS: '0xD4CE02705041F04135f1949Bc835c1Fe0885513c'

## Setting up 1 EVM.

==========================

Chain 551

Estimated gas price: 25.000000001 gwei

Estimated total gas used for script: 10475541

Estimated amount required: 0.261888525010475541 ETH

==========================

##### 551
✅  [Success] Hash: 0x4c455802ca637ef7df21f6d3de372c1c07f5f2d88c52a1857db1657570000034
Contract Address: 0x1e1fEAa7c2C1Be60f3F4b864A4389Cd99f00a9dd
Block: 24076108
Paid: 0.007444637500595571 ETH (595571 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x5b82f47197bf00198e2fc9d7f7f7ce916d57bbffc152199d334719e26d09c059
Block: 24076108
Paid: 0.000439737500035179 ETH (35179 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0xd47ba4c5addee62973ec8a28e481acfeefc559418aac3569db585ced683d5b34
Contract Address: 0xf44117366AE0D8F43260E0262527FB9EB2003cad
Block: 24076108
Paid: 0.006345687500507655 ETH (507655 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x6b1999f459fc08fa33a41a2f28d8b9203010cd1b9e963b6212ee5ff4f8f31999
Contract Address: 0xcFBFDe74F1C71a49EEC3050ca3a0CB0A5de92F8E
Block: 24076108
Paid: 0.076860275006148822 ETH (6148822 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x571c359953870602fa6ca148c95f68a160bb6a98e5aaa95f0f175b8ee52356fe
Block: 24076108
Paid: 0.000618362500049469 ETH (49469 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x533aa609224a486a027320e29b1c71368b048efe346ec4055718c0d8b43bb52e
Block: 24076108
Paid: 0.001147850000091828 ETH (91828 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x45adfb2fe8e3e6cf46f43127fc496a693526f4e01562bfb7582e8e14f38eee81
Block: 24076108
Paid: 0.001410037500112803 ETH (112803 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0xf4f2981de76a559d7746775e9442e81fa0fba7999bb96bff83a3cb9894d20d37
Contract Address: 0x7bdb6EaB59864eE77C256cA3ca76533d28e8D143
Block: 24076108
Paid: 0.018582650001486612 ETH (1486612 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x3d060ff7dda50f202a952ed7a2dd07a31eed5addfd0a9a82229b8a9eb24dbbdd
Block: 24076108
Paid: 0.000334912500026793 ETH (26793 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x19fac97efe0f5b406735d1789a12bbc833e9455e5996c187a8ae410d7343ae66
Block: 24076108
Paid: 0.000560837500044867 ETH (44867 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x4ce999526026546ac62a60882aefda4ebbd006d405ef93585d4243f696ecffe6
Block: 24076108
Paid: 0.001019800000081584 ETH (81584 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x88741cf2dfb0da5dd5b7c6e7d5a3a2c6fea1094f253d35e647cc79bccadf0350
Block: 24076108
Paid: 0.000723087500057847 ETH (57847 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x5f7be603ffdb556bd506e14ef00c8c42c19f821c0dc8b3a59ac5b25fef99526f
Block: 24076108
Paid: 0.0003687500000295 ETH (29500 gas * 12.500000001 gwei)


##### 551
✅  [Success] Hash: 0x3c821e83e681fc67255d556c207935249377d46159a79d2c040bf44c8485d268
Block: 24076108
Paid: 0.002705475000216438 ETH (216438 gas * 12.500000001 gwei)

✅ Sequence #1 on 551 | Total Paid: 0.118562100009484968 ETH (9484968 gas * avg 12.500000001 gwei)


==========================

ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.

Transactions saved to: /home/me/stablecoin-evm/broadcast/deploy-fiat-token.s.sol/551/run-latest.json

Sensitive values saved to: /home/me/stablecoin-evm/cache/foundry/deploy-fiat-token.s.sol/551/run-latest.json

Verify

TODO: The devnet does not support etherscan now. We will test the following command on testnet later.

yarn forge:verify scripts/deploy/deploy-fiat-token.s.sol --rpc-url <RPC>

The metrics of XDC chain

Daniel Liu — Wed, 11 Dec 2024 06:35:05 +0000

The metrics has been improved in the PR #758 greatly.

1. Metrics flags

XDC includes a variety of optional metrics that can be reported to the user. However, metrics are disabled by default to save on the computational overhead for the average user.

The following flags exist in the PR #758:

--metrics                       (default=false):
    Enable metrics collection and reporting
--metrics-addr                  (default="127.0.0.1"):
    Enable stand-alone metrics HTTP server listening interface
--metrics-port                  (default=6060):
    Metrics HTTP server listening port
--metrics-influxdb              (default=false):
    Enable metrics export/push to an external InfluxDB database
--metrics-influxdb.endpoint     (default="<http://localhost:8086>"):
    InfluxDB API endpoint to report metrics to
--metrics-influxdb.database     (default="xdc"):
    InfluxDB database name to push reported metrics to
--metrics-influxdb.username     (default="test"):
    Username to authorize access to the database
--metrics-influxdb.password     (default="test"):
    Password to authorize access to the database
--metrics-influxdb.tags         (default="host=localhost"):
    Comma-separated InfluxDB tags (key/values) attached to all measurements
--metrics-influxdbv2            (default=false):
    Enable metrics export/push to an external InfluxDB v2 database
--metrics-influxdb.token        (default="test"):
    Token to authorize access to the database (v2 only)
--metrics-influxdb.bucket       (default=xdc"):
    InfluxDB bucket name to push reported metrics to (v2 only)
--metrics-influxdb.organization (default="xdc"):
    InfluxDB organization name (v2 only)

2. Metric types

XDC's metrics can be classified into four types: meters, timers, counters and gauges.

2.1 Meters

Analogous to physical meters (electricity, water, etc), XDC's meters are capable of measuring the amount of "things" that pass through and at the rate at which they do. A meter doesn't have a specific unit of measure (byte, block, malloc, etc), it just counts arbitrary events. At any point in time a meter can report:

Total number of events that passed through the meter
Mean throughput rate of the meter since startup (events / second)
Weighted throughput rate in the last 1, 5 and 15 minutes (events / second) ("weighted" means that recent seconds count more that in older ones*)

2.2 Timers

Timers are extensions of meters, the duration of an event is collected alongside a log of its occurrence. Similarly to meters, a timer can also measure arbitrary events but each requires a duration to be assigned individually. In addition generating all of the meter report types, a timer also reports:

Percentiles (5, 20, 50, 80, 95), reporting that some percentage of the events took less than the reported time to execute (e.g. Percentile 20 = 1.5s would mean that 20% of the measured events took less time than 1.5 seconds to execute; inherently 80%(=100%-20%) took more that 1.5s)
Percentile 5: minimum durations (this is as fast as it gets)
Percentile 50: well behaved samples (boring, just to give an idea)
Percentile 80: general performance (these should be optimised)
Percentile 95: worst case outliers (rare, just handle gracefully)

2.3 Counters

A counter is a single int64 value that can be incremented and decremented. The current value of the counter can be queried.

2.4 Gauges

A gauge is a single int64 value. Its value can increment and decrement - as with a counter - but can also be set arbitrarily.

3. Querying metrics

XDC collects metrics if the --metrics flag is provided at startup. Those metrics are available via an HTTP server if the --metrics-addr flag is also provided. By default the metrics are served at 127.0.0.1:6060/debug/metrics but a custom IP address can be provided. A custom port can also be provided to the --metrics-port flag. For example, to serve all metrics at the default address and port:

XDC <other commands> --metrics --metrics-addr 127.0.0.1

Navigating the browser to the given metrics address displays all the available metrics in the form of JSON data that looks similar to:

{
    "chain/account/commits.50-percentile": 1763,
    "chain/account/commits.75-percentile": 1763,
    "chain/account/commits.95-percentile": 1763,
    "chain/account/commits.99-percentile": 1763,
    "chain/account/commits.count": 1,
    "chain/account/commits.mean": 1763,
    "chain/account/hashes.50-percentile": 962,
    "chain/account/hashes.75-percentile": 962,
    "chain/account/hashes.95-percentile": 962,
    "chain/account/hashes.99-percentile": 962,
    "chain/account/hashes.count": 1,
    "chain/account/hashes.mean": 962,
    ...
}

XDC also supports dumping metrics directly into an influx database. In order to activate this, the --metrics-influxdb flag must be provided at startup. The API endpoint, username, password and other influxdb tags can also be provided.

We also provide Prometheus-formatted metrics data, which can be obtained through the http://127.0.0.1:6060/debug/metrics/prometheus URL, eg:

# TYPE chain_account_commits_count counter
chain_account_commits_count 1

# TYPE chain_account_commits summary
chain_account_commits {quantile="0.5"} 2305
chain_account_commits {quantile="0.75"} 2305
chain_account_commits {quantile="0.95"} 2305
chain_account_commits {quantile="0.99"} 2305
chain_account_commits {quantile="0.999"} 2305
chain_account_commits {quantile="0.9999"} 2305

# TYPE chain_account_hashes_count counter
chain_account_hashes_count 1

# TYPE chain_account_hashes summary
chain_account_hashes {quantile="0.5"} 1283
chain_account_hashes {quantile="0.75"} 1283
chain_account_hashes {quantile="0.95"} 1283
chain_account_hashes {quantile="0.99"} 1283
chain_account_hashes {quantile="0.999"} 1283
chain_account_hashes {quantile="0.9999"} 1283

...

4. Summary

XDC can be configured to report metrics to an HTTP server or database. These functions are disabled by default but can be configured by passing the appropriate commands on startup.

EIP1559 call for early users

Daniel Liu — Wed, 26 Jun 2024 07:48:36 +0000

EIP1559 call for early users

The develpment of EIP1559 is completed by https://github.com/XinFinOrg/XDPoSChain/pull/527 now.

Our parameters:

InitialBaseFee: 12.5 GWei
BaseFee: fixed value 12.5 GWei
GasLimit of block: not changed

1. Get source code

git clone https://github.com/XinFinOrg/XDPoSChain.git

2. Test private network

2.1 Create genesis

If genesis file is not exist, it can be created according to the below guides:

Then add parameter eip1559Block to your genesis file, such as:

{
  "config": {
    "eip1559Block": 0,
  }
}

Here I use block number 0 as the EIP1559 block because I will start a new private network. You can use any block number you like. If an existing private network is used, then it must be greater than the current block number.

Notice: we can also set the variable Eip1559Block in the file common/constants.go.

2.2 Start private network

Then you can build and start your private network according to guides.

3. How to use

3.1 foundry

legacy transaction: --legacy or --legacy --gas-price <price>
EIP1559 transaction with max fee per gas : --with-gas-price <price>
EIP1559 transaction with priority fee per gas: --priority-gas-price <PriorityFee>

3.2 MetaMask

You can edit Max base fee and Priority Fee manually before confirm transaction.

3.3 HardHat

It seems that hardhat.config.js has no parameters for EIP1559. But we can define parameters in the individual transaction code. Please refer to https://medium.com/klaytn/using-ethereum-tools-in-klaytn-dc068d48de04.

3.4 Truffle

3.5 viem

4. Releated API

RPC="http://localhost:8545/"

4.1 eth_getBlockByNumber

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC}  -d '{
  "jsonrpc": "2.0",
  "id": 1001,
  "method": "eth_getBlockByNumber",
  "params": [
    "latest",
    false
  ]
}' | jq

Response:

{
  "result": {
    "baseFeePerGas": "0x2e90edd00",
  }
}

Verify: baseFeePerGas = 12500000000.

4.2 eth_maxPriorityFeePerGas

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1002,
  "method": "eth_maxPriorityFeePerGas",
  "params": []
}' | jq

Response:

{
  "result": "0x1"
}

Verify: result is reasonable.

4.3 eth_gasPrice

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1003,
  "method": "eth_gasPrice",
  "params": []
}' | jq

Response:

{
  "result": "0x2e90edd01"
}

Verify: result = baseFeePerGas + eth_maxPriorityFeePerGas.

4.4 eth_feeHistory

Usage: https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_feehistory#parameters

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1004,
  "method": "eth_feeHistory",
  "params": [
    "0x3",
    "latest",
    [20,50]
  ]
}' | jq

4.5 eth_getTransactionByHash

Send 3 transactions to the private network, such as:

legacy tx: forge script -vv --broadcast --legacy scripts/deploy/deploy-fiat-token.s.sol --rpc-url ${RPC}
EIP1559 tx with parameter maxFeePerGas: forge script -vv --broadcast scripts/deploy/deploy-fiat-token.s.sol --rpc-url ${RPC} --with-gas-price 12501000000
EIP1559 tx with maxPriorityFeePerGas: forge script -vv --broadcast scripts/deploy/deploy-fiat-token.s.sol --rpc-url ${RPC} --priority-gas-price 1000

and record their transaction id.

Request:

# eg: HASH="0xc64985e6faccc11c96a8baef1d989888022b75c958095e69d5e30938142a0375"
HASH=<HASH>

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1005,
  "method": "eth_getTransactionByHash",
  "params": [
    "'"${HASH}"'"
    ]
}' | jq

Then verify tx's type, gasPrice, maxFeePerGas, maxPriorityFeePerGas in the response.

4.6 eth_getBlockReceipts

# eg: NUMBER="0x8"
NUMBER=<NUMBER>

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1006,
  "method": "eth_getBlockReceipts",
  "params": [
    "'"${NUMBER}"'"
    ]
}' | jq

Verify tx's type and effectiveGasPrice in the response.

4.7 eth_getTransactionReceipt

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 5002,
  "method": "eth_getTransactionReceipt",
  "params": [
    "'"${HASH}"'"
  ]
}' | jq

Verify tx's type and effectiveGasPrice in the response.

5. Test synchronization

Although out network does not support EIP1559 now, the new codes can synchronize with any network normally and act as RPC without EIP1559 functions. You can use below scripts to sync:

devnet: sync_devnet.sh
testnet: sync-apothem.sh
mainnet: sync-xinfin.sh

[Informative]Release graph node v0.32.0 for xdc chain

Daniel Liu — Tue, 29 Aug 2023 04:04:22 +0000

https://github.com/XinFinOrg/XDC-Graph-Node

Support xdc prefix
Bypass the eth_getLogs bug of xdc chain
Add flag no_eip1898 for xdc chain
Provide new docker image

[Infomative]graph-node v0.31.0 for xdc

Daniel Liu — Thu, 03 Aug 2023 07:39:48 +0000

https://github.com/Carry-So/graph-node/blob/xdc-release-0.31.0/README.md

Sign in with XDCPay 2.0

Daniel Liu — Mon, 17 Apr 2023 09:18:27 +0000

This article introduces how to authenticate user by:

1. Introduction

1.1 About ERC-4361

Sign in with Ethereum is a new form of authentication that enables users to control their digital identity with their Ethereum account and ENS profile instead of relying on a traditional intermediary.

Today’s login experiences rely on accounts controlled by centralized identity providers, for-profit behemoths like Google, Facebook, and Apple. Identity providers often have sole discretion over the existence and use of users’ digital identities across the web, fundamentally at odds with the best interest of users.

The Ethereum Foundation and Ethereum Name Service (ENS) put forward a Request for Proposal for Sign-in with Ethereum in 2021, which would enable users to use their Ethereum accounts to access web services instead of accounts owned by large corporations.

Sign-In with Ethereum describes how Ethereum accounts authenticate with off-chain services by signing a standard message format parameterized by scope, session details, and security mechanisms (e.g., a nonce).

Already, many services support workflows to authenticate Ethereum accounts using message signing, such as establishing a cookie-based web session which can manage privileged metadata about the authenticating address.

For Web2, this is an opportunity to give users control over their identifiers and slowly introduce their dedicated user bases to Web3. By providing a strict specification that can be followed along with any necessary tooling to ease any integration concerns, Sign-In with Ethereum has a chance at truly transforming the way in which individuals interact with apps and services.

For Web3, this is an opportunity to standardize the sign-in workflow and improve interoperability across existing services, while also providing wallet vendors a reliable method to identify signing requests as Sign-In with Ethereum requests for improved UX.

1.2 About XDCPay 2.0

The XDCPay is an extension for accessing XDC's XDPoS enabled distributed applications, or "Dapps" in your browser!

The extension injects the XDC's XDPoS web3 API into every website's javascript context, so that dapps can read from the blockchain.

The XDCPay extension also lets the user create and manage their own identities (via private keys, local client wallet), so when a Dapp wants to perform a transaction and write to the blockchain.

1.3 About XinFin

XinFin is an enterprise-ready hybrid Blockchain technology company optimized for international trade and finance. The XinFin network is powered by the native coin XDC and uses XinFin Delegated Proof of Stake (XDPoS) consensus architecture to support smart contracts, 2000TPS, 2-second transaction time, near-zero GAS fees, and KYC to Masternodes (Validator Nodes). XDC also creates an opportunity to useXinFin’s real-world use-cases such as TradeFinex.org, which helps small and medium businesses or institutions originate their own financial requirements in a digital, fully structured manner so that they can distribute it to the bank or non-bank funders themselves using a common distribution standard. It also allows access to Mycontract.co, a middleware that connects any two centralized systems using decentralized APIs running on XDC blockchain Network.

2. Run the demo

2.1 Download source code

Execute the following commands:

cd ${HOME}
git clone https://github.com/gzliudan/sign-in-with-xdcpay.git

2.2 Start the backend

Execute the following commands, remember to change <BACKEND_IP> to your real IP address:

# set BACKEND_IP according to your environment
export BACKEND_IP=<BACKEND_IP>

cd ${HOME}/sign-in-with-xdcpay/backend
npm install
npm start

eg:

2.3 Start the frontend

Open a new terminal window, execute the following commands, remember to change <BACKEND_IP> to your real IP address:

# set BACKEND_IP according to your environment
export BACKEND_IP=<BACKEND_IP>

cd ${HOME}/sign-in-with-xdcpay/frontend
npm install
npm run dev

eg:

3. Test the demo

3.1 Open web page

Open the url which is after On Your Network (IPv4): in the above screenshoot, such as http://10.146.1.124:8080/.

3.2 Connect the wallet

Click Connect wallet button:

3.2.1 Switch to XinFin network

If your XDCPay's current network is not XinFin network, please swith to XinFin network in XDCPay manually:

3.2.2 Connect XDCPay account

If there is no account connected to the XDCPay, the web page will request Connect With XDCPay:

3.2.2.1 Choose an account

Select the account(s) if your XDCPay contains multiple accounts.

3.2.2.2 Connect to account

Then click Next button:

At last click Connect button on the XDCPay's second popup window.

3.2.3 Show connect status

If it's connected, the web page will popup a window:

It shows Connect XDCPay OK, click OK button to close it.

3.3 Get information before sign in

Click Get session info button, the web page will popup a window:

It shows You are not sign in, click OK button to close it.

3.4 Sign in with XDCPay

Click Sign in with XDCPay 2.0 button, the XDCPay will prompt you to sign the below message:

Then click Sign button on the XDCPay's popup window. At last the web page will popup a window:

It shows sign in Ok with XDCPay account: 0XD4CE02705041F04135F1949Bc835c1Fe0885513C, click OK button to close it.

3.5 Get information after sign in

Click Get session info button, the web page will popup a window:

It shows You are authenticated with XDCPay account: 0xD4CE02705041F04135F1949Bc835c1Fe0885513C, click OK button to close it.

4. Some source codes

4.1 The backend

The backend server handle the user's submission using Express.js, it

gives the frontend a nonce to include in the SIWE message
verifies the submission
returns the authenticating state

As such, this basic example only provides three endpoints:

/nonce: generate the nonce for the interaction via GET request
/verify: verify the submitted SIWE message and signature via POST request
/info: retrieve the information from the session in place via GET request

4.1.1 endpoint nonce

This endpoint returns a different nonce for each request.

app.get("/nonce", async function (req, res) {
  req.session.nonce = generateNonce();
  res.setHeader("Content-Type", "text/plain");
  res.status(200).send(req.session.nonce);
});

Open a new terminal window, run below command to test:

curl 'http://localhost:3000/nonce' && echo

4.1.2 endpoint verify

4.1.2.1 validate SiweMessage object

const message = new SiweMessage(req.body.message);

We validate the received SIWE message by parsing it back into a SiweMessage object (the constructor handles this), assigning the received signature to it and calling the validate method:

const fields = await message.validate(req.body.signature);

message.validate(req.body.signature) in the above snippet makes sure that the given signature is correct for the message, ensuring that the XinFin blockchain address within the message produced the matching signature. In other applications, you may wish to do further validation on other fields in the
message, for example asserting that the authority matches the expected domain, or checking that the named address has the authority to access the named URI.

4.1.2.2 req.session

req.session.siwe = fields;
req.session.cookie.expires = new Date(fields.expirationTime);

The session (req.session) stores the nonce for the initial validation of the message, and once that's done, more can be added. For example here we store the message's fields, so we can always reference the address of the user.

4.1.3 endpoint info

This endpoint is used to retrieve the information from the session in place, without having to send the message and signature every time.

app.get("/info", function (req, res) {
  if (!req.session.siwe) {
    res.status(401).send("You are not sign in");
    return;
  }
  res.setHeader("Content-Type", "text/plain");
  res.send(
    `You are authenticated with XinFin blockchain account: ${req.session.siwe.address}`
  );
});

4.2 The frontend

4.2.1 ethers.js

ethers.js is a library that provides functionality for interacting with the Ethereum blockchain. We use it here for connecting the webpage to extension wallets.

4.2.2 XDCPay

const provider = new ethers.providers.Web3Provider(window.ethereum);
const signer = provider.getSigner();

The XDCPay extension injects the window.ethereum object into every web page, and the ethers library provides a convenient provider class to wrap it. We then use this provider to connect to the wallet, and access signing capabilities.

4.2.3 eth_requestAccounts

try {
  await provider.send("eth_requestAccounts", []);
  message = `Connect XinFin blockchain OK`;
} catch (err) {
  message = `Fail to request account: ${err.message}`;
}

The eth_requestAccounts function will send a request to the XDCPay extension to ask permission to view information about the XinFin accounts that it controls. XDCPay will then show a window to the user asking them to authorize our application to do so. If they authorize the request then we've connected their account.

4.2.4 signMessage

await signer.signMessage(message);

Sign message with the above code.

4.2.5 SiweMessage

Creating SIWE messages in JavaScript is straightforward when using the siwe library:

const message = new SiweMessage({
  domain,
  address,
  statement,
  uri: origin,
  version: "1",
  chainId: "50", // chain id of XinFin blockchain
  nonce: await res.text(),
});

The SiweMessage's fields we are most interested in are address and statement. The address is the XinFin blockchain address which the user is signing in with, and the statement as this will describe to the user what action we wish to perform on their behalf.

Hummingbot supports xdc blockchain and xsswap exchage now

Daniel Liu — Tue, 11 Apr 2023 04:37:12 +0000

Hummingbot released out v1.14.0 on March 30, 2023. It supports xdc blockchain and xsswap exchange from this version.

Deploy and call smart contract on XinFin blockchain from thirdweb dashboard

Daniel Liu — Thu, 06 Apr 2023 08:17:50 +0000

1. About thirdweb

Thirdweb is a complete web3 development framework that provides everything you need to connect your apps and games to decentralized networks. It provides workflows to speed up your development, including:

2. Prebuilt contracts

Deploying smart contracts is the first step of building any web3 application. You can deploy one of prebuilt contracts for more common use cases (NFTs, tokens, marketplaces), or you can build your own smart contract with Solidity SDK and ship it with Deploy. The prebuilt contracts are:

Fully open-source on GitHub
Consistently audited by trusted firms
10x cheaper to deploy than ordinary smart contracts
Completely owned by you

3. Deploy steps

3.1 Connect wallet

Open dashboard in web browser:

Click Connect Wallet button:

Choose your wallet according to actual situation, here I choose MetaMask:

3.2 Configure networks

If you have not configured networks, or want to modify the network configuration, then you must perform this operation.

Click Configrue Networks icon in top navigation bar:

Type xdc in Network name input box to search by name:

3.2.1 Add XinFin mainnet

Choose XinFin XDC Network:

Then change RPC URL to https://erpc.xinfin.network:

At last click Add Network button:

3.2.2 Add Apothem testnet

Type xdc in Network name input box again, and choose XDC Apothem Network:

Then change Network type to Testnet, and RPC URL to https://erpc.apothem.network/:

At last click Add Network button:

3.3 Choose contract

Chick Browse contracts card under Get started quickly subject, or click explorer link to visit explorer page:

Here I click Token card to choose ERC20:

3.4 Deploy contract

Click Deploy now button:

Then input:

Name: My Demo Token
Symbol: MDT
Description: A demo ERC20 token

And choose network, here I choose XDC Apothem Network(TXDC):

Next click Deploy Now button:

Confirm transaction one or more times:

And sign the message to add contract to dashboard:

At last it appears in dashboard:

4. Interact with contract

4.1 Mint tokens

Let's mint some tokens to self:

Click Tokens tab under Extensions in left menu bar:

Then click Mint button:

And type 1000000000000000000000 as amount in Additional Supply input box:

At last click Mint Tokens button:

And comfirm this transaction in MetaMask:

We can see 1000000000000000000000 MDT are mint to my address.

4.2 Use explorer of thirdweb

Click Explorer tab under My Demo Token in left menu bar:

4.2.1 Call write function

Let's choose Transfer function as example:

Input the value of parameters, such as To and Amount:

Click Execute button:

Afer confirm this transaction in MetaMask:

4.2.2 Call read function

Click Read tab in right, and choose a function such as balanceOf:

Then input the value of parameter account:

At last click Run button, get the result: