What is the best practice for a tax payment Smart Contract?
What is the best practice for a tax payment Smart Contract?
Loading saved threads...
xSkyripper · External communityPost link
External question — Ethereum Stack Exchange
Author: xSkyripper
Original post: https://ethereum.stackexchange.com/questions/61865
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
I have just been introduced to Ethereum Smart Contracts and I have a faculty-related project that implies the usage of them.
The idea is to create a DApp which allows clients (persons) pay taxes (in Ethereum) to a public institution.
My problem is that I cannot decide which high-level version of smart contract follows the best practices:
Global Smart Contract
institution creates it
institution adds clients to it
has the address of institution
has a list of clients (unique identifiers)
checks the payment conditions (e.g. amount paid == tax, the payer is in the list of clients, the receiver is the institution)
Smart Contract per client
institution creates it based on client information
holds the address of institution
holds a client (unique identifier)
checks the payment conditions (e.g. amount paid == tax, the payer is the client, the receiver is the institution)
Generic Smart Contract
institution creates it
checks the payment conditions (e.g. amount paid == tax)
Are the above ideas viable in the Ethereum - Smart Contracts context?
If yes, which one is the right one?
If not, how should the right Smart Contract look like based on my idea?
Quote
Report
Lauri Peltonen · External communityPost link
External answer — Ethereum Stack Exchange
Author: Lauri Peltonen
Original post: https://ethereum.stackexchange.com/a/61868
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
It's a bit difficult to know how thorough an approach you need. But let me offer you one alternative:
Institution creates contract
Institution adds a list of
person
objects to the contract
A
person
object contains the following data:
1) Ethereum address (each person has to have an Ethereum address tied to him personally)
2) Amount of tax that needs to be paid (in Ethers)
After that the contract makes sure people pay the taxes in some fashion. After date X institution issues a transaction to the contract to a
makeSureTaxesArePaid
function which makes sure all taxes have been paid. If not, something happens. All taxes paid to the contract can be later withdrawn from the contract by its owner (creator).
So this is pretty close to your original first idea.
Quote
Report
Rick Park · External communityPost link
External answer — Ethereum Stack Exchange
Author: Rick Park
Original post: https://ethereum.stackexchange.com/a/61874
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
From my point of view I have no doubts: first solution is the best practice.
It ensures that all the action needed, different from paying taxes, are in charge to the institution, which will benefits from money, I.e. do not charge who pays taxes of extra-work or extra-expenditure; furthermore it is naturally coordinated (on the contrary the second one require coordinations between institution and all of the tax payers); furthermore do not require to clone N contracts different for the client address only. Remember that you pay gas for each single contract deployed and for any byte occupied in blockchain: too much duplicates in solution 2!
Third solution is truly poor and it is not cheaper.
The solution proposed by Lauri can be useful if any client has a different amount of taxes to pay, but your question do not give us information on the matter.
In short: use first solution!
Hope this helps!
Quote
Report
Rob Hitchens · External communityPost link
External answer — Ethereum Stack Exchange
Author: Rob Hitchens
Original post: https://ethereum.stackexchange.com/a/76796
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
OP didn't say if this is sales tax, income tax, or something else so we have no information about how it is calculated. I'm going with a tax form/tax remittance scheme as it seems the most likely.
On the surface, this sounds like a "request payment" app, and little more. If confidentiality is a concern, then it takes diligent efforts to protect it and one should refrain from putting unnecessary information on the blockchain.
I would incline to option 1. For clarity:
institution creates it
institution adds client
addresses
to it
has
is
the address of institution
contract
has a list of clients (
unique identifiers
addresses
)
checks the payment conditions (e.g. amount paid == tax, the payer is in the list of clients
, the receiver is the institution
) From the contract's perspective, the receiver can't be anyone other than itself.
and ...
The institution determines taxes owed and informs the contract. This can be an off-chain process, with the net result committed to the contract.
Optionally, a version of the authoratative off-chain document that supports the net result in the contract. Something like (pseudo) hash(taxpayer, year/period, document revision number).
The institution has a way to withdraw tax revenue collected. Forwarding is possible, but not generally recommended.
Access control (who/what can withdraw, alter taxpayer obligations) through address whitelists.
The addresses and amounts of obligations and receipts will be open to examination by everyone and that might not be desirable. Consider investigating methods of obfuscation to support assurances about confidentiality including metadata analysis.
Hope it helps.
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Ethereum Stack Exchange Author: Rob Hitchens Source score (net votes, not local likes): 0 Original post: https://ethereum.stackexchange.com/a/76796 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. OP didn't say if this is sales tax, income tax, or something else so we have no information about how it is calculated. I'm going with a tax form/tax remittance scheme as it seems the most likely. On the surface, this sounds like a "request payment" app, and little more. If confidentiality is a concern, then it takes diligent efforts to protect it and one should refrain from putting unnecessary information on the blockchain. I would incline to option 1. For clarity: institution creates it institution adds client addresses to it has is the address of institution contract has a list of clients ( unique identifiers addresses ) checks the payment conditions (e.g. amount paid == tax, the payer is in the list of clients , the receiver is the institution ) From the contract's perspective, the receiver can't be anyone other than itself. and ... The institution determines taxes owed and informs the contract. This can be an off-chain process, with the net result committed to the contract. Optionally, a version of the authoratative off-chain document that supports the net result in the contract. Something like (pseudo) hash(taxpayer, year/period, document revision number). The institution has a way to withdraw tax revenue collected. Forwarding is possible, but not generally recommended. Access control (who/what can withdraw, alter taxpayer obligations) through address whitelists. The addresses and amounts of obligations and receipts will be open to examination by everyone and that might not be desirable. Consider investigating methods of obfuscation to support assurances about confidentiality including metadata analysis. Hope it helps.
Checking account access…