search

pinknetworkx / atomicassets-contract

Smart Contract of the AtomicAssets standard.
MIT License
149 stars 88 forks source link

Fix where Asset in RAM originally owned by "owner1" is minted for "owner2" and then fails on transfer to "owner3" #38

Closed dallasjohnson closed 3 years ago

dallasjohnson commented 3 years ago

This was causing a missing auth of "owner1" due to ram-payer issue.

I have not investigated deeply but changing the RAM to "from" as in the source change made it work immediately. If it's not a row size issue perhaps it's a secondary index increase issue. (or perhaps I was just using the contracts wrong. :) )

jona-wilmsmann commented 3 years ago

This is likely failing for you because the network you tested it on doesn't have the RAM_RESTRICTIONS protocol upgrade enabled. Transfers need this to work.

Not having the users pay for the RAM of an asset when transferring it was a key design principle when designing AtomicAssets. Instead, the RAM is paid by the minter of the NFT (which is then stored in the ram_payer attribute of the asset), and on transferring the NFT, it is still paid by this ram_payer. The row is first deleted from the "from" asset table and then emplaced into the "to" asset table, and the RAM delta is 0.

dallasjohnson commented 3 years ago

Thanks for the response @jona-wilmsmann This is very helpful for me. I was running locally with Docker and had not realised RAM_RESTRICTIONS was not being set. I'll look into that further.