In order to support merging and splitting, there is still some missing primitives in the existing contracts.
ERC721License
Burning
Needs to support burning a license for after a merge
Potentially support merging assets at the time of burning to avoid “lost” assets
ETHExpirationCollector
Reallocating funds
Needs to support reallocating existing funds from one parcel to another
Both whole reallocation (merging) and partial reallocation (splitting)
Removing expiration
There is currently a minExpiration that prevents setting an expiration to 0
Should we support “clearing” the expiration by setting it to now?
Reclaiming?
The original requirements specify that a path given upon merge should only contain coordinates from both existing parcels. Similarly, a split operation should only include coordinates that were in the original parcel.
In practice, this will be difficult to enforce. Perhaps we should think about this as “reclaiming” at the contract level instead of merging and splitting.
“Merging” is really about taking two or more existing parcels and replacing them with a single parcel made up of coordinates either not claimed yet or in one of the existing parcels.
“Splitting” is really about taking a single parcel and claiming a new parcel that is made of coordinates not claimed or from the existing parcel.
The concepts of merging and splitting without including new coordinates can be done at the Cadastre layer. The user can select coordinates to merge, and the Cadastre can find a path.
To me the term “reclaim” still has a connotation that the coordinates that make up the new parcel were previously claimed (i.e., they come from the previous path). Depending on the structure of transaction might it be closer to an “exchange?”
If the parcels created from a merge/split/reclaim/exchange don’t have to include at least some of the same coordinates as the previous parcel(s) then these functions could be used to move deposits, parcel history, etc around the globe without any friction. This may or may not be a bad thing. Currently it’s hard to come up with “normal” reasons someone would want to do this, so the conservative approach would be to have some limits to the the mobility of parcels with these functions.
Notes after Discussing with Cody
Most of the discussion centered around the merits of requiring the base coordinate of a parcel’s path to be conserved when extending, trimming, splitting (one parcel keeps the base coordinate, other gets a new one), and merging (user chooses which of the base coordinates to keep). This seems like a reasonable restriction for now that we can adjust later as needed.
If it just happens to be that the base coordinate is included in the part of the parcel that a use wants to trim, we’ll need to require a new token ID to be created with a new base coordinate as part of a multi step function (burn the original license & transfer its deposit/content to a newly created one)
For now, only admin contracts will have the ability to burn a parcel license
Discussed the “right to exit” in the context of a future federated governance model defined by geography. Might someone want to move their network fee deposits to the other side of the world due to a localized governance change? This type of behavior should be protected/enacted in a different layer of the stack, but it’s something to consider as we develop.
MEV scenarios came up—could a current licensor basically sandwich attack a prospective buyer by changing the path of a parcel (move to a diff place, exclude some or all of the desired coordinates) just before the purchase goes through then back run the purchase transaction with a claim of part or all of the original path? This sort of thing seems inevitable and again should be addressed with more comprehensive logic and protections in other parts fo the stack rather than merge/splitting logic being capable of solving it.
This is really good. I think it definitely succinctly captures all the permutations of the rules we’re going for.
I’m trying to wrap my head around a good heuristic for the difference between a TO and FROM coords columns. In a SPLIT operation the difference makes perfect sense. It’s not as clear to me why the MODIFY operation utilizes TO & TO rather than FROM & FROM? Does it matter?
Yeah that’s where my head was at. It seemed more consistent with the SPLIT operations. The naming convention is really helpful with some operations, but others its a bit closer to just Parcel #1 & Parcel #2.
In the Summary section, you had the following statement:
The “coords” columns specify which sources the FROM and TO parcels may contain coordinates from
Is that saying that basically saying that coordinates within these one or two parcels are already claimed, but they are eligible to be reconfigured/used in this operation?
Yes. Basically any parcel with YES will be “freed” before the new path is traversed, and can thus be included in the new path. But this is all done atomically in the same transaction.