Service fees cut

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:

  1. 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.

  2. 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!!