Mergeable Tokens on Algorand

Supirogurafu · March 23, 2021, 12:13pm

I’m currently looking into evaluating different smart contract platforms to implement mergeable tokens for an insurance crowd sourcing use case. These tokens have a few numerical properties, foremost value and risk. Value behaves similar to a fungible ASA. There are two dissimilarities though:

Exactly 2 mergeable tokens can be combined, producing a single output mergeable token
The output risk value is the average of the two input risk values

What is a good starting place to implement this in TEAL? I think I have a rough idea of how to approach this in Solidity but I am completely new to Algorand so any pointers are much appreciated.

Thank you

JasonW · March 23, 2021, 12:56pm

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. The contract could handle extra properties and doing the combine operation. The only issue with using a stateful smart contract is the default wallets don’t show these as ASAs currently when listing balances. The stateful smart contract documentation is here: Algorand Developer Docs
You also may want to watch this video to get started with writing smart contracts: Algorand Partner Training | Overview of Stateful and Stateless Smart Contracts - YouTube

Supirogurafu · March 23, 2021, 5:23pm

Thank you, Jason. Yes, it would be excellent to describe these as non-fungible ASA. However, I’m unclear how to express the additional data in an ASA:

      ┌────────────────────────┐┌ ─ ─ ─ ─ ─ ─ ─ ─ ─  ┌────────────────────────┐┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ 
      │          ASA1          │ Additional Values │ │          ASA2          │ Additional Values │
      │       Holder: A        ││Risk: 80%           │       Holder: A        ││Risk: 20%          
      │                        │ ...               │ │                        │ ...               │
      └────────────────────────┘└ ─ ─ ─ ─ ─ ─ ─ ─ ─  └────────────────────────┘└ ─ ─ ─ ─ ─ ─ ─ ─ ─ 
                   │                                              │                                
                   └───────────────────────┬──────────────────────┘                                
                                           │                                                       
                                           ▼                                                       
                              ┌────────────────────────┐                                           
                              │                        │                                           
                              │        Contract        │                                           
                              │                        │                                           
                              └────────────────────────┘                                           
                                           │                                                       
                                           ▼                                                       
                              ┌────────────────────────┐┌ ─ ─ ─ ─ ─ ─ ─ ─ ─                        
                              │          ASA3          │ Additional Values │                       
                              │       Holder: A        ││Risk: 50%                                 
                              │                        │ ...               │                       
                              └────────────────────────┘└ ─ ─ ─ ─ ─ ─ ─ ─ ─

JasonW · March 23, 2021, 6:50pm

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 ASA as a local state variable. You could store the NFT id and the risk in local storage. As another question. How many of these NFTs will you have?

JasonW · March 23, 2021, 6:52pm

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

JasonW · March 23, 2021, 7:10pm

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

github.com

algorand/pyteal/blob/master/examples/application/asset.py

# This example is provided for informational purposes only and has not been audited for security.

from pyteal import *

def approval_program():
    on_creation = Seq([
        Assert(Txn.application_args.length() == Int(1)),
        App.globalPut(Bytes("total supply"), Btoi(Txn.application_args[0])),
        App.globalPut(Bytes("reserve"), Btoi(Txn.application_args[0])),
        App.localPut(Int(0), Bytes("admin"), Int(1)),
        App.localPut(Int(0), Bytes("balance"), Int(0)),
        Return(Int(1))
    ])

    is_admin = App.localGet(Int(0), Bytes("admin"))

    on_closeout = Seq([
        App.globalPut(
            Bytes("reserve"),
            App.globalGet(Bytes("reserve")) + App.localGet(Int(0), Bytes("balance"))

This file has been truncated. show original

Supirogurafu · March 23, 2021, 7:38pm

Excellent points, thanks Jason. I pondered (ab)using URL or tx note but it felt too much of a hack (I haven’t even gotten as far as understanding whether these would be accessible from a contract). I think there will be roughly 500 NFT to begin with, all with bespoke risk parameters and a handful of other bespoke parameters.

If I understand your examples correctly, the “Assets and Custom Transfer Logic” use ASA, therefore, at least for regular transfers of the NFT, users could use standard wallet functionality (which is a plus), even though for merging the NFT they would need lower level access. Whereas the “asset.py” approach is completely bespoke and wouldn’t be supported by any standard wallet.

ryanRfox · March 23, 2021, 8:42pm

@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)

Supirogurafu · March 23, 2021, 8:53pm

Yes, you’re describing my intention correctly, @ryanRfox. Abstracting from the very helpful tutorial on Assets and Custom Transfer Logic I would assume the contract would need to be the manager address so that the two input assets would be destroyed and the output asset would be generated. Presumably in that contract I could write the “risk” parameter to global/local state.

ryanRfox · March 23, 2021, 9:13pm

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 optin 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 manager of ASA9999 destroyed it and also ASA1 was destroyed.

I have a similar combine/destroy/reissue ASA system I’m designing. I’m using the metaDataHash and URL fields in non-standard ways to store data accessible to program logic. You may consider using these fields to store your risk value.

Supirogurafu · March 29, 2021, 7:42pm

This is very helpful, @ryanRfox. Thank you. I think I can probably work with the url field. However, I’m currently stuck trying to understand how to approach the merging of the assets, meta data aside. I.e. how do I ensure that the contract owns both expected input assets? Ideally I want to create a transaction which moves both assets at the same time. But this does not seem to be possible?

fabrice · March 30, 2021, 12:59pm

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 to create ASA3.

~~Note: only the creator can destroy assets, not the managers~~

Edit: The above note is indeed incorrect.

cusma · March 30, 2021, 9:26am

Who destory the ASA is the Asset Manager, but the whole supply must be in the Asset Creator account:

Supirogurafu · March 30, 2021, 12:15pm

Understood, Fabrice. This is what I was hoping to do. However, even the mechanics of this basic use case are unclear to me: How does the smart contract that issues ASA3 register that ASA1 and ASA2 have been sent to it. Would this be a transaction group like that?

┌──────────────────────────────┐
│group1                        │
│┌────────────────────────────┐│
││tx1 (AssetTransfer ASA1)    ││
│├────────────────────────────┤│
││tx2 (AssetTransfer ASA2)    ││
│├────────────────────────────┤│
││tx3 (AppCall)               ││
│└────────────────────────────┘│
└──────────────────────────────┘

Is this about correct? If so, how would I evaluate tx1 and tx2 from tx3?

ryanRfox · March 30, 2021, 12:41pm

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.