safeTransferFrom on ERC1155 contracts always sets the to address as the contract address

[acastle-optimist]

I'm trying to use Ethers to interact with an ERC1155 contract. I'm trying to initiate a transfer but the 'to' address is always ignored and instead in the receipt I see that the 'to' address is the contract address. This is killing me! Any idea why this is happening. I have tried multiple contracts including minting directly on opensea so it's not using a contract I wrote and it doesn't seem to make any difference.

My code is as follows:

const provider = new ethers.providers.JsonRpcProvider(
"https://polygon-mumbai.g.alchemy.com/xxxxxxxxxx"
);

const contract_address = "0x5e23D82D528244A31C1048f7513673DE5eB62cc7";

const ERC1155_ABI = [
"function name() view returns (string)",
"function symbol() view returns (string)",
"function balanceOf(address, uint256) public view returns (uint256)",
"function safeTransferFrom(address, address, uint256, uint256, bytes) public",
];

const contract = new ethers.Contract(contract_address, ERC1155_ABI, provider);

const wallet = new ethers.Wallet(
PRIVATE_KEY,
provider
);

const contractWithWallet = contract.connect(wallet);
try {
  const tx = await contractWithWallet.safeTransferFrom(
    "0x09D30d3cae12e5c3e3D076183e451d75a96Ce9Ea",
    "0x7b8B48aECc22c1828dC0F91Ba72DD39920061216",
    0,
    1,
    "0x00",
    { gasLimit: 100000 }
  );
  console.log("success: ", tx);
} catch (e) {
  console.log(e);
}

which returns the receipt:

success:  {
  type: 2,
  chainId: 80001,
  nonce: 19,
  maxPriorityFeePerGas: BigNumber { _hex: '0x59682f00', _isBigNumber: true },
  maxFeePerGas: BigNumber { _hex: '0x59682f16', _isBigNumber: true },
  gasPrice: null,
  gasLimit: BigNumber { _hex: '0x0186a0', _isBigNumber: true },
  to: '0x5e23D82D528244A31C1048f7513673DE5eB62cc7',
  value: BigNumber { _hex: '0x00', _isBigNumber: true },
  data: '0xf242432a00000000000000000000000009d30d3cae12e5c3e3d076183e451d75a96ce9ea0000000000000000000000007b8b48aecc22c1828dc0f91ba72dd399200612160000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000',
  accessList: [],
  hash: '0xdefccc9e1c1dfc952f0856399757784dd70fbe34153b2f1c12f7f019ba23e72d',
  v: 1,
  r: '0x1c5bd2e86f4f740372a7387b30058cd11beb403904f6d75e84203a7c3f8e1c77',
  s: '0x586fcc4f3f7b3925045eb3eb01d595833ab526e8ad37901d29c8889a53591151',
  from: '0x09D30d3cae12e5c3e3D076183e451d75a96Ce9Ea',
  confirmations: 0,
  wait: [Function (ano

Am I doing something wrong? I can't see an issue but it refuses to play ball! Thanks for any suggestions.

[ricmoo]

That's how Ethereal works. When you interact with a contract, you send the transaction to that contract, along with data that describes what to do. If you look in the data, you will see your to address.

[acastle-optimist]

Thanks for the reply. I get that I am interacting with the contract, I feel pretty stupid now - I was thinking the from and to addresses were the from and to addresses from the transfer function I was calling on the contract. :(. So how the heck do I find out why the transfer function keeps failing? Polygonscan just shows the transaction as failed (repeatedly). No info at all. Do you know how to troubleshoot that? I'm using an Openzepelin contract templatre and I didn't modify the transfer function at all. I tried adding await tx.wait() then logging it to see if there was error info after the tx got rejected that is not in the receipt but it just never returned.

[ricmoo]

No worries.

It depends entirely on what the contract emits on an error, whether it sends back. meaningful error or not, for example. Otherwise, short of getting into debugging tools, your best bet is to look at the source an try to figure out what conditions it could be expecting to be true aren't...

Debugging is seldom easy. ;)

[acastle-optimist]

That's why I'm tearing my hair out - the ABI is straight from the openzepelin docs. It just takes a from wallet address, a to wallet address and two ints, the token id and amount. Don't really see where that can go wrong! I have no idea where to begin troubleshooting that. :(

[acastle-optimist]

As far as my use of the Ethers library - could you confirm that I am using it as intended?

[ricmoo]

Looks fine to me. Usually its an issue with trying to send from an account that doesn't have enough tokens, or sending to a contract that hasn't enabled EIP-1155 receive functionality, etc...

[acastle-optimist]

Thanks for the help - in the end I found the issue, it was actually multiple issues. Kind of like an episode of House. :) But the key was adding tx.wait() to actually see the outcome of the transaction. It was also compounded by the fact that transfers were taking around 10 minutes on the testnet so I thought they had failed when in fact they were just stupidly slow. Again the tx.wait() made that clear. Blockchain dev is a new world for sure.