Starting a topic to discuss standards and implementations around partial common ownership of NFTs.
Some thoughts on my mind:
So far, we have experimented with two different implementations on the Geo Web.
Similar to above except:
Accountant, ETHExpirationCollector, ETHPurchaser, SimpleETHClaimer)Other solutions I have come across.
Some quick notes (may not be accurate):
Adding thoughts to the aforementioned solutions.
Geo Web
going to return to this because youâve clearly spent some time on it
721 Labs
ERC721.sol. For now this asset, for now, must be deployed from scratch. I am thinking about developing / deploying an ERC1155 contract for wrapping existent NFTs to make them PCO but am not sure whether that should be included within the core repo for 721 Labâs implementation.Wild Cards
#listNewTokens).Superfluid
Boundless
#buyToken in Seller.sol â not sure if this is a perpetual market or the current owner needs to list âfor saleâ. The inline method comment alludes to the latter but I couldnât tell from my first pass over the method logic.I believe that we should create a standard implementation for several reasons:
This is great. Thanks for all the info @will!
Some more info shared by @graven that I did not mention in my first post. We have also discussed an implementation for the beneficiary to collect (pull) accrued taxes in constant* time, regardless of the number of assets whoâs taxes are going to that beneficiary.
We have a few meetings setup with various people in RxC community interested in partial common ownership. As mentioned in Discord, we will probably find another place to continue this conversation across multiple people and teams.
I will come back to this thread after those conversations and update it with relevant info for the Geo Web.
*Update: I meant constant, not linear
Something like this?
function withdrawFunds() public {
// query all tokens the message sender is beneficiary of
uint256[] beneficiaryOf = getTokensOf(msg.sender);
// map & reduce
uint256 remittance = 0;
for (uint i = 0; i< beneficiaryOf.length; i++) {
uint256 tokenId = beneficiaryOf[i];
uint256 due = getTaxedOwed(tokenId);
remittance += due;
}
payable(msg.sender).send(remittance);
}
It probably makes the most sense, for now, to use this as Geo Webâs Partial Common Ownership thread.
Our goal is to withdraw without iterating through all tokens that the DAO is a beneficiary of, since the DAO would be the single beneficiary for all tokens in our case. We want this to be a constant and not linear time operation.
However, I can see where there are other use cases when it may be perfectly acceptable to iterate through all tokens. Like when an artist wants to collect funds from each of their pieces, or whenever else there may be a small number of tokens for one beneficiary. I believe Wild Cards fits this use case.
Because in your case Geo Web (the Geo Web DAO?) is the always beneficiary, correct?
Something as simple as?
private uint256 balance = 0;
address payable owner;
function collectTax() public payable {
balance += msg.value;
}
function withdrawFunds() public ownerOnly {
owner.send(balance);
balance = 0;
}That is essentially what we have implemented today. What @graven discusses in that post is how to only collect taxes that have actually accrued, so not the entire msg.value.
Say a user deposits 1 ETH for a parcel worth 10 ETH. At 10% tax rate, that deposit is enough to pay for a year of taxes. The DAO could either:
Makes sense. The latter is what my implementation has because the tax holder can withdraw. A few things come to mind:
great jobďźI just joined, I am a smart blogger
The goal of the formula thatâs included here is to prevent a DAO from overdrawing the treasury for the reasons that you cite. We felt that in a smart contract world, 99.999% safe or a massively positive expected value investment doesnât even cut it.
So it sounds like that formula mimics your implementation, but it calculates the âearned revenueâ (which can be withdrawn) in aggregate rather than on a per token basis. This was important for the Geo Web because iterating through potentially millions of parcels would be computationally/cost prohibitive.
That said, we didnât end up implementing this and instead went with non-refundable deposits. On transfers of land/tokens, the purchaser must reimburse the previous licensor for their outstanding network fee balance. The purchaser essentially inherits the fee balance (which they can add to at any time).
Quoting the important part of that post for easier reference and in case (centralized 
) Substack goes away:
The new part is calculating earned taxes (aggregate funds that can be collected by the Geo Web org* from the contract) and a required reserves (unearned/prepaid taxes that must remain locked for potential refunds):
- Required Reserve(T1) = Reserve(T0) + New Taxes Paid - Taxes Returned - Sum of Self-Assessed Values(T0) * (Tax Rate * Duration(T1-T0))
- The above assumes a universal tax rate, but could be modified to handle multiple tax rates. Weâll likely measure duration between transactions in seconds, so the tax rate used in the formula would be per second.
- Total Contract Funds(T1) - Required Reserve(T1) = Funds Available to Withdraw(T1)
The required reserve formula is concurrently updated with each of our basic contract functions. Aggregate tax collection/withdraws are now a constant time complexity transaction (thereby saving the fate of the Geo Web and the Ethereum blockchain).
I should have read that Wk2 Update linked above more closely : ) Makes sense!
Weâve moved the overarching conversation around this to the RadicalxChange Github discussion board for more visibility and project-neutral considerations. Weâre excited about the prospect of standards for PCO NFTs, but will also need to push forward on our unique implementation needs, so weâll post Geo Web-specific discussion here still.
Based on group discussions my baseline thinking for which PCO values to store and which are implied have changed. Hereâs a cross post from the RxC board that summarizes that change in thinking for me:
My attempt to summarize the challenge is finding the right balance between the user experience of partial common ownership, technical limitations/implications of smart contracts, and economic reasoning.
Itâs currently a big lift to convince people to adopt this radical property rights system, so making it easy to understand, use, and manage should drive a lot of design decisions to start (without sacrificing the core principles). This challenge is most apparent in the question and implementation of, âHow am I even supposed to price property under this new system?â Pricing is a complex often subjective question even in traditional property rights systems. For many itâs just an exercise in +/- from an existing market reference. So⌠what do we do without a good existing reference?
My initial reaction was to embrace bottom-up economic reasoning: have users set their desired tax/fee payment rate and calculate their self-assessed value accordingly (
Self Assessed Value * Tax Rate = Payment Rate). There are two problems here. As Matt pointed out, most people arenât used to thinking in discounted cash flow terms and may prefer to just set their price directly and more subjectively. The second is that if you key off the tax payment rate (both from a user entry perspective & by directly storing the payment rate in the smart contract) the implication is that a change in the tax rate would immediately, proportionally lower all self-assessed values and the total market value. That could be quite jarring. In non-smart-contract-intermediated markets, changes to a tax rate would be factored into self-assessed values over time. There would be downward pressure from a tax increase on value, but you would also assume that the tax rate increase is being driven by a desire to pay for useful public goods, services, etc. that increase market value. How those two forces net out is up to the market.Given the above, I now lean toward embracing the subjectivity and complexity of all that goes into a self-assessed value in the design and implementation of a PCO smart contract. Because changes in a tax rate would have complex impact on the marketâs value, we shouldnât try to bake in too many hard-coded assumptions. There isnât a perfect or certain answer, so it seems that defaulting to the self-assessed value staying constant rather than the payment rate (effectively one or the other needs to be stored in the smart contract and you donât want to have to do mass updates) is the safer choice. Users can and should update their self-assessed values and implied payment rates, but they can do that over time, factoring in their personal perspective/information to come to a new equilibrium.
Cody and I discussed the technical implications and tradeoffs around this today in the context of (eventual) streaming payments, global/individual rates, grandfathering in rate changes, and continuous/fixed period auction implementations. The move to discrete auction periods has the biggest potential impact on the architecture, so weâre both taking time over the next few days to sketch out what that might look like before proceeding. More to comeâŚ
Been thinking a lot about periodic auctions, especially in the context of Entry & storage of self-assessed values/contribution rates and changing tax rates. Here are some thoughts:
Although perhaps the âpurestâ form of PCO, there are issues and tradeoffs with a continuous auction.
Exploring a periodic auction could solve some of these issues and make PCO more conservative. Essentially, the new requirement could be:
A licensee should have the opportunity to guarantee their control of a license for some reasonable amount of time
License Duration has a max, say 1 yearValue * Tax Rate * License DurationTax Rate may have been updated since the last auction, and would be reflected in this new periodThis is a simple approach that allows a licensee to guarantee control of a license for some period up to the max License Duration, as long as they pay all the fees up front.
A major issue with this approach is the working capital requirement. Not only is a potentially large amount of working capital needed to bid, but the people with a larger working capital would have a major advantage over those with a small working capital.
Here is an example. Say there are two potential licensees (Alice and Bob) who both want a license for a year and who both value the license at $1000. The tax rate is 10%, thus the deposit required up front to purchase the license is $100.
Alice has $100 of working capital, but Bob only has $10 of working capital.
In PCO theory, Alice and Bob should be economically equal. In practice, Alice has an advantage because of the extra working capital. Bob, in this case, would either need to bid a higher self-assessed value or a smaller license duration.
A potential new requirement could be:
The current owner should be who values it the most for that period of time, not who has the most working capital.
This is not only an issue for this approach, but for our current design as well.
Here is another method that could eliminate the working capital issue (or reduce it to be negligible).
Same as above, except:
License duration is a constant for all bidsValue * Tax RateLicense duration)This approach allows the licensee to pay for their fees throughout the period, only requiring a 4 hour deposit in the Superfluid protocol. Any failure or change to the flow would trigger an auction to allow others to bid again.
The license duration would need to be constant, since there is no deposit that can be used to âoutbidâ others, thus eliminating the race to who has the highest working capital as described above.
This approach also uses deposits, but allows for a licensee to not need to come back every period unless someone outbids them.
Same as method 1, except:
License Duration is a constant, say 1 monthMax Expiration is stored instead of Expiration that is calculated from the deposit amountStart Date is also storedExpiration is calculated as the smaller of:
Start Date + (License Duration * (((Now - Start Date) % License Duration) + 1))Max ExpirationThe approaches above are very similar, but just differ in how the fees are paid. With our approach to modularity and reversible decisions, choosing a specific payment method (especially a niche protocol like Superfluid) is almost certain to be the wrong decision. So, is there a way we can support both payment methods and/or allow for switching between them?
Starting with the auction, the bids for both approaches are almost the same. Both contain:
Therefore, bids from both approaches can actually be used against one another and are interoperable. This means some bidders can be using flows while others are using deposits, all without needing to know which method the current licensee is using.
One catch is the max license duration used in the deposit method needs to be equal to the constant license duration used in the flow method. It would not be fair for users using the flow method to be âoutbidâ by a bidder using the deposit method with a bigger duration.
One contract can track the self-assessed value and expiration of licenses, without collecting payments. Two different contracts can be used to collect payments that have the necessary permission to transfer the license.
Adding more details for the bidding process.
In both methods, a bid consists of:
A bid can be placed at any time, but must include a deposit equal to the current licenseeâs self-assessed value.
Once the open auction period is over, the winning bidder must send another transaction that:
There could also be a commit-reveal model, where the initial bid has the bid amount hidden, only to be revealed on the second transaction. There would be the following bidding stages:
If the current ownerâs deposit or flow runs out AND nobody submits or reveals a bid, the license is burned and the land is made available for other claims.
Here is my attempt at diagraming this in a state diagram:
And the version without commit-reveal:
In both approaches, one limitation is for someone who wants to control a license for a specific period of time (like for an event), they will most likely need to bid for the license at the start of the period that contains the dates they are interested in. This is most likely much earlier than the actual date they would like to start owning it. This could be mitigated by having a shorter License duration. A limit of say, one month, would give a bidder the opportunity to bid for their interested period no more than one month in advance, limiting the unnecessary fees they have to pay.
License duration
Awesome stuff @codynhat! Weâve chatted directly on earlier versions of this post and thereâs quite a lot here to pull together, so Iâll try to keep this response short-ish. Here are my high-level notes and questions:
License Duration needs to be less than a year to allow the market dynamics to work on a reasonable timeframe (a year at this stage might as well be a decade), and it shouldnât unduly favor those with more working capital. 30 days/1month seems right, but Iâm open to arguments for longer/shorter.License Duration as the auction period or trigger (not with a transaction, but with if/then logic) a shorter, fixed-length one. I lean toward the latter, so we donât have variability between 30 day and 1 day/second liquidation auctions.
We are forking off the conversation around periodic auctions here: