Questions about Algorand contracts, ASC

1

Hi!

I have the following use case (simplified for brevity):

  1. create a new fungible token FT1 as ASA, max. limit 1 million
  2. create nonfunible token NFT2 as ASA, max. limit 1 million
  3. sell FT1 for Algo
  4. FT1 can optionally be converted (by the owner) to NFT2, 1 FT1 = 1 NFT2, FT1 is “burned” during this process, this makes FT1 “rare”
  5. Algos from later FT1 sales give Algos to NFT2 owners, proportionally to their NFT2 amount owned

My questions:
Q1: How can FT1 be burned during step4? E.g. by using a group of transactions, with a ASC, where the first tx sends FT1 to an address like like BB…BBBB?
Q2: How can the Algos from the selling of FT1 be distributed among the CURRENT NFT2 owners, proportionally to their held NFT2 amount? For this, the following state information would be needed:
NTF2owner: address;
NFT2amount: int;

Waiting for your proposals… Thx.

2

Question: What do you mean when you say the second token is non-fungible?

Q1

Burning the tokens always consists in sending them to some address. There are two orthogonal points with burning:

  • If you want the block explorers to show the correct circulating supply of the tokens, the burnt tokens must be sent to the “reserve address” of the ASA.
  • If you want the burnt tokens not to be mintable again, you need the address to which you send them to be a stateless smart contract account that does not allow to mint the token again. Essentially the smart contract account must allow a single opt-in transaction and forbid all other transactions.

If you also want both, the reserve address must be set to this smart contract account.

If you want to be able to mint new tokens and also burn definitely some tokens, then you need to use a smart contract account as reserve and an application to control this smart contract account. (You can also get very fancy by using two ASAs.) Let me know if you want to know more about this.

Q2

This is a very interesting question. I am thinking of several solutions

Off-chain solution

One solution is a completely off-chain solution: you choose a round, use the indexer to compute the NFT2 balance of all NFT2 holders for this round and then send manually to all these NFT2 holders the correct amount of Algos.

Multiple ASA solutions

You have one new ASA NFT2_i each time a reward is distributed.
Then you can convert NFT2_i into NFT_{i+1} and get the reward according to your NFT2_i balance.
Redeemed NFT2_i are burnt.

Advanced escrow

Each address/user A has a personalized escrow account C_A created from some template.
The escrow account is controlled by a stateful application and distributes rewards in the same way as Algorand participation rewards are distributed.
Essentially, the escrow account requires any transaction to be grouped with a call to the stateful application App.
(See Bond Implementation - #7 by fabrice for details how to make them interact correctly).

NFT2 can also be held outside of escrow accounts but in that case they don’t receive the rewards from the FT1 sell.
App stores the current total amount T of tokens in escrow accounts as well as a global “reward level” working the same was as reward level for Algorand participation rewards: https://www.algorand.com/resources/blog/rewards-technical-overview

The operations would look like the following:

  • When depositing x NFT2 to C_A for the first time, 4 transactions are involved:
    1. A sends 1 Algo to C_A
    2. C_A opts in to NFT2
    3. A send x NFT2 to C_A
    4. C_A opts in to App that stores locally x and increase the total T. It also stores a reward level working the same way as reward level for Algorand participation rewards:
  • When depositing NFT2 to C_A after that the opt in to NFT2 and the funding of C_A are skipped, but transaction 3 and 4 are kept.
  • …

I can give more details if needed.