Using a secret contract, a tax report can be compiled on chain by querying SNIP-20 transfer history for registered accounts. This report can contain a summary of events, without revealing the full transaction details (who you interacted with, how much you sent to each address, your full balance). This report can be used, by that same contract or another contract (for modularity) to determine how much tax the account needs to pay (to authorities). If deployed by the authority in question, users may give this contract allowance to their account, and allow the contract to automatically withdraw the tax it determined needs to be collected.
The flow might look like this:
- A Tax Authority (TA) writes down the rules by which they wish to collect taxes. This can be literally anything, include exceptions for special known addresses, etc.
- A Report Contract (RC) is deployed which can create tax reports. These tax reports will only be visible by the users to which they pertain, the tax authority, and the next bullet point.
- A Collections Contract (CC) is deployed which knows how to read the tax report. Presumably, the format of this report will change less often than the reporting mechanism itself, so it makes sense to separate them.
- A user registers to the CC. This includes giving full allowance to the CC for the relevant SNIP-20 tokens, and providing the viewing key (VK) for those tokens.
- The CC shares the VKs with the RC.
- The TA pays for transactions with the RC that incrementally process the transfer history of the user.
- Once complete, the RC presents the completed report to the relevant entities, and submits it to the CC.
- The CC withdraws funds from the user’s account to the TA’s account using the provided allowance. If not enough funds are available, the TA may periodically attempt to withdraw the remaining debt (or however this sort of business is handled IRL)
This sort of system can be extended to include whatever safety, regulatory, dispute, etc features that are required. The key is that it would allow users to correctly comply to whatever regulations they may be subject to, but while still maintaining their privacy. The TA never has to know how much money users had, who they interacted with, how many times, etc.
This contract will probably need additional information like historic price data and the likes, which can either be submitted by the TA itself, or collected from on-chain oracles.
Once established, other applications that are subject to various KYC requirements may require being registered to the CC in order to be used. Basically deferring the KYC to the TA.
The upcoming Transfer History feature will also help improve this tooling, as it will provide richer info about user’s history of interactions with SNIP-20 tokens.