Sender mixup during `mint` operation

[skenaja]

There were simultaneous contract calls from 2 separate Hicetnunc users that ended up next to each other in block 1516913 in RPC positions 3/20/0 & 3/21/0. They were both mint_OBJKT calls to KT1Hkg5qeNhfwpKW4fXvq7HGZB9z2EnmCCA9.

https://tzstats.com/oomznvokNKX6xWiQhUfm1XborokPEmvNFBkkkXBdpVMw2E6qSoX https://tzstats.com/ooPbTzYuGM8RoSGPCjAV8u4LCwckQr2yvPJdwxRez1pczKK3bzu

Hicetnunc uses Taquito SDK to interact with users' wallets, with mainnet.smartpy.io as the RPC entrypoint.

Both users reported that they had apparently minted tokens that contain the metadata from the other user, so it looks like the sender wallet address parameter from one transaction was somehow associated with the other transaction's parameters (amount, metadata, royalties) & vice-versa.

Could this possibly this be a data contention/corruption issue within the RPC node?

This may also have happened to another user in the same block, and I'm trying to obtain further details. I've heard a few sporadic reports about this before, but haven't had the full details to be able to try to track down the issue.

As this is possibly an issue with the RPC node's tezos client, I've raised the above on tezos stackexchange to see if I can get further information; https://tezos.stackexchange.com/questions/3536/contract-call-sender-mix-up-what-happened

---

Details from: https://discord.com/channels/759930487946215444/812076819129827358/854708848895328266

Expected:

• 13401's params apart from address should be associated with tz1ajd,
• 13402's params should be associated with tz1Nxu

Actual: ooPbTzYuGM8RoSGPCjAV8u4LCwckQr2yvPJdwxRez1pczKK3bzu objkt id 134041 address: tz1NxuUYdwWbFQbSK8GxzEKHDHM9qcFKv8BY amount: nat 12 metadata: bytes ipfs://QmSeaJARkid5qePb1gdkPwuuLt5c6846GyvoYmdDsT3xhx royalties: nat 200

oomznvokNKX6xWiQhUfm1XborokPEmvNFBkkkXBdpVMw2E6qSoX objkt id: 134042 address tz1ajdBod8APKLCbwk1TWz93a9nYGmemnLK7 amount: nat 1 metadata: bytes ipfs://QmPL9jEETEom1HpzyuWtGwquH4QxogK35ey34nA1goffK3 royalties: nat 150

[skenaja]

There was a similar problem mint (obj#140310 ooU4dzsX9TiAAko3u1qC21joq4iMHtP6KCupgkhvTcVa2PdxVh1). Looks like it happened in a block that got orphaned/re-orged, so it ended up correct in the end... https://tzstats.com/BLN4zkwj71ec83G9dXXWgZJwyDuULAVkQiVBunwFJ7aTqiVwTbZ relevant info:

source: tz2RQP3GBNhZgPeUk3Wnj2aGZsgNofufAo9Q
ooU4dzsX9TiAAko3u1qC21joq4iMHtP6KCupgkhvTcVa2PdxVh1
140310
amount: 10000
metadata: bytes 697066733a2f2f516d556933347967716b714d3436676a70537a564d7637737343724e326a795377634b3453623941644a46625675
ipfs://QmUi34ygqkqM46gjpSzVMv7ssCrN2jySwcK4Sb9AdJFbVu