I believe the /api/contracts/code API endpoint should return actual source code, not just bytecode and ABI, if the source has been verified. This would be consistent with the Etherscan API (which has been forked for so many other blockchains).
I am a smart contract security researcher, currently studying upgradeable proxies across 9 different blockchains. Part of our workflow involves querying block explorer APIs to get the implementation address for each proxy we identify, and then making a second query to download the implementation source code, which we then feed into the static analysis tool Slither along with the proxy's code. Because Slither works at the source code level, fetching the ABI and bytecode for the implementation is not sufficient for our needs.
I do appreciate that the /api/contract API does return the is_proxy, proxy_implementation and old_proxy_implementation information. But with no way to fetch the implementation source code via an API call, this is not nearly as useful as the equivalent endpoints for Etherscan.
Not to mention, I can't even scrape the source code easily from the https://tronscan.io/#/contract/T...y9/code page because of the way the "contract codes" section displays only one source file at a time (whereas Etherscan stacks them all on the page in separate text areas).
Hello,
I believe the
/api/contracts/code
API endpoint should return actual source code, not just bytecode and ABI, if the source has been verified. This would be consistent with the Etherscan API (which has been forked for so many other blockchains).I am a smart contract security researcher, currently studying upgradeable proxies across 9 different blockchains. Part of our workflow involves querying block explorer APIs to get the implementation address for each proxy we identify, and then making a second query to download the implementation source code, which we then feed into the static analysis tool Slither along with the proxy's code. Because Slither works at the source code level, fetching the ABI and bytecode for the implementation is not sufficient for our needs.
I do appreciate that the
/api/contract
API does return theis_proxy
,proxy_implementation
andold_proxy_implementation
information. But with no way to fetch the implementation source code via an API call, this is not nearly as useful as the equivalent endpoints for Etherscan.Not to mention, I can't even scrape the source code easily from the
https://tronscan.io/#/contract/T...y9/code
page because of the way the "contract codes" section displays only one source file at a time (whereas Etherscan stacks them all on the page in separate text areas).