Hard user onboarding for asa project(s)

AlgoSDK
, , , ,
1

Hello Algorand Community,

I am having a problem trying to create an easy user onboarding infrastructure for an ASA project on Algorand.

PROBLEM: Trying to design and build an Algorand-based service for users without them being needed to have ALGOs to use dapps/products/services.
Somehow, for every interaction with an Algorand-based dapp, ALGOs are needed. While I understand that ALGO fees technically help prevent DDOS and commercially help with revenues for the Foundation, it is still hard to create a solution where users who are not crypto-native(nor tech-savvy) or users in countries where buying of crypto is legally troubling or unfeasible(due to per capita income, local fiat liquidity availability or simply consumer purchasing power) can still access services built on the network.

Technically, in a dapp on the network, if Alice wants to send 100 ASAs to Bob that she has earned or received from Claire, Alice needs to foot 0.001 ALGOs for general network fees.

My solution for this has been to create a logicsig that runs in the background of Alice’s 100 ASAs transaction to Bob whereby the logicsig receives the 100 ASAs and sends the 100 ASAs to Bob directly. Since the logicsig is rekeyed to my ALGO address, it covers the fees. However, there is a catch here, Alice still has to send the 100 ASAs to the logicsig’s address, which means she will still need to pay the 0.001 ALGOs. So this solution falls flat.

Humbly requesting for help from the Algorand dev community on a possible hack(solution) to make such a process successful, or maybe I missed sth and would be deeply grateful for a heads-up. Hopefully, the Algorand core devs would architect the chain’s technicals and economics to make it easier for an ASA project with the scenario I shared to easily do onboardings as it would make adoption for Algorand-based niche consumer projects easier and faster. Thank you

2

So every account on Algorand has to have a min balance of .1 algos and an additional .1 for every ASA class they own. So no matter what you do with the fees that will still be an issue. On the fee itself, you can always group with another transaction that pays the transaction fee.

1 Like
3

For the transaction that pays the fee, what are the parameters for it? So far, I can only see the assembling, and grouping process documented, but I cannot see where another transaction pays the fee for the other.

Another issue, is who will be the receiver of the algo fees for the transaction paying the fees if the transaction that needs algo fees paid is more than one?

4

Here is a detailed description of how fee pooling works:

Essentially the only thing that matters is that the sum of all the fees of all the transactions in a group cover the required fee.
So if you have a group of two transactions (tx1,tx2):

  • either both tx1 and tx2 fees are at least 0.001
  • or tx1 fee is at least 0.002 (and tx2 fee may be 0)
  • or tx2 fee is at least 0.002 (and tx1 fee may be 0)

(this is assuming no inner transactions)