If you use for signing transactions for your , you would have noticed that, you could not find any trace about the transaction against the contract if you check on Etherscan.io. This is because Etherscan for Rinkeby does not provide information about internal transactions. While we were developing our decentralised skill verification platform at , we face this problem and thought it would be useful to document about this as this would be useful to fellow developers. In this article, I’m trying to provide some details about journey of a transaction if someone use uPort to sign a transaction and possible way to get details of internal transactions. uPort smart contract Diwala Important point to remember is, when you use uPort for identity management, your private key is stored in your mobile device and it would never be exposed to outside. Hence, any transaction to the blockchain should go through your mobile device. This may not directly relevant to this article, but it immensely help when you design systems using uPort. Journey of a transaction with uPort Usually a transaction get formulated inside a DApp. Then ether through a QR Code or via deep links the transaction would transfer into the uPort app in your device. DApp: Use the private key inside uPort app to sign the transaction and send it to TxRelay contract. uPort App: Receive transaction from uPort app and this is the transaction that is visible to you if you use the transaction hash returned from uPort app. Once received as name suggest, TxRelay relay the message to MetaIdetityManager smart contract. TxRelay: This contract provide means to send transaction without sender owning any ether. This contract finally forward the transaction to its final destination, which is your custom contract that you wanted to invoke at first place. MetaIdentityManager: View data sent to a Smart Contract Once a transaction is submitted (without uPort) and it successfully hit the destination in network, it is possible to pull all the data related to that transaction by calling Web3.js method and decode its data parameter using a library like But if you try this with the transaction hash you get after submitting a transaction via uPort, you would not see the data you submitted to your target smart contract’s function. web3.eth.getTransaction abi-decoder . Reason for this is, behind the scenes, the uPort app does not send the transaction directly to your contract but it routed via and contracts. TxRelay MetaIdentityManager So to view actual data sent to your contract by signing with uPort, following steps needed to be followed. Pull the transaction using by providing the transaction hash web3.eth.getTransaction Decode data using with the contract’s ABI abi-decoder TxRelay Value of the data attribute received from step 2 , should be input to the but this time with the ABI of the abi-decoder MetaIdentityManager And finally, value of data attribute received from step 3 should be input to the but this time with the ABI of the abi-decoder target contract Summary Once transaction signed from uPort app it traverse through multiple contracts before hit the target contract. So the data you get using transaction hash should be recursively decoded using relevant smart contract ABIs to liberate the data to the target contract. You could try this out at or use the for developments. You could find a more generalised module done by Snorre where you could adopt this library to view internal transactions of any smart contract. uPort Message Decoder simple node module _So we have been playing around with uPort for our platform and found that the support for internal transactions on the…_medium.com uPort Internal Transactions Resources Reusable library ( , , ) GitHub NPM Sample Online tool (Rinkeby) contract and ABI from Etherscan MetaIdentityManager (Rinkeby) contract TxRelay and ABI from Etherscan ABI-Decoder library uPort Project uPort white paper

Ethereum

ConsenSys

Dapp

uPort Transactions

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@chim

RELATED STORIES