Title: EIP_5320__Harberger_Taxes_NFT
Category: EIPs

Author: green
Date: 2022-07-24T09:30:31.888Z

GitHub PR

Author: TimDaub
Date: 2022-07-24T15:54:07.124Z

I’ve been trying to find useful interfaces around implementing Harberger Taxes for NFTs that have maximal backward compatibility with EIP-721. Some of my work:

Incomplete Solidity implementation: GitHub - rugpullindex/libharberger: A dapptools/foundry-ready library for charging Harberger taxes on partial common non-fungible property.

blog posts:

Harberger Taxes can be Crypto's Sustainable Business Model
Non-Skeuomorphic Harberger Properties may not be implementable as ERC721 NFTs



My initial idea had been to use a Soulbound token bound to a smart contract as the base object that can then be harberger-taxed. For that, I had attempted to standardize two EIPs:


EIP-4973: Account-bound Tokens (which has arguably diverged from this idea a lot)

Add EIP-5192 - Minimal Soulbound NFTs by TimDaub · Pull Request #5192 · ethereum/EIPs · GitHub (which may neither be super useful)

Here are a few critical questions that you hopefully deem helpful for further developing the document:

Why mix auction logic into the NFT ownership logic? Auction houses like Zora and OpenSea implement auction houses such that any EIP-721 can move through them for allocating new owners. In fact, it’d be elegant if we could standardize around auctioning scheme interfaces for EIP-721. It seems unnecessary to conflate Harberger tax auctioning and NFT logic in one contract, as you suggest using Solidity inheritance.
Ownership is a preexisting topic defined outside of Ethereum or Solidity. Some say Ownership is the bucket of rights, permissions, and license opportunities that make a property ownable. E.g., there’s a difference between possessing and owning: As EIP-5320 introduces possession-based Harberger tax interest to users, what should function ownerOf(...) return? The collection’s address or that of the “NFT owner”? I’d argue an Harberger-taxed property isn’t truly owned by a user but by the taxing contract (which has the right to foreclose when taxes aren’t paid).
When can transfer functions of EIP-721 be called? When do they throw? I assume there is a connection between paying taxes and being able to call those functions?
As the variability and connection of tax rates to turnover rates seem to be fundamental (at least Radical Markets and Anthony Lee Zhang say so): What made you decide not to include them in the specification? E.g. a view function returning the current tax rate or a function to set a tax rate. Also: Do all items have the same tax rate? E.g. how would a Harberger tax possessor know what taxes are necessary to be paid at time t?

Regarding building a Harberger property contract, I’ve found this EIP very interesting: EIP-4907: Rental NFT, ERC-721 User And Expires Extension It would allow building an auction house that treats the Harberger property possessor to be the user and the taxation authority to be the NFT owner.

Author: will-holley
Date: 2022-07-25T12:54:34.496Z

Several of us, including Tim, are working towards this HT token standards over at https://partialcommonownership.com/.  Our next community meeting is this Wednesday; it would be great for you to attend.

Author: MicahZoltu
Date: 2022-07-31T07:11:10.299Z

One could imagine a mechanism for depositing ETH into some contract and then having multiple NFTs pull from that. This would allow someone to put say 10 ETH into a contract that is used to pay taxes on a hundreds of NFTs until the pot ran out. The owner then wouldn’t need to constantly top up each individual property all of the time, but instead just top up their funding source account.
Even better would be to use approvals and disallow ETH (WETH can be used instead).  This way the owner can just approve the NFT to draw on their TOK as necessary, so as long as they have TOK in their account they can pay taxes as they are collected.
Already addressed in the rationale, good job!

Author: MicahZoltu
Date: 2022-07-31T07:20:28.301Z

Instead of doing this, buy could have simply accepted the valuation of the item as the buy price. This, however, has frontrunning concerns, as the current owner can frontrun and increase the valuation.

It seems like this could be avoided by having a time delay on valuation changes.  When changeValuation is called, it wouldn’t take effect for n blocks, thus preventing the seller from frontrunning the purchase.  This does make the collect function a bit more complex, but I don’t think it would be too bad.

Author: guoliu
Date: 2022-08-02T06:09:15.748Z

Thank you for this proposal, we needed a standard like this a while ago, and will still need it for several future projects. We implemented Harberger Tax for our collaborative pixel canvas TheSpace.Game, and it has been played by several thousands of users.
Here are some of my thoughts regarding the proposal based on that experience.
Offer or buy
When there is competition, buying a token is not guaranteed since only the first one will acquire it. We implemented an offer logic (it’s called “bid” since it’s an auction): the bidder agrees to pay the current valuation as long as it is lower than the bid price. In this way, there is no racing condition and no front runs.
Prepaid tax or tax allowance
Prepaid tax is definitely a clearer logic. But with tax allowance, users need fewer ERC20 tokens to start playing the game, which turned out to be important in onboarding users for us. Tax allowance needs to be combined with a mint tax mechanism, so users are discouraged to repeat the following: “buy at a low price → increase price → default / burnt → mint again at a low price”.
Using tax allowance also means tax needs to be collected frequently. We opened up the tax collection function for anyone to call, and among the players emerged a role called “tax collectors”, who volunteer to collect tax and have become part of the game.
Also in our case, taxes and funds per token are not possible since the mental complexity it brings discourages users from playing the game. I believe the choice of tax collection method should be left to the implementation of the contract.

Author: mdnorman
Date: 2022-08-03T11:03:32.530Z

since there’s no “tax period”, it’s hard to know when taxes must be paid for someone who owns this token. I was working with CityDAO on this a proposal for using Harberger taxes on a parcel of land, and one of the things that folks need to know is when the collection period is. You don’t want to make it a single date because then folks will try to game the system, and you don’t want to make it “all year long” because you don’t know when it will actually be assessed.
I wrote up quite a bit of detail here if you want to take a look. It may inform this EIP in some ways to make tax collection more standardized.

Author: JasoonS
Date: 2022-08-03T11:08:34.887Z

Cool to see this topic come up again!
We implemented harberger tax contracts first at wildcards[dot]world (sorry - unable to share more than two links) where users could share deposits between their harberger NFTs, and the harberger tax of those NFTs could go to multiple different beneficiaries. (Hence it is “scalable” for users to own multiple NFTs that share a deposit and fund multiple beneficiaries). We re-used these contracts for a variety of hackathons and experiments over the years.
I gave a presentation on this a while ago which can be found here: https://youtu.be/LYm-cVuo0sg and here is the slideshow: Harberger Tax Contract Overview.pdf
The contracts are on github at wildcards-world/contracts, which might be an interesting reference too.
Quick thoughts:



 TimDaub:

Why mix auction logic into the NFT ownership logic?


At wildcards we always used a ‘Steward’ contract that acted as an NFT operator that managed the harberger tax side of things.



 TimDaub:

When can transfer functions of EIP-721 be called? When do they throw? I assume there is a connection between paying taxes and being able to call those functions?


Lots of thought needed here. Lots of trickery can happen if users don’t understand this. Also might depend on the use case.



 TimDaub:

a view function returning the current tax rate or a function to set a tax rate


Yes, this is essential IMO. In wildcards as a case study each NFT has a different rate.



 TimDaub:

It would allow building an auction house that treats the Harberger property possessor to be the user and the taxation authority to be the NFT owner.


I think this makes sense, but if it is possible for the NFT to ever be withdrawn from the taxation authority, it kind of defeats the point (although there are likely lots of fun mechanisms that could use this).
There are so different variations you can make to harberger tax. For example, realitycards[dot]io have their own variation on harberger tax. So I think this EIP should aim to be high level enough to accommodate future variations and explorations.

Author: guoliu
Date: 2022-08-04T00:09:24.778Z

mdnorman:

since there’s no “tax period”, it’s hard to know when taxes must be paid for someone who owns this token.


It seems to me that the concept of “tax period” is not needed, since the calculation of tax obligation should be continuous (or in practice, with 1 block as the calculation period).  Whether using prepaid tax or tax allowance, tax collection can be triggered at any time, including but not limited to ownership and price change.

Author: will-holley
Date: 2022-08-04T00:16:44.096Z

This depends on whether you’re using a deposit or non-deposit model to pay the taxes[1].  In the case of a deposit, there will be a tax period, the foreclosure time of which is easily calculable (see example here).
Footnotes

There is an inherent tradeoff between requiring the leasor to deposit funds and the risk that the leasor does not make a deposit, does not have the funds when collection is required, and the collector loses out on her tax revenue.  A depreciating license model may be an alternative to this problem.

Author: guoliu
Date: 2022-08-04T04:36:09.119Z

JasoonS:

When can transfer functions of EIP-721 be called? When do they throw? I assume there is a connection between paying taxes and being able to call those functions?


I think a broader issue related is that “transfer” in the context of Harberger Tax should be different from that in ERC721. ERC721 is designed for private ownership, while Harberger Tax is designed for partial common ownership.
Ownership under Harberger Tax corresponds to tax obligation, so transferring token is also transferring tax obligation. This can be used as a form of attack, where the attacker set the price very high and then transfer it to the victim. (In the case where tax is prepaid/deposited and allocated for each token, it can be mitigated by clearing deposits of all tokens I do not own, but it can still cause unwanted consequences)
In our case, we automatically set the token price to 0 when a transfer is triggered. “Transfer” thus still follows the continuous auction logic of Harberger Tax, where the owner set the price to 0 then the receiver gets it for free.

Author: MicahZoltu
Date: 2022-08-04T07:20:22.351Z

will-holley:

A depreciating license model may be an alternative to this problem.


This is a clever solution, and I generally like it.  Can you draft up a simple example (Alice mints token, sells to Bob who values it at some price, then a year later Carol buys it)?  I’m particularly curious how valuation changes are handled.  When I go through the construction in my head, I end up with no change in capital efficiency, just a change in mechanics and who has to escrow the money (the minter vs the renter).

Author: MicahZoltu
Date: 2022-08-04T07:22:49.312Z

guoliu:

Ownership under Harberger Tax corresponds to tax obligation, so transferring token is also transferring tax obligation. This can be used as a form of attack, where the attacker set the price very high and then transfer it to the victim. (In the case where tax is prepaid/deposited and allocated for each token, it can be mitigated by clearing deposits of all tokens I do not own, but it can still cause unwanted consequences)


If the tax is pre-paid in escrow, transferring it wouldn’t do you any good because either there is a requirement for the asset to always remain funded, or the valuation would immediately go to 0 when the escrowed funds are cleared out so no taxese are due.  There is no way to force someone else to pay for something in crypto as users have to sign any asset transfer.

Author: JasoonS
Date: 2022-08-04T07:45:18.726Z

guoliu:

In our case, we automatically set the token price to 0 when a transfer is triggered. “Transfer” thus still follows the continuous auction logic of Harberger Tax, where the owner set the price to 0 then the receiver gets it for free.


That is the same as giving away the NFT, since anyone could claim it for zero too (this sounds undesirable for almost all use cases). There could be a “approveReceipt” function of sorts that allows a recipient to add deposit+chose price before a token gets sent.
In wildcards we have a gift function that requires the sender to give some time-period amount of deposit along with the NFT so that it doesn’t auto foreclose as soon as it is sent (it is sort of ‘gift of giving’ function). Additionally, this means it is less likely to be a predatory attack on the rest of the users deposit given the minimum time is long enough and participants are relatively active. Once again, I think this kind of mechanism is project dependant.
In any case, I don’t think one rule fits all here, and I think many projects may decide to completely remove the transfer function from erc721 standard (ie, a new type of token that isn’t erc721 compliant).

Author: TimDaub
Date: 2022-08-04T08:40:41.715Z

mdnorman:

You don’t want to make it a single date because then folks will try to game the system, and you don’t want to make it “all year long” because you don’t know when it will actually be assessed.


In libharberger, a tax period is the block time of Ethereum. IMO this will always work considering that the percentage can be adjusted to low or high depending on the frequency of new blocks being mined.

Author: TimDaub
Date: 2022-08-04T08:59:54.852Z

guoliu:

Ownership under Harberger Tax corresponds to tax obligation, so transferring token is also transferring tax obligation. This can be used as a form of attack, where the attacker set the price very high and then transfer it to the victim. (In the case where tax is prepaid/deposited and allocated for each token, it can be mitigated by clearing deposits of all tokens I do not own, but it can still cause unwanted consequences)


I actually like this model as it may simplify implementation with deprecating licenses. Essentially, to start possessing a Harberger Token, one attaches ETH that then gets continuously taxed until the ETH amount is zero.

By sending more ETH, the token’s self-assessed value goes up
By letting ETH get taxed, the token’s self-assessed value goes down
By transferring the token to another account, the token’s ETH credit is transferred to that account too
In case a token has an ETH balance of zero, anyone can buy it directly from the tax authority

Author: TimDaub
Date: 2022-08-04T09:03:48.901Z

will-holley:

(see example here ).


I know I’ve been beating this dead horse for too long but isn’t this function vulnerable to attacks? Integer Division - Ethereum Smart Contract Best Practices

Author: guoliu
Date: 2022-08-06T22:32:19.122Z

TimDaub:

Essentially, to start possessing a Harberger Token, one attaches ETH that then gets continuously taxed until the ETH amount is zero.


It is a neat mental model. Each token has its own deposit account, which does not change with ownership transfer, but determines if current ownership should be revoked.
One implication is that one cannot get back the deposit after losing ownership, whether intentionally or bid by another buyer. And there would be one strategy to buy in tokens with a higher deposit balance.

Author: guoliu
Date: 2022-08-06T22:38:38.612Z

MicahZoltu:

There is no way to force someone else to pay for something in crypto as users have to sign any asset transfer.


It is true with the following implementation:

tax is pre-paid
pre-paid tax is per token
after ownership changes, the balance in pre-paid tax is returned to the previous owner

But in other implementations, transferring tokens can still drain tax (pre-paid or allowance) unintentionally.
@TimDaub 's idea above should also be able to avoid such tax drain since the tax account is only attached to the token and detached from the payer address.

Author: will-holley
Date: 2022-08-10T16:33:45.948Z

When using a deposit model, the leaser should be remitted their deposit, post tax-collection, on lease takeover or foreclosure, unless they are actively transferring their lease, in which case the deposit should also transfer.

Author: will-holley
Date: 2022-08-10T16:38:44.337Z

Can you specify the type of attack your thinking of?  I have encountered overflow issues with the division here when fuzzing during testing: partial-common-ownership/Taxation.sol at 3e7713bc60b6bb2e103320036ec5aeaaaceb7d2b · 721labs/partial-common-ownership · GitHub.  I’ve looked into solving it by switching over to DSMath but haven’t spent much time on the implementation.

Author: TimDaub
Date: 2022-08-10T17:07:20.859Z

will-holley:

I’ve looked into solving it by switching over to DSMath but haven’t spent much time on the implementation.


I’m confident that this implementation addresses it properly: libharberger/src/Harberger.sol at master · attestate/libharberger · GitHub (test: libharberger/src/Harberger.t.sol at master · attestate/libharberger · GitHub)



 will-holley:

Can you specify the type of attack your thinking of?


Unfortunately, I don’t have enough time to plan a concrete attack. I think it’d be where you try to, e.g., divide such that the outcome is close to 0.5, and then you can make something go to zero because of Solidity’s integer flooring. Not suggesting that this CAN actually happen - but I think striving for perfect accounting precision must be the goal. From my understanding scaling the calculation’s numbers up using the parts-per concept is sufficient. Cool that you’ve fuzzed this! Should look into it!

Author: TimDaub
Date: 2022-08-11T20:03:02.530Z

I wanted to make another comment on the original submission of EIP-5320. It features 6 different functions to interact financially with the Harberger property.
A recent implementation of depreciating licenses I did just necessitates two (function assess and function fiscal): hdmap/hdmap.sol at 640ebbe5b5daaf94225224611a974dd97143f619 · rugpullindex/hdmap · GitHub


function assess can increase and decrease taxes and allows a buyer to fulfill their order. Taxes are calculated whenever it’s run.

function fiscal returns the property’s new price and the amount of taxes due (which will go into effect the next time assess is called.

Author: esaulpaugh
Date: 2022-08-12T07:41:05.179Z

A decentralized tax collector? Can we get a decentralized Roko’s Basilisk too?
And of all the taxes, we choose the one that’s incompatible with ownership? Owning things is pretty popular. Much unlike a basilisk.

Author: TimDaub
Date: 2022-08-12T08:47:54.357Z

please comment here when you have constructive things to say about the document. Please don’t comment here if your intention is to bash other people’s work. Thanks.

Author: esaulpaugh
Date: 2022-08-12T09:13:49.081Z

Assume my pronouns, not my intentions. My suggestion is to reconsider the roadmap. I haven’t so much as glanced at your work.
But I reserve the right to criticize EIP 1057, 5320, and others.

Author: TimDaub
Date: 2022-08-12T10:09:20.388Z

Look, if you feel like needing to complain about something, I recommend https://twitter.com.
For this forum, you must make a substantiated complaint about the subject matter, e.g., that you don’t like certain things in @green’s PR: Add EIP-5320: Harberger Taxes NFT by greenlucid · Pull Request #5320 · ethereum/EIPs · GitHub
Sadly, Glen Weyl has the strength for naming things such that people go crazy about them. Soulbound tokens, next to Harberger taxes is one such example. But in reality and if you look into the source code, this has nothing to do with the taxes that a government collects. Nothing at all. Any marketplace taking a fee e.g. does the exact same thing. So Harberger fees would be the equivalent.
But don’t expect us to take your deontic criticism seriously: We’re not working for you, and there is no moral high ground here. The path to being heard is where you make a substantiated argument against the specification on an epistemic basis and not on what “should be” because you think it’s right.

Author: SamWilsn
Date: 2022-08-12T17:49:34.076Z

I’m not even the slightest bit familiar with Harberger taxes so please forgive any stupid questions.

Is it important to differentiate between Harberger transfers and non-Harberger transfers? As I understand the document, a Transfer event will be emitted for every TokenBought event.
The event names are somewhat inconsistent. TokenBought has token but TaxesPaid does not, even though they are both events applicable to a single token.
Should increasing the valuation require some kind of back-taxes? Seems like an owner could always frontrun buy attempts by increasing the valuation by one wei.
Would a taxFor(uint256 tokenId, uint256 valuation, uint256 duration) returns (uint256) function make sense, or are there reasonable tax rate schemes that would break with that signature?

Author: green
Date: 2022-08-14T12:43:40.169Z

Hey, thanks everyone for the interest in this EIP.
I’m going to try to shed some light in the rationales of why some features weren’t put into the standard draft:
owner vs leasor
Ownership is understood “in the context of the contract”. The contract (or the collector) are known to be the ultimate “owners” of the item. Also, owner is a standard label. Changing owner to leasor would make no functional changes.
There as discussion by Tim on what to do about ERC-721 functions, should they revert?
It would depend on the implementation, but the implementer is free to separate the taxpayer from the owner of the item as separate parties. Then, owner-exclusive functions can be called by owner, ERC-721 transfers don’t need to revert (because ownership is not a liability), and leasor remains the one paying the cost. This consideration to implementers can be added to the EIP.
views and setters for “tax rate”
Flat tax rates aren’t the only way to do taxes. For example, there’s progressive taxes. Or, you could create address dependent systems, for example, giving a lower rate to addresses registered in Proof of Humanity, or owning some NFT that makes you eligible for a discount. If a flat tax rate interface was desirable, it should be extended from this EIP-5320.
on calculating taxes
The standard doesn’t indicate how should they be calculated. In our PoC implementation we used timestamps, and calculated the tax rate over seconds. But taxes could be calculated by block counts, periods, or something else. It’s up to the implementation.
There a consideration to make here. If seconds are being used and the ERC-20 token to pay taxes with has “low precision”, the valuation is small, or the unpaid period is small, a naive implementation could have a divisor too large and turn the owed taxes for the collect call to zero.
security concerns over this implementation
In this Proof of Humanity proposal I outlined a few caveats:

Excluding collect, interactions must revert if the funds available to pay for the taxes on the seat are not enough to go over the cooldown period.

Then, I proposed a cooldown period of 3 months. What this means, is that if you were to acquire a token, you’d have to prepay taxes for 3 months. If something similar to this isn’t done, someone may acquire the token at a high price, do a damaging action, and then revoke it in some way, paying close to no taxes in the process.
Actions that wouldn’t be allowed (or, they could be allowed on the condition of forfeiting a portion of prepaid taxes):

revoking (or, if allowed, the prepaid taxes from timestamp to timestamp + period are not reimbursed)
defunding (likewise, defunding more than the taxes to complete the period is not allowed)
changing valuation (changing to something high is disallowed if prepaid taxes aren’t enough to cover the period. changing to something lower isn’t allowed during the period)

prepaid taxes vs allowance
Anyhow, I believe this is standard level worthy. Keeping it up to the implementer would make the main functions that are relevant to the standard unable to be standarized. So the discussion is relevant to the ERC. I’m divided between these two.
how to allowance-based taxes
If taxes are not pre-paid, then the leasor makes an allowance, and a function is open for everyone to collect taxes. If there’s not enough allowance or balance to pay the pending taxes, the token is revoked.
Considerations:

either collector or a third party need to manually claim the pending taxes. on the implementation level, a compensation for the gas expenses of collecting the taxes could be provided, for example, by sending a portion of the claimed taxes to the one that calls the function.
leasor can default on the latest unpaid taxes at any time.
no longer is it possible to force them to prepay a given amount, so “flash buy” attacks are possible. you can still impede the flash-buyer leasor to lower the valuation, but you cannot force them to sell the token for a certain amount.

flash-buyer defaults on the taxes and loses the token. the loss will be, at the very least, equal to how much they paid for the item.
flash-buyer makes a contract to effectively sell the token for less than the valuation (the contract buys at current price, they reimburse the difference to new leasor). The Harberger Tax contract can still forbid lowering the valuation, so leasors that acquire the item through this scheme could have to endure high taxes for a minimum period.



how to prepaid taxes
(This flow doesn’t need to be followed exactly, this is just an indication on how could it work)
When you buy a token, you also prepay a certain amount in taxes. You may choose this amount, and the contract may enforce a minimum.
A collect function is still there so that collector can realize partial tax payments, but no longer has to be called continuously to defend against defaulting. Only once, if there are not enough prepaid taxes to continue supporting the token.
If an action occurs that makes the previous leasor stop paying taxes, the remainder of prepaid taxes, if it exists, is reimbursed to the leasor.
Considerations:

It’s not as capital efficient
Doesn’t require collecting taxes manually and continuously to mitigate the loss of the leasor defaulting on the taxes
Prepaying taxes allows the contract to enforce leasors to prepay a minimum period. This makes flash-buy attacks more expensive, because the attacker would need to pay for the token to the previous leasor, plus a minimum period to the collector.

miscellaneous consideration for implementers
To increase the cost of attacks (such as flash-buy), or acquire a compensation, a fee could be included on every buy transaction, which could substitute the “minimum period” concept.

Author: esaulpaugh
Date: 2022-08-14T23:05:38.088Z

Are you kidding? Glen Weyl literally wrote something called “Property Is Only Another Name for Monopoly”. I’ve had that bookmarked for over a year. Why you think I might be triggered by the word “tax” but somehow simultaneously okay with the outright abolition of private property, I do not know.
Harberger causes forced sales as if everyone is constantly in bankruptcy proceedings. It’s deranged. It would have forced Elon Musk to sell SpaceX to Lockheed and Boeing. Perhaps that is why you like it.

there is no moral high ground here

Against standardizing communism? Au contraire.
Build your communist utopia on Ethereum, by all means. But I will always oppose its standardization. If for no other reason than it sends a terrible message to the youth.

Author: guoliu
Date: 2022-08-15T05:34:42.137Z

esaulpaugh:

Harberger causes forced sales as if everyone is constantly in bankruptcy proceedings. It’s deranged.


It is indeed ridiculous to abolish private property.
But there are many cases where properties are publicly owned. In the physical world, there are examples such as the usage of the radio spectrum, and the land of national parks. In the digital world, there is user attention (or ad spaces), since it is derived from the collective contribution of the users and developers and therefore should be owned collectively.
These are the cases where partial common ownership is applicable, not the cases where properties should be privately owned.
These types of resources/properties are usually allocated either by the government in a centralized and inefficient way or privatized by companies in an exploitive manner. Partial common ownership is useful since it provides a decentralized and market-driven alternative.
So standardizing partial common ownership is not about building a communist utopia, it’s about avoiding the need of having a communist government by extending the scope of the market.

Author: TimDaub
Date: 2022-08-15T07:44:43.047Z

Please name one country where private property exists. According to the economists I spoke, if the state can foreclose property (e.g. given tax obligation), it’s not truly private. That’s the academic definition.
Since you mentioned US-american names, the USA also doesn’t implement true private property. So technically nobody wants to abolish anything - as what you’re talking about doesn’t exist in reality.

Author: will-holley
Date: 2022-08-15T13:33:37.937Z

Partial Common Ownership is an applicable property scheme for assets that derive their value, at least partially, from network effects. The classic Georgian example is land. A conceptual separation of network effects from the owner’s capital and labor investments is necessary. In doing so, PCO schemes purport to improve the allocative efficiency for investments in these network effects (typically but not limited non-excludable goods), ultimately improving the value of the asset.

Author: esaulpaugh
Date: 2022-08-16T18:04:55.349Z

But then calling it radical markets is a misnomer. It may be a system of exchange, but a market it is not. And if it were only about things which are already public, then it wouldn’t be radical either. There is a fundamental bait-and-switch with so-called radical so-called markets. Which is kind of par for the course in left economics.

Author: esaulpaugh
Date: 2022-08-16T18:10:38.535Z

will-holley:

applicable property scheme


Indeed, scheme is the correct word. Some should be rejected for having undesirable properties. This is one of those.

allocative efficiency

I don’t think there is allocative efficiency in turning a nascent startup over to the established interests it threatens.

Author: esaulpaugh
Date: 2022-08-16T18:20:06.785Z

Agricultural, educational and institutional properties on St Kitts are exempt from property taxes.


technically nobody wants to abolish anything

Is that what Glen Weyl says? And evidence of institutionalized theft isn’t evidence of public ownership. You have the two confused.
Lastly, where is the property tax on sports cars? I haven’t gotten any visits from the fuzz lately and I haven’t been paying anything to merely own my ride.
Remember when Happy Gilmore’s grandma had to bid on her own house? The only thing worse would be if she were not allowed to bid. That’s Harberger.

Author: doyl.io
Date: 2022-08-17T12:38:37.692Z

Guys, this is a forum for discussing the details of a technical spec.  If you want to discuss the moral or political implications of this ideas, I suggest moving to twitter

Author: doyl.io
Date: 2022-08-17T13:18:13.532Z

I think this would benefit from a view to see the balance of tax prepaid for an item.
function fundingFor(uint256 tokenId) external view returns (uint256);

This could also allow real time tax payments.  fundingFor could be calculated as the result of a decreasing linear function which would be updated when the user adds more funds

Author: TimDaub
Date: 2022-08-17T16:26:41.347Z

100% agree. I’d appreciate if moral comments would get moderated actually.

Author: esaulpaugh
Date: 2022-08-18T06:29:35.824Z

Ride on the peace train; ooh ah ee aah ooh aah.
Nothing in this post should be construed as a commercial or promotional message. This message shall not engender feelings of an overly promotional or commerical nature. This post is neither an advertisement nor a promotion. Do not associate this post with its author or any product or service associated with its author.

Author: green
Date: 2022-08-22T01:24:56.762Z

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.

Author: guoliu
Date: 2022-09-07T05:33:14.186Z

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?

Author: TimDaub
Date: 2022-09-09T13:04:49.231Z

In a recent tweet storm, I document the mechanic behind Harberger dmap: https://twitter.com/glenweyl/status/1568223395543670784

Author: 0xCaps
Date: 2023-05-02T13:45:16.827Z

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.

Author: xinbenlv
Date: 2023-05-09T16:59:45.015Z

Hello from 2023! @TimDaub and @green
Are you still perusing EIP-5320?

Author: TimDaub
Date: 2023-05-09T18:00:22.876Z

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

Author: xinbenlv
Date: 2023-05-10T06:11:47.844Z

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.
It would be on May 16 Tuesday 4pm PT / 7pm ET / UTC2300.
Sign up agenda here Agenda for 1st AllERCDevs Meetup · Issue #1 · ercref/AllERCDevs · GitHub

Author: TimDaub
Date: 2023-05-10T08:43:01.363Z

On holiday during that call but 23pm UTC seems very hostile to EU time zones