Revenue sharing for authenticators via proxy on TPID

[prcolaco]

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

[aaroncox]

I'd probably avoid using the proxy field itself just to avoid situations where the account receiving the TPID payouts is indeed also utilized as a proxy. IMHO best not to mix responsibilities, and just add a new field specifically for this purpose.

[prcolaco]

I'd probably avoid using the proxy field itself just to avoid situations where the account receiving the TPID payouts is indeed also utilized as a proxy. IMHO best not to mix responsibilities, and just add a new field specifically for this purpose.

I suggested the creation of tpidproxy field exactly because of that...