Function 'sendSignedTransaction' changes the value of the 'to' field from 'null' to '0x'

[barakman]

Attempting to deploy a contract:

let contract = new web3.eth.Contract(abi);
let transaction = contract.deploy({data: bin, arguments: args});
let options = {
    to  : transaction._parent._address, // this is null
    data: transaction.encodeABI(),
    gas : gas
};

async function signAndSendTransaction(options) {
    let signedTransaction  = await web3.eth.accounts.signTransaction(options, PRIVATE_KEY);
    let transactionReceipt = await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
    return transactionReceipt;
}

When the value of gas is too low, this function fails with base fee exceeds gas limit, which is fine.
However, in the process, it updates the options object, namely:

• It adds the fields chainId, gasPrice, nonce and value.
• It changes the value of the to field from null to "0x".

As a result of the latter, any further attempt to call this function with the options object results with:

Provided address "0x" is invalid, the capitalization checksum test failed, or its an indrect IBAN address which can't be converted.

This behavior is extremely undesired IMO (moreover, perhaps you should even consider not updating the options object altogether, but you should by the least avoid setting the to field to an illegal value).

Side note: I'm not sure if related to this problem, but the value of the (new) value field is also "0x".

Thanks

[Jason-Soo]

Hi, sorry just to clarify a part of your problem so you are having issues with your "to" field which is by default in ETH blockchain that 0x is a legit account that anyone who leaves the "to" empty will automatically send it to 0x (black hole). Therefore most of the contracts nowadays set
require (_to != 0x0);
to prevent this matter. Apologies if i got the question wrong

[nivida]

This does no longer happen all the given parameters will be deep cloned. The defined object options will no longer change his values and properties you can now just execute the method again with the same object. Because of this, I will close this issue. If I got you wrong please feel free to tag me in a comment here and explain me further details. I will reopen it if required.

[barakman]

@nivida : deep cloned implies that you got me just right :)

Starting from which version of web3.js will this fix be available?

Thanks

https://github.com/ethereum/web3.js/releases/tag/v1.0.0-beta.39, I suppose?

At least according to:

This release will fix the TypeScript type definitions and deep cloning of the contract arguments.

Well, v39 has at least one other problem that I've reported in the past (something about babel).

So I guess that v40 onward should do?

[barakman]

@nivida:

I'm sorry, but this doesn't seem to be resolved even on version 1.2.1 (which was released long after you had closed this issue).

I clearly see that function web3.eth.accounts.signTransaction changes the contents of the object passed to it as the first input parameter.

Specifically, I see that it changes the value of the to field from "" to "0x".

It is clearly visible in your code, at file web3-eth-accounts/src/index.js / line 167:

var transaction = tx;

There is obviously no deep cloning of the input object here, hence the lines that follow change it:

transaction.to = tx.to || '0x';
transaction.data = tx.data || '0x';
transaction.value = tx.value || '0x';
transaction.chainId = utils.numberToHex(tx.chainId);

Thanks

Update:

I am guessing that perhaps the deep-cloning was meant to be done via:

tx = helpers.formatters.inputCallFormatter(tx);
var transaction = tx;

If so, then here is how I have verified that this does not achieve the purpose:

var tx2 = tx;
tx = helpers.formatters.inputCallFormatter(tx);
var transaction = tx;
console.log('before:', tx2.to);
transaction.to = tx.to || '0x';
transaction.data = tx.data || '0x';
transaction.value = tx.value || '0x';
transaction.chainId = utils.numberToHex(tx.chainId);
console.log('after:', tx2.to);

The printout is:

before:
after: 0x

[nivida]

2.0-alpha.x does have this implemented. We will back-port it to the old architecture asap. (Have a look at the release notes of 1.2.0 and the referenced blog post)