Mergeable Tokens on Algorand

Mar 30, 2021
Yes, that group looks correct. The TEAL program will make use of the global transaction OpCode gtxn i field to access fields at global transaction index i.

Mar 30, 2021
I think the simpler solution is to have both assets replaced by the new asset ASA3. Your merged asset is just a brand new asset. You can keep history of merge in the note field of the transaction creating ASA3 for example or in the local state of the stateless smart contract account that you use t…

Mar 30, 2021
Who destroys the ASA is the Asset Manager, but the whole supply must be in the Asset Creator account:

@Supirogurafu in your system are both ASA1 and ASA2 consumed (destroyed), such that:

• Holder: A gives up ownership of ASA1 and ASA2 (assetSend transaction)
• ASA1 and ASA2 are destroyed (assetDestroy transaction)
• Contract mints new ASA3 (assetCreate transaction)
• Holder: A receives ASA3 (assetSend transaction)

Yes, the manager address must be able to destroy ASA1 and ASA2, so that logic will be in there. The logic needs to include the ability to opt-in to each ASA prior to receiving them. This will cause some limitations if you go beyond issuing ASA1000 as you would need some other method to observe the man…

Are you using the URL field? As a workaround, you could put it there or in the creation tx note field, but that is not readily accessible in a contract later. It would have to be passed as a parameter to the contract that does the combining. You could make a stateful contract track the risk of the AS…

if you used ASAs and tracked the additional properties in a stateful contract, you could guarantee that the additional properties are transferred appropriately with some custom logic similar to what we do in this example: Algorand Developer Portal

BTW if you wanted to do it completely in stateful take a look at this sample from Jason Paulos:

You may be able to do this with a combination of smart contracts and ASAs where the contract handles the merge. You would need to give more information on what you need to be sure. Another option is to build it all in a stateful smart contract where the data per user is stored in local storage.