SRC-21: add out-of-band fee-on-transfer token standard #103
Conversation
moodysalem
changed the title
moodysalem
changed the title
SNIPS/snip-x.md
Outdated
| created: 2024-07-29 | ||
| --- | ||
|
|
||
| ## Simple Summary |
There was a problem hiding this comment.
Could you add a flow diagram to explain how the normal scenario unfolds?
There was a problem hiding this comment.
I added some context as well as some methods to the interface to the specification
Could use some feedback from FOT developers on how it is proposed to work
There was a problem hiding this comment.
@moodysalem, thanks for proposing this out-of-band FOT standard. As a FOT developer, I have some thoughts:
Implementation seems feasible. Curious about what specifically makes FOT tokens difficult in Ekubo's architecture?
I think pre-paying tax might add friction, but it's probably manageable. Your approach could prevent 'k' invariant issues in pools. It seems easier to implement since the transfer function doesn't alter token amounts in the pool.
SNIPS/snip-x.md
Outdated
| - DApp stores off-chain metadata about whether a token is fee-on-transfer, and implements the following logic if it is | ||
| - When depositing this token into a dapp, the `recipient` is the Dapp contract: | ||
| - Dapp calls `compute_fees_required(user, dapp_contract, amount)` off-chain | ||
| - Dapp adds `pay_fees(computed_fees)` call to the list of calls before all dapp calls |
There was a problem hiding this comment.
shouldn't this be
"Dapp adds pay_fees_for_sender(user, computed_fees)call" given that the user is the sender? current call defines the Dapp as the sender
There was a problem hiding this comment.
when i say 'dapp adds xyz to list of calls', i mean calls that are made from the user's account. it's usually easier to not include the user's address in the list of calls, so pay_fees would implicitly be for the user's account
There was a problem hiding this comment.
Oh yes makes sense.. my bad. I understood it as the Dapp making the calls to the token contract that implements the interface with calldata passed by the user (which indeed doesn't make sense as it's the user that pays the fee, not the dapp)
|
Could someone assign a SNIP number? |
Eikix
changed the title
Assigning the number 21 to this SNIP. Skipping number 20 to avoid confusion with ERC-20 |
|
Hey @moodysalem, can you add a sections "Rationale" and "Security considerations" (to keep syntax uniform among snips). IMO you can delete section "Implementation" and "History" for the time being. I think it would help to add more context on how this standard interacts with the ERC-20 token standard, e.g. does this standard require that the token be an ERC-20 token? The inteface should lie in the token contract? Should there be events? I also think that adding a use case would be helpful. It's not clear to me what problems this standard comes to solve (this isn't a blocker for merging, but adding context may make it a better snip IMO). |
|
|
||
| The expected usage flow is as follows: | ||
|
|
||
| - DApp stores off-chain metadata about whether a token is fee-on-transfer, and implements the following logic if it is |
There was a problem hiding this comment.
syntax: below you write "DApp", "Dapp", "dapp". Better sticking to one choice.
No description provided.