I agree, if prepaid taxes become the way to go, this will be included into the standard.
@guoliu made some arguments in favor of allowance, so I’m not sure which way should the standard go. I lean towards prepaid taxes.
I don’t think the standard should be compatible with both allowance and pre-paid taxes at the same time. The main functions to standardize (buying the tokens, paying taxes, etc) could depend on this, don’t they? Although, if the interface could be the same, then the allowance vs. pre-paid taxes could just be left as security considerations per implementation.
PD: After a second read, you were indeed proposing this function for both pre-paid and real time. So, anyhow, this view should be included.
It would be ideal to be compatible with both allowance and prepaid taxes. The choice should be left to implementation since it depends on the use case, and the standard should be implementation agnostic.
What are the interfaces that cannot be compatible with both routes?
On the subject of allowances I believe it has more or less the same capital inefficiency as pre-paying taxes but with the UX of mistakenly moving/spending/staking “liquid” tokens and defaulting on your underlying.
I think most users would rather lock funds similar to prepaying for years on an ENS name. Paying taxes in a low-level hyper-secure staked ETH derivative would also help fight capital inefficiency and could open the door to some Alchemix-styled self-repaying Harberger tax mechanic.
Not sure what is the best path here. I deployed hdmap but there was also no interest. But it can be instructive what methods or API such a standard may need
I talked to @guoliu the other day. This direction of exploration, Harberger Tax and others is increasingly interesting to me.
Do you care to come and share this, maybe 5-10min on our first #AllERCDevs meetup? We hope this become a place for more synchronized peer review / collaboration place among people who cares and builds ERCs.