Problem:
A regular wallet that integrates FIO Protocol is able to generate revenue by setting TPID in the transactions that allow it and receive that way a share of the fees to that account. This is a great tool to incentivise wallets and dapps to integrate with the protocol, but when a dapp uses an Authenticator as Anchor, Scatter or our project in the future, then it becomes impossible to share that revenue between the dapp and the authenticator, due to TPID accept only one account and a contract cannot be deployed to that account to perform the split.
Suggested solution:
When performing the payout of each TPID, the fio.treasury::tpidclaim action could check if the account is a proxy, and possibly some other flag in the voters table (there are reserved2 and reserved3 placeholders) so that the payout could be split equally to all accounts voted by the proxy, instead of the proxy account itself. This way it would be easy to setup revenue sharing and also clean, transparent, on-chain, trust-less and verifiable by all parties. Of course this would require all the accounts voted by the proxy to be producer accounts... maybe that new flag, say "tpidproxy", could remove that requirement of producer account? in this case some extra checks should also be done in voteproxy and in autoproxy code...
Problem:
A regular wallet that integrates FIO Protocol is able to generate revenue by setting TPID in the transactions that allow it and receive that way a share of the fees to that account. This is a great tool to incentivise wallets and dapps to integrate with the protocol, but when a dapp uses an Authenticator as Anchor, Scatter or our project in the future, then it becomes impossible to share that revenue between the dapp and the authenticator, due to TPID accept only one account and a contract cannot be deployed to that account to perform the split.
Suggested solution:
When performing the payout of each TPID, the
fio.treasury::tpidclaimaction could check if the account is a proxy, and possibly some other flag in thevoterstable (there are reserved2 and reserved3 placeholders) so that the payout could be split equally to all accounts voted by the proxy, instead of the proxy account itself. This way it would be easy to setup revenue sharing and also clean, transparent, on-chain, trust-less and verifiable by all parties. Of course this would require all the accounts voted by the proxy to be producer accounts... maybe that new flag, say "tpidproxy", could remove that requirement of producer account? in this case some extra checks should also be done invoteproxyand inautoproxycode...