Is there a way to deduct a small percentage of fees to me when users use my service when they do a transactions?
I’m guessing this can only be done from TEAL?
It depends what you mean by “service”.
If the service is a stateful smart contract, aka an application, then you need to add logic to the stateful smart contract requiring that any call to the smart contract is grouped (via an atomic transfer) with a payment to you.
If the service is an asset ASA, then you can freeze the ASA, and require to use the ASAs to be transferred using the clawback address (making the clawback address a stateless TEAL smart contract requiring that a call is grouped with a payment to you).
If your service is something else, it really depends on what it is exactly.
2 Likes
Very helpful. Thank you.
@toad as @fabrice suggested if you are trying to model some sort of “royalty” on ASA you may want to take a look at this solution in which I showed how you can use Stateful/Stateless ASC1 to embed royalties into ASAs.
1 Like
@cusma thanks. Yeah I checked that out.
What if I wanted an extra one time fee for ASA that’s not royalty, while royalty is used by the creator? Meaning two types of fees in one, with one being royalty and the other is one time.
It seems like it’s only possible to do it separately. Use TEAL then ASA?
What kind of users would pay the “one-time fee” and to whom?
To the creator. I understand anyone can easily create on their own via the algo wallet and taking fees probably doesn’t sound economical for the creator but we also have other things attached and may be more valuable for the service.
You may adopt different strategies to do that, not necessarily using TEAL.
Since, as you said, anyone would be able in principle to create any ASA they like, one think you may want to ensure is that “legit ASAs”, for the purposes of your application, are just those one either:
-
Created by a [2/2] MultiSignature account, composed by the Issuer to be paid once for the ASA issuance and the account of the User that requires those ASA. This approach let you collect the one time fee and scale up against the 1000 ASA per account limit.
-
Created through an Atomic Transfer that include the ASA create transaction, signed by the Issuer, and the payment from the User to the Issuer.
Both those approaches require that your application knows how to differentiate between “legit ASAs” and “fake ASAs” based on client-side checks.
A more decentralised approach would involve TEAL as a mean of ASA create approval on chain, to enforce directly process on ASA creation. You can find one example of this approach here.
Yeah I actually thought about the first scenario and was actually doing that at first, then checked some eth contracts to see what people are up to, it seems to be all coming in from creator address. I guess I didn’t want to throw off any “unconventional” situation.
Ok, I’ll try out the other scenarios. Thank you guys! What a helpful community!!
Hello,
Trying to deeply understand this solution, specifically the clawback address implementation.
So, basically, say Fabrice wanted to transfer 100 Fungible ASAs to Cusma, we would construct this transaction using the [1]algosdk.makeAssetTxn(sender=Fabrice.address, receiver=Cusma.address, amt=100); . The developer, say Toad, wants to impose fees in the ASA as well, say 0.01 ASAs are needed to effect a successful Fabrice → Cusma transfer of ASAs. By your explanation @fabrice , you say that the developer has to freeze ASAs to freeze.addr, and also get clawback.addr.
One question is, how would the transaction that is supposed to be grouped with transaction[1] to impose the 0.01 ASAs on Fabrice be constructed?
Going by your explanation( @fabrice ) [2] algosdk.makeAssetTxn(sender=clawback.address, receiver=toadthedev.address amt=0.01 ASAs) - Is that correct?
And if the above, transaction[2] is correct? Then how are these fees(0.001ASAs) deducted from Fabrice.addr or Fabrice’s transaction of 100 ASAs to Cusma?
You cannot do it in a single makeAssetTxn transaction.
The clawback address just allows to bypass the freeze (and require an additional parameter asset_sender that is the actual sender). It does not take any cut.
You need either to use smart signatures (for clawback address) + group of transactions like in AlgoRealm, a NFT Royalty Game | Algorand Developer Portal.
Nowadays with inner transactions, this can be slightly changed using a smart contract only (instead of stateless smart contracts, aka smart signatures): in this case you want the application account to be the clawback address.
1 Like