You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the proof of concept only uses a single Ethereum JSON-RPC connector, and assumes that either side is operating on the same contract on the same network for testing purposes.
To be useful it needs to support multiple networks on both the client & coordinator server side.
I think this should be done via a config file, e.g.:
Other information that could be contained in a config file:
Token addresses, which network they're on
HTLC and other swap contract addresses
Approved contract code hashes
This also opens the possibility of using Infura or Etherscan to submit transactions, instead of a direct EthJsonRpc connection, as long as they both provide the same interface.
Will need to find a clean method for supporting the config file in the client & server, e.g. when creating a connection it will use an object factory from the config class.
The text was updated successfully, but these errors were encountered:
Currently the proof of concept only uses a single Ethereum JSON-RPC connector, and assumes that either side is operating on the same contract on the same network for testing purposes.
To be useful it needs to support multiple networks on both the client & coordinator server side.
I think this should be done via a config file, e.g.:
Other information that could be contained in a config file:
This also opens the possibility of using Infura or Etherscan to submit transactions, instead of a direct EthJsonRpc connection, as long as they both provide the same interface.
Will need to find a clean method for supporting the config file in the client & server, e.g. when creating a connection it will use an object factory from the config class.
The text was updated successfully, but these errors were encountered: