Failing to test_deployment.js deploy to testnet
nazariyv opened this issue · comments
- There is a step missing in your guide: https://docs.bancor.network/developer-quick-start/deploying-bancor-contracts-for-testing
One needs to run node scripts/export.js to extract abis and bytecode from the json artifacts.
- Now when I run the test_deployment.js to deploy to kovan, I get this:
Enter gas-price or leave empty to use 4500000000:
contractRegistry deployed at 0x7011EE30ac0B8E02Ab60Aa6Ad5018003b58aD2b6
converterFactory deployed at 0x310106F48F47532097Ba12FF985ac070f46b9366
bancorFormula deployed at 0x1698BF55095A30FB99EFDa88B7eB64aA2Ef1a35e
bancorNetwork deployed at 0xe0a6f491868C75bdF684BF77E8fd5a88A5f6C753
conversionPathFinder deployed at 0xb2Cdd85265841c0939a1acf33F947C380E883751
converterUpgrader deployed at 0x88F380782D97423EdebD3CB785c6f0Fe5C08F4c7
converterRegistry deployed at 0x319f4Cc4FE9bb6e18A4b183A1dEe3F17A6D04e26
converterRegistryData deployed at 0x9fAFcf89E93694Ca205f21bD7Ae21D1d5e86FCC4
liquidTokenConverterFactory deployed at 0x758A3fF4697E9379AA8d43f34FaDCFd2a0862f30
liquidityPoolV1ConverterFactory deployed at 0xd17536b8B9854AC6192DCc7CF472E95361e3E838
standardPoolConverterFactory deployed at 0xd8eb549edea3F014c4da442046eA2c8fD680Fb5c
poolToken1 deployed at 0x982105fD6255E961a00413Ea3dB0d85A7f482453
poolToken2 deployed at 0x08F993f38C2e844399BEeCb150dbF75De4D3c568
liquidTokenConverter deployed at 0x290291A20151404C0EF287a12BE11aD0438D540C
liquidityPoolV1Converter deployed at 0xBaa2ce6530B788B13972F965784C0443dCfc5E6F
standardPoolConverter deployed at 0xc5182DF1c4421a0446365C2C69B4006ABd63bF81
phase 1 executed
phase 2 executed
phase 3 executed
phase 4 executed
phase 5 executed
phase 6 executed
phase 7 executed
phase 8 executed
phase 9 executed
phase 10 executed
phase 11 executed
erc20Token-XXX deployed at 0x020723B9Ce86cF35105A3fc975221B22f37465B0
erc20Token-YYY deployed at 0x48C10a95D470d4C03e4FdBEc630377B4d2B7444d
dsToken-BNT deployed at 0x4D5bb036f89D34a5433724804D32C952383865a4
phase 12 executed
dsToken-vBNT deployed at 0xd54fBa0dbf71ac439345f67a5DB2cED674f2f1A8
phase 13 executed
(node:11735) UnhandledPromiseRejectionWarning: Error: Returned values aren't valid, did it run Out of Gas? You might also see this error if you are not using the correct ABI for the contract you are retrieving data from, requesting data from a block number that does not exist, or querying a node which is not fully synced.
at ABICoder.decodeParameters (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-eth-abi/src/index.js:338:15)
at Contract._decodeMethodReturn (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-eth-contract/src/index.js:572:22)
at Method.outputFormatter (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-eth-contract/src/index.js:935:42)
at Method.formatOutput (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-core-method/src/index.js:169:54)
at sendTxCallback (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-core-method/src/index.js:653:33)
at onJsonrpcResult (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-core-requestmanager/src/index.js:179:9)
at XMLHttpRequest.request.onreadystatechange (/home/naz/git/bancor/contracts-solidity/node_modules/web3/node_modules/web3-providers-http/src/index.js:111:13)
at XMLHttpRequestEventTarget.dispatchEvent (/home/naz/git/bancor/contracts-solidity/node_modules/xhr2-cookies/dist/xml-http-request-event-target.js:34:22)
at XMLHttpRequest._setReadyState (/home/naz/git/bancor/contracts-solidity/node_modules/xhr2-cookies/dist/xml-http-request.js:208:14)
at XMLHttpRequest._onHttpResponseEnd (/home/naz/git/bancor/contracts-solidity/node_modules/xhr2-cookies/dist/xml-http-request.js:318:14)
at IncomingMessage.<anonymous> (/home/naz/git/bancor/contracts-solidity/node_modules/xhr2-cookies/dist/xml-http-request.js:289:61)
at IncomingMessage.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1241:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
(node:11735) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 176)
(node:11735) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Done in 241.44s.
thanks for tagging it, there's probably an issue there after some of the recent upgrades, we'll take a look
@nazariyv:
What is your initial configuration file, and what network are you running on?
Is there any chance that you've used the following combination:
- In the configuration file, the address of an already-deployed token on network X
- In the second parameter passed to the script, the address of a node on network Y
?
Bullets 1 and 2 are not two separate questions.
The question is whether or not you have used both of them as part of your configuration.
Another question, which you did not refer to, is what is your initial configuration file?.
Thanks
the example one defined in this repo, https://github.com/bancorprotocol/contracts-solidity/tree/master/solidity/utils, namely
{
"reserves": [
{
"type": 0,
"symbol": "XXX",
"decimals": 18,
"supply": "1829101"
},
{
"type": 0,
"symbol": "YYY",
"decimals": 18,
"supply": "3603801"
},
{
"type": 1,
"symbol": "BNT",
"decimals": 18,
"supply": "6914855"
},
{
"type": 1,
"symbol": "vBNT",
"decimals": 18,
"supply": "0"
},
{
"address": "0xBde8bB00A7eF67007A96945B3a3621177B615C44",
"optional": "this is the already-deployed WBTC token"
},
{
"address": "0x443Fd8D5766169416aE42B8E050fE9422f628419",
"optional": "this is the already-deployed BAT token"
},
{
"address": "0x20fE562d797A42Dcb3399062AE9546cd06f63280",
"optional": "this is the already-deployed LINK token"
}
],
"converters": [
{
"type": 3,
"symbol": "ETHBNT",
"decimals": 18,
"fee": "0.1%",
"reserves": [
{
"symbol": "ETH",
"weight": "50%",
"balance": "21"
},
{
"symbol": "BNT",
"weight": "50%",
"balance": "3092"
}
]
},
{
"type": 3,
"symbol": "XXXBNT",
"decimals": 18,
"fee": "0.1%",
"reserves": [
{
"symbol": "XXX",
"weight": "50%",
"balance": "582"
},
{
"symbol": "BNT",
"weight": "50%",
"balance": "2817"
}
]
},
{
"type": 1,
"symbol": "YYYBNT",
"decimals": 18,
"fee": "0.2%",
"reserves": [
{
"symbol": "YYY",
"weight": "40%",
"balance": "312"
},
{
"symbol": "BNT",
"weight": "60%",
"balance": "270"
}
]
},
{
"type": 0,
"symbol": "ZZZ",
"decimals": 18,
"fee": "0.3%",
"reserves": [
{
"symbol": "BNT",
"weight": "10%",
"balance": "920"
}
]
}
],
"liquidityProtectionParams": {
"minNetworkTokenLiquidityForMinting": "100",
"defaultNetworkTokenMintingLimit": "750",
"minProtectionDelay": 600,
"maxProtectionDelay": 3600,
"lockDuration": 60,
"converters": [
"ETHBNT",
"XXXBNT"
]
}
}
I see what you mean, then the answer to your question would be yes I think, if the above addresses are deployed on kovan
@nazariyv:
I initially asked you if there was any chance that you were using the following combination:
- In the configuration file, the address of an already-deployed token on network X
- In the second parameter passed to the script, the address of a node on network Y
The configuration file that you're using contains the addresses of 3 tokens deployed on ropsten, while you are running our deployment script on kovan:
{
"address": "0xBde8bB00A7eF67007A96945B3a3621177B615C44",
"optional": "this is the already-deployed WBTC token"
},
{
"address": "0x443Fd8D5766169416aE42B8E050fE9422f628419",
"optional": "this is the already-deployed BAT token"
},
{
"address": "0x20fE562d797A42Dcb3399062AE9546cd06f63280",
"optional": "this is the already-deployed LINK token"
}
So either run the deployment script on ropsten instead of kovan, or change these addresses to be of tokens deployed on kovan instead of ropsten, or simply get rid of that part in the configuration file.
thanks for the feedback, closing for now.
@barakman running into a new issue now
web3-shh package will be deprecated in version 1.3.5 and will no longer be supported.
web3-bzz package will be deprecated in version 1.3.5 and will no longer be supported.
Enter gas-price or leave empty to use 1115406561:
contractRegistry deployed at 0x1069Fe059B26F34c36af58480f80472f08D7A1d8
converterFactory deployed at 0xBBC96301b5E6fDe7AE9741F15502B56d3c0e1239
bancorFormula deployed at 0x365E01320B655591d21E1a6A3DF8fD2aDE320dB0
bancorNetwork deployed at 0xdc36d28D4B0Ea4dD99347F8a49b7B874Ac123a69
conversionPathFinder deployed at 0x9dA5eAed5EB770E3424DeD2AE42a20b95ac02a33
converterUpgrader deployed at 0x6Ec8f62c562bfd652607CB778C62EAE0b6C3A30b
converterRegistry deployed at 0x95f81828D140993CB8D8aF37b5F15986b88F4c33
converterRegistryData deployed at 0x483a9BfC2C9a71c13A45b48EF1D93421831896dF
liquidTokenConverterFactory deployed at 0xCD1236471882c732d89ea9a009EE1584720FBCF5
liquidityPoolV1ConverterFactory deployed at 0xF46fB393a2Ea91169F1d8C5CDa805bd144F19539
standardPoolConverterFactory deployed at 0xa275F642eA5c4549317493812FED6DF1e95A8c11
poolToken1 deployed at 0x75fb60601d151723D616298Ef702f31308e66B1C
poolToken2 deployed at 0xd6CD5929d9f6a8fC8BBe9d38526fa43F60c4ac63
liquidTokenConverter deployed at 0x4C2690dc806795297949a2D52F36B104fDfb8b17
liquidityPoolV1Converter deployed at 0x9a62FF9f20a7f050eAce256c7100dE9FBE7D03B2
standardPoolConverter deployed at 0xd5DB30BdEe857D01145451ebda02046d165C950A
phase 1 executed
phase 2 executed
phase 3 executed
phase 4 executed
phase 5 executed
phase 6 executed
phase 7 executed
phase 8 executed
phase 9 executed
phase 10 executed
phase 11 executed
dsToken-XXX deployed at 0x665432AC5F9511aDCc3ED048348473456B3982D5
phase 12 executed
dsToken-YYY deployed at 0xA9D104001e9ab358af6090dcbE5f3E564E24681B
phase 13 executed
dsToken-BNT deployed at 0x8D2e44e54ff89c255Bf5e1774cd56B46F6854c26
phase 14 executed
dsToken-vBNT deployed at 0x7011EE30ac0B8E02Ab60Aa6Ad5018003b58aD2b6
phase 15 executed
phase 16 executed
phase 17 executed
phase 18 executed
phase 19 executed
Returned error: err: insufficient funds for transfer (supplied gas 4010499)
Enter transaction-hash or leave empty to retry:
Returned error: err: insufficient funds for transfer (supplied gas 4010499)
Enter transaction-hash or leave empty to retry:
Returned error: err: insufficient funds for transfer (supplied gas 4010499)
Enter transaction-hash or leave empty to retry: ^C
what is this due to? thanks
It's due to insufficient amount of ether in your account.
that's strange because I had 4 ether in there during that error
could it be the insufficient amount of tokens as per the config? I am just using that default config above
No, the error insufficient funds for transfer is a web3.js builtin error, emitted when attempting to transfer ETH as part of the transaction.
Note that the first converter in your configuration file is:
{
"type": 3,
"symbol": "ETHBNT",
"decimals": 18,
"fee": "0.1%",
"reserves": [
{
"symbol": "ETH",
"weight": "50%",
"balance": "21"
},
{
"symbol": "BNT",
"weight": "50%",
"balance": "3092"
}
]
}
That by itself would require the script to transfer 21 ether from your account into the converter after creating it.
So a balance of 4 ether is obviously insufficient for running this script, and I haven't even accounted for the gas required for executing all the other transactions.