xDai bridge contracts management

#1

xDai bridge contracts management

This article was moved from POA GitHub to the Forum

The article by Alexander Kolotov was moved from
https://github.com/poanetwork/wiki/blob/0fad39e5bdac44433f3a31d85b57c577e337e083/xDai/bridge-contracts-management.md
to the forum on 2019-01-21T23:00:00Z

Action flow

Bridge administrators can perform 4 groups of operations with the xDai bridge. All operations are performed by owners of the Multisignature Wallet which requires several accounts to confirm the operation transaction.

The addresses of the Multisignature Wallet:

  • the ETH Mainnet: 0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd, ABI, Etherscan
  • the xDai chain: 0x0d3726e5a9f37234d6b55216fc971d30f150a60f, ABI, Blockscout

Example action flow:

  1. One of the multisig wallet owner encodes the call of a method with a set of parameters (if any). For example, this can be done with the ABI Encoding Service.
  2. The encoded sequence of bytes is used to create a transaction for the multisig wallet contract. This is done with the submitTransaction method of the multisig wallet contract. The method raises the event Submission containing the index of the registered transaction. The index is shared with the other owners of the wallet.
  3. The rest of the owners confirm the transaction by invoking confirmTransaction from the multisig wallet contract. As soon as enough confirmations are received, the method encoded in step 1 is invoked automatically. This is important because adequate gas limits must be set for that transaction and set of confirmations sent by the wallet owner finalizing the operation.
  4. If the method is not invoked because the gas limit is exceeded, the owners can execute the confirmed transaction manually by sending executeTransaction.

The particular action flow will vary for different management operations. See details below.

Upgrade

There are two possible scenarios for how the bridge or validators contracts can be upgraded:

  • a security fix when only the contract implementation is changed
  • an improvement when the contract implementation upgrade requires initialization of storage values

Security upgrade

  1. Deploy a new implementation of the bridge or validators contract.
  2. Depending on the contract and the chain use one of the links below to get the current version of the contract implementation:
  • The bridge contract_ on the ETH Mainnet: Etherscan,
  • The validators contract_ on the ETH Mainnet: Etherscan
  • The bridge contract_ on the xDai chain: Blockscout
  • The validators contract_ on the xDai chain: Blockscout
  1. Use the upgradeTo method from EternalStorageProxy ABI, the address of the new implementation, and the incremented version number to encode the data for the transaction. Example of the data: 3ad06d160000000000000000000000000000000000000000000000000000000000000004000000000000000000000000f097137c7ec5e582b5704065f72ac5903d0b526d.
  2. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The data field must be filled with the bytes received from the previous step. The destination depends on the contract:
  • 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the security upgrade is made for the bridge contract on the ETH Mainnet.
  • 0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E if the security upgrade is made for the validators contract on the ETH Mainnet.
  • 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the security upgrade is made for the bridge contract on the xDai chain.
  • 0xb289f0e6fbdff8eee340498a56e1787b303f1b6d if the security upgrade is made for the validators contract on the xDai chain.
  1. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with the other multisig wallet owners.
  2. (for the rest of owners) Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). Set the gas limit to three times bigger than the gas estimator function suggests.

Improvement introduction

  1. Identify the method to call as part of the new implementation initialization. In the following steps we assume that the method’s name is upgradeFrom3to4 which takes no arguments.
  2. Use the method mentioned above from the new contract implementation code or ABI to encode the data to be passed to upgradeToAndCall method. Example of the data: 50d28adb.
  3. Deploy a new implementation of the bridge or validators contract.
  4. Depending on the contract and the chain, use one of the links below to get the current version of the contract implementation:
  • The bridge contract_ on the ETH Mainnet: Etherscan,
  • The validators contract_ on the ETH Mainnet: Etherscan
  • The bridge contract_ on the xDai chain: Blockscout
  • The validators contract_ on the xDai chain: Blockscout
  1. Use the upgradeToAndCall method from the EternalStorageProxy ABI, the address of the new implementation, and the incremented version number to encode the data for the transaction. Example of the data: 0xa9c45fcb0000000000000000000000000000000000000000000000000000000000000004000000000000000000000000692a70d2e424a56d2c6c27aa97d1a86395877b3a0000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000450d28adb00000000000000000000000000000000000000000000000000000000.
  2. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The data field must be filled with the bytes received on the previous step. The destination depends on the contract:
  • 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the security upgrade is made for the bridge contract on the ETH Mainnet.
  • 0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E if the security upgrade is made for the validators contract on the ETH Mainnet.
  • 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the security upgrade is made for the bridge contract on the xDai chain.
  • 0xb289f0e6fbdff8eee340498a56e1787b303f1b6d if the security upgrade is made for the validators contract on the xDai chain.
  1. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with other multisig wallet owners.
  2. (for the rest of owners) Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). Set the gas limit to four times bigger than the gas estimator suggests.

Configuration

A definition of all configuration parameters that can change the bridge behavior are available in the separate section below.
We describe the steps for changing the daily limit of the Bridge Home contract (0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6, deployed in the xDai chain). These steps can also be used on other parameters of this or another contract:

  1. Use the setDailyLimit method from HomeBridgeErcToNative ABI and a new daily limit (in this example the new limit is 50000 xDai coins) to encode the data for the transaction. Example of the data: b20d30a9000000000000000000000000000000000000000000000a968163f0a57b400000.
  2. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The destination must be 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6. The data field must be filled with the bytes received on the previous step.
  3. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with the other multisig wallet owners.
  4. (for the rest of owners) Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0x0d3726e5a9f37234d6b55216fc971d30f150a60f). Set the gas limit two times bigger than the gas estimator suggests.
  5. Since any modification of the daily limit on one side must be reflected on another side, as described below, steps 1 - 4 need to be executed on the ETH Mainnet. Use the setExecutionDailyLimit method from ForeignBridgeErcToNative ABI and the same daily limit used in step 1 to encode the data for the transaction. Example of the data: 3dd95d1b000000000000000000000000000000000000000000000a968163f0a57b400000.
  6. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the ETH Mainnet). The destination must be 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016. The data field must be filled with the bytes received on the previous step.
  7. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with the other multisig wallet owners.
  8. (for the rest of owners) Use NiftyWallet (or another tool that could build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd). Set the gas limit two times bigger than the gas estimator suggests.

Admin privileges management

Each admin account type has certain rights and permissions:

  1. Admin to manage the validators set - add and remove validators, and change the number of required confirmations.
  2. Admin to manage bridge parameters - adjust transaction limits, change the fallback gas price and finalization threshold.
  3. Upgradability admin - upgrade the bridge contract and the validators contract. This type of admin is very powerful, and is the only admin with permission to claim tokens sent to the bridge contract by mistake.

By default, the multisig wallet of the xDai bridge validators is associated with all three roles.

Change the admin to manage the validators set

  1. Use the transferOwnership method from BridgeValidators ABI and a new admin account to encode the data for the transaction. Example of the data: f2fde38b000000000000000000000000715e5837c903d0b52ec2b576d70406f095f72ac5.
  2. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The destination must be either 0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E if the new admin is for the validators contract on the ETH Mainnet side or 0xb289f0e6fbdff8eee340498a56e1787b303f1b6d if the new admin is for the contract on the xDai chain. The data field must be filled with the bytes received on the previous step.
  3. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with other multisig wallet owners.
  4. (for the rest of owners) Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). Set the gas limit two times bigger than the gas estimator suggests.

Change the admin to manage bridge parameters

  1. Use the transferOwnership method from ForeignBridgeErcToNative or HomeBridgeErcToNative ABI and a new admin account to encode the data for the transaction. Example of the data: f2fde38b000000000000000000000000715e5837c903d0b52ec2b576d70406f095f72ac5.
  2. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The destination must be either 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the new admin is for the bridge contract on the ETH Mainnet side or 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the new admin is for the contract on the xDai chain. The data field must be filled with the bytes received on the previous step.
  3. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step included into a block and share it with other multisig wallet owners.
  4. (for the rest of owners) Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). Set the gas limit two times bigger than the gas estimator suggests.

Change the upgradability admin

  1. Use the transferProxyOwnership method from EternalStorageProxy ABI and a new admin account to encode the data for the transaction. Example of the data: ff1739cae000000000000000000000000715e5837c903d0b52ec2b576d70406f095f72ac5.
  2. Use NiftyWallet (or another tool that could build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The data field must be filled with the bytes received on the previous step. The destination depends on the contract:
  • 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the upgradability admin is being changed for the bridge contract on the ETH Mainnet.
  • 0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E if the upgradability admin is being changed for the validators contract on the ETH Mainnet.
  • 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the upgradability admin is being changed for the bridge contract on the xDai chain.
  • 0xb289f0e6fbdff8eee340498a56e1787b303f1b6d if the upgradability admin is being changed for the validators contract on the xDai chain.
  1. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step ia included into a block and share it with other multisig wallet owners.
  2. (for the rest of owners) Use NiftyWallet (or another tool that could build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). Set the gas limit two times bigger than the gas estimator suggests.

ERC20 tokens release

  1. Use the claimTokens method from ForeignBridgeErcToNative or HomeBridgeErcToNative ABI, an address of an ERC20 token contract, and receiver of the tokens to encode the data for the transaction. Example of the data: 69ffa08a0000000000000000000000000dcd2f752394c41875e259e00bb44fd505297caf000000000000000000000000583031d1113ad414f02576bd6afabfb302140225.
  2. Use NiftyWallet (or another tool that can build transactions based on the contract source code or ABI) to invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). The destination must be either 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the token contract is on the ETH Mainnet or 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the token contract is on the xDai chain. The data field must be filled with the bytes received on the previous step.
  3. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step included into a block and share it with other multisig wallet owners.
  4. (for the rest of owners) Use NiftyWallet (or another tool that could build transactions based on the contract source code or ABI) to invoke confirmTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on the xDai chain). Set the gas limit three times bigger than the gas estimator suggests.

The xDai bridge management API

The following management interfaces are available for the validators of the xDai bridge:

Upgrade the bridge contracts implementation:

The contract on the ETH Mainnet:

Address Explorers ABI
0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 Blockscout Etherscan
Method Description
upgradeTo Upgrade the current implementation of the bridge contract to a new one. This method expects an integer which specifies the next implementation version and an Ethereum address where the next implementation was deployed.
upgradeToAndCall Upgrade the current implementation of the bridge contract to a new one and automatically call a method in the new implementation. The method expects an integer specifying the next implementation version, an Ethereum address where the next implementation was deployed, and a set of bytes containing the selector of the method with the parameters ABI-encoded. The encoded method will be called on behalf of the proxy contract.
transferProxyOwnership Changes the upgrade admin account whose operations are allowed to upgrade the bridge contract implementation. The method expects a new Ethereum address.

The contract on the xDai chain:

Address Explorers ABI
0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 Blockscout EternalStorageProxy ABI
Method Description
upgradeTo Upgrade the current implementation of the bridge contract to a new one. The method expects an integer specifying the next implementation version and an Ethereum address where the next implementation was deployed.
upgradeToAndCall Upgrade the current implementation of the bridge contract to a new one and automatically call a method in the new implementation. The method expects an integer specifying the next implementation version, an Ethereum address where the next implementation was deployed, and a set of bytes containing the selector of the method with the parameters ABI-encoded. The encoded method will be called on behalf of the proxy contract.
transferProxyOwnership Changes the upgrade admin account whose operations are allowed to upgrade the bridge contract implementation. The method expects a new Ethereum address.

Upgrade the validators contracts implementation:

The contract on the ETH Mainnet:

Address Explorers ABI
0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E Blockscout, Etherscan EternalStorageProxy ABI
Method Description
upgradeTo Upgrade the current implementation of the bridge contract to a new one. The method expects an integer specifying the next implementation version and an Ethereum address where the next implementation was deployed.
upgradeToAndCall Upgrade the current implementation of the bridge contract to a new one and automatically calls a method in the new implementation. The method expects an integer specifying the next implementation version, an Ethereum address where the next implementation was deployed, and a set of bytes containing the selector of the method with the parameters ABI-encoded. The encoded method will be called on behalf of the proxy contract.
transferProxyOwnership Changes the upgrade admin account whose operations are allowed to upgrade the validators contract implementation. The method expects a new Ethereum address.

The contract on the xDai chain:

Address Explorers ABI
0xb289f0e6fbdff8eee340498a56e1787b303f1b6d Blockscout EternalStorageProxy ABI
Method Description
`upgradeTo Upgrade the current implementation of the bridge contract to a new one. The method expects an integer specifying the next implementation version and an Ethereum address where the next implementation is deployed.
upgradeToAndCall Upgrade the current implementation of the bridge contract to a new one and automatically call a method in the new implementation. The method expects an integer numbering the next implementation version, an Ethereum address where the next implementation is deployed, and a set of bytes containing the selector of the method with the parameters ABI-encoded. The encoded method will be called on behalf of the proxy contract.
transferProxyOwnership Changes the upgrade admin account whose operations are allowed to upgrade the validators contract implementation. The method expects a new Ethereum address.

Management of the bridge validators list and the number of required signatures:

The contract on the ETH Mainnet:

Address Explorers ABI
0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E Blockscout, Etherscan BridgeValidators ABI
Method Description
addValidator Adds a new validator. The method expects the Ethereum address of the new validator. We recommend stopping all bridge instances prior to adding the new validator. The corresponding validator must also be added to the other side of the bridge.
removeValidator Removes a validator. The method expects the address of the validator that needs to be removed. The operation will only be successful if the number of remaining validators remains greater or equal to the number of required signatures. We recommend stopping all bridge instances prior to removing a validator. The corresponding validator must also be removed on the other side of the bridge.
setRequiredSignatures Sets the number of required signatures (the number of validators’ confirmations). The method expects an integer. We recommend stopping all bridge instances prior to setting signatures. The number of required signatures must also be updated to this value on the other side of the bridge.
transferOwnership Changes the management account whose operations are allowed to change parameters of the validators contract. The method expects a new Ethereum address.

The contract on the xDai chain:

Address Explorers ABI
0xb289f0e6fbdff8eee340498a56e1787b303f1b6d Blockscout BridgeValidators ABI
Method Description
addValidator Adds a new validator. The method expects an Ethereum address of the new validator. We recommend stopping all bridge instances prior to adding the new validator. The corresponding validator must also be added on the other side of the bridge.
removeValidator Removes a validator. The method expects the address of the validator that needs to be removed. The operation will only be successful if the number of remaining validators remains greater or equal to the number of required signatures. We recommend stopping all bridge instances prior to removing a validator. The corresponding validator must also be removed on the other side of the bridge.
setRequiredSignatures Sets the number of required signatures (the number of validators’ confirmations). The method expects an integer. We recommend stopping all bridge instances prior to setting signatures. The number of required signatures must also be updated to this value on the other side of the bridge.
transferOwnership Changes the management account whose operations are allowed to change parameters of the validators contract. The method expects a new Ethereum address.

Management of the bridge parameters:

The contract on the ETH Mainnet:

Address Explorers ABI
0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 Blockscout, Etherscan ForeignBridgeErcToNative ABI
Method Description
setExecutionDailyLimit Sets the daily limit on the amount of tokens that the bridge validators can request to unlock through confirmations. The method expects an integer - the amount of tokens. The value must be the same as the daily limit set on the other side of the bridge. This parameter is needed to secure the bridge from malicious validator actions.
setExecutionMaxPerTx Sets the maximum number of tokens that bridge validators can request to unlock in one transaction. The method expects an integer - the amount of tokens. The value must be the same as the daily limit set on the other side of the bridge. This parameter is needed to secure the bridge from malicious validator actions.
setGasPrice Sets the gas price used by the bridge instance to send transactions to the ETH Mainnet if the gas price oracle is not accessible. The method expects an integer - the gas price in Wei.
setRequiredBlockConfirmations Sets the finalization threshold - the number of blocks after which the bridge instance considers the chain finalized and sends the confirmation for the corresponding transfer request. The method expects an integer.
transferOwnership Changes the management account whose operations are allowed to change parameters of the bridge contract. The method expects a new Ethereum address.
claimTokens Allows the user to transfer ether or ERC20 tokens sent to the bridge address by mistake. The method expects the Ethereum address of an ERC20 token contract and the Ethereum address of a token recipient. If ether is sent instead of tokens the token address account must be 0. The method will fail if the token address is the same as the address of the token contract used for bridge operations. Only the account that is able to upgrade the bridge contracts can call this method.

The contract on the xDai chain:

Address Explorers ABI
0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 Blockscout HomeBridgeErcToNative ABI
Method Description
setDailyLimit Sets the daily limit of xDai coins that can be transferred to the ETH Mainnet by the xDai chain users. The method expects an integer - the amount of coins in Wei. If this parameter is changed ExecutionDailyLimit must be set to the same value on the ETH Mainnet side.
setMaxPerTx Sets the maximum amount of xDai coins that can be transferred to the ETH Mainnet by a chain user in one transaction. The method expects an integer - the amount of coins in Wei. If this parameter is changed ExecutionMaxPerTx must be set to the same value on the ETH Mainnet side.
setMinPerTx Sets the minimum amount of xDai coins that can be transferred to the ETH Mainnet by a chain user in one transaction. The method expects an integer - the amount of coins in Wei. This parameter is needed to secure that the validators account is not dried out by transactions whose values are less than network fees.
setExecutionDailyLimit Sets the daily limit of xDai coins that can be requested by the bridge validators to be minted through confirmations. The method expects an integer - the amount of tokens. This parameter is needed to secure the bridge from malicious validator actions.
setExecutionMaxPerTx Sets the maximum amount of xDai coins that can be requested by the bridge validators to be minted in one transaction. The method expects an integer - the amount of tokens. This parameter is needed to secure the bridge from malicious validator actions.
setRequiredBlockConfirmations Sets the finalization threshold - the number of blocks after which the bridge instance considers the chain finalized and sends the confirmation for the corresponding transfer request. The method expects an integer.
transferOwnership Changes the management account whose operations are allowed to change parameters of the bridge contract. The method expects a new Ethereum address.
claimTokens Allows the user to transfer xDai coins or ERC20 tokens sent to the bridge address by mistake. The method expects the Ethereum address of an ERC20 token contract and the Ethereum address of a token recipient. If ether should be sent instead of tokens the token address account must be 0. The method can only be called from the admin account able to upgrade bridge contracts.

Usage NiftyWallet for the xDai bridge management

Starting from version 4.10, NiftyWallet can invoke methods of the contracts by taking ABIs either from the verified contracts code on a block explorer or from the JSON data entered manually.

An example how to use the new functionality is available here

5 Likes
TokenBridge roles: Administrators, Validators and Users
Current xDai Validators: Add a new validator to the bridge [ BRIDGE VALIDATORS]