Land Parcels Owning Assets

Protocol
1

This topic is to explore and discuss the idea of land parcels owning other assets.

From @graven’s original post:

Content on the Geo Web can be thought of as straddling two separate planes—the content layer and the property rights layer.

The content layer consists of the protocols and networks (currently Ceramic, IPFS, & Filecoin) that enable the information sharing required to publish and resolve content. This layer creates utility by organizing linked digital content for consumption on the Geo Web.

Content linking does not, however, create or necessitate explicit property rights (i.e. anyone can link to any digital content, tokenized or not). There are “Layer 0” social norms which limit the utility of linking someone else’s tokenized content, and Geo Web spatial browsers can help reinforce these norms through differential display of NFTs. But, true digital real estate development requires an enforceable property rights mechanism on the Geo Web that complements the content layer.

As of writing, Geo Web land parcels are ERC-721 non-fungible tokens. We need to implement an extension of the ERC-721 standard that allows the land parcels themselves to own other tokenized assets on-chain .

This concept has been explored by numerous projects in the Ethereum ecosystem and is commonly referred to as composable NFTs.

ERC-998 is a draft EIP, which includes different approaches to attach ERC-721 and ERC-20 tokens to ERC-721 tokens, that may serve as the basis for a Geo Web implementation.

The implementation of composable NFTs will also need to work in conjunction with the logic of the partial common ownership land market including license expiration, forced transfers, and parcel merges/splits.

Once there is an enforceable property right link between land parcels and downstream assets, the design space for digital real estate development will be wide open.

When a plot of physical land is purchased, the ownership of the house and its foundation are usually transferred with the land. The paintings and the furniture in the house aren’t, unless the sale is specifically structured to include them.

With composable land parcel NFTs, we can mimic this dynamic. Some content linked to a parcel will only be tied via the content layer. Its ownership isn’t included in a parcel transfer. Other content can be anchored with automatically transferable property rights and may be the main reason for a parcel purchase.

Entrepreneurial Geo Web land licensors may choose to anchor ownership of tokenized apps, art, architecture, games, etc. to their parcels to help grow their land value. They may also choose to keep content ownership separate and limit the value subject to the private common ownership market.

This is where investment incentives may play an important role in growing the value of the Geo Web land market.

2

Some of my thoughts on implementation and how this fits with the current architecture.

ERC-998 Asset Collection

A new asset could be created, call it an asset collection. This collection is a ERC-998 that is both top-down and bottom-up. It is bottom-up as it is an asset that knows it is own by a particular ERC-721 land parcel. It is top-down as it knows all the ERC-20 and ERC-721 assets that it owns.

This collection can be created without either the land parcel or existing assets needing to know about it. The latter is obviously needed to support owning all kinds of existing ERC-721 and ERC-20 assets. The former is needed to fit into the extensible architecture of the Geo Web.

The tokenId of the asset collection can be the same ID as the land parcel itself. This collection could never be transferred, except in the event of merging (see below).

nomnoml
nomnoml572×742 22.3 KB

Merging and Splitting

How would this work with merging and splitting?

During a merge, the asset collection of the parcel to be burned can be added to the asset collection of the parcel it is being merged into. This would result in a collection owning a collection, but can be done in constant time without iterating through all assets and transferring them one-by-one.

During a split all assets will stay owned by the existing parcel by default. The user should have the ability to transfer whichever assets they want to the new parcel that was split off.

We need to avoid assets being “lost” and attached to parcels that have been burned. One way to accomplish this is to have the Merger contract be aware of the asset collection, and make sure to transfer the old collection before merging.

Partial Common Ownership

Because it is the parcel that owns the assets, all these owned assets would also be under partial common ownership property rights. The original post also describes restricting these assets to forever be tied up in PCO.

What if a new licensor doesn’t want to own the parcel’s downstream content or wants to move it to another parcel? There must be a mechanism by which to separate assets from the parcel.

For this, we propose allowing licensors to split NFTs from a parent parcel by setting a separate self-assessed value for the asset. All of the requirements of partial common ownership can be applied to the newly independent NFT.

Some open questions I have are:

  • Can assets also be transferred within the Geo Web (between parcels)?
  • Can these assets be transferred to other PCO systems?
    • Hard to think of this, as none exist, but imagine a protocol built to wrap existing NFTs with PCO. Would assets be allowed to be transferred here?

It seems like the ethos is to add existing NFTs to the Geo Web to increase the value of the network to benefit everyone. If not that, then hopefully to keep the NFTs under some other PCO in order to increase the value of some other public good.

One way to implement this would be to restrict transfers to:

  • Other Geo Web land parcels
  • Some list of approved addresses

The approved list could contain a smart contract that implements a separate PCO system without land parcels built by the Geo Web, or similar existing systems. This list can be governed by the Geo Web.

1 Like
3

@graven With this approach, we can add this functionality later without needing any changes to the current ERC-721 license.

There will be a dependency, however, with the Merger needing to be aware of the ERC-998 collection. We could either:

  1. Build the Merger first, and later replace the Merger with one that knows about ERC-998
    • This would potentially be a breaking change to any Cadastre that uses the original Merger. Although we also discussed not actually needing the merging UI in the Cadastre yet
  2. Build ERC-998 first and a Merger, no need to update later
  3. UPDATE: Rebuild the ERC-721 license as a top-down ERC-998
    • Force assets to be merged upon merging licenses
    • Merger does not need to know about ERC-998
    • I realized we already need to rebuild this anyway to support burning/merging

What are your thoughts on which is needed for mainnet launch?

4

This is all great stuff! Thanks @codynhat!

I agree with the reasoning and proposed implementation here:

One way to implement this would be to restrict transfers to:

* Other Geo Web land parcels
* Some list of approved addresses

The approved list could contain a smart contract that implements a separate PCO system without land parcels built by the Geo Web, or similar existing systems. This list can be governed by the Geo Web.

The goal is to create a feedback loop between the efficiency of the Geo Web’s partial common ownership system and continued investment into assets (land or otherwise) subject to PCO. Moving assets between parcels satisfies this and so does creating separate PCO asset registries that fall under Geo Web governance. Over time the registries may evolve to have their own rules or even target use of funds, but they’d still be part of the same ecosystem/network.

1 Like
5

Option #3 means we can rebuild the ERC-721 as a 998, but that isn’t required. The required rebuild of the current contract is based on burning/merging functionality?

I’m super stoked about this idea and think it is an important long-term piece of the puzzle, but as long as it wouldn’t require a major rebuild/migration, NFT composability could come post-launch IMO.

6

Rebuild of the ERC721License is required for merging/splitting. Option #3 means the ERC-721 should be rebuilt as ERC-998 now. Options #1 and #2 don’t need the ERC-721 to be rebuilt because the Merger will know about ERC-998.

7

Based on our discussion today and assessment of the architecture and technical trade-offs, we are going to go with Option #1: build the merger/split functionality first, then down the line implement a ERC-998 asset collection architecture (or similar alternative). The top factors:

  • Rebuilding the current ERC-721 license as a 998 has limited payoff right now. ERC-998 isn’t an accepted standard as of yet and there are some advantages to having the 998 functionality be in a separate collection from the license. Most importantly this functionality can be added later without breaking the license.
  • Adding merge/split is important before launch because it would be a breaking change. We likely won’t have the functionality added to the Cadastre at first, but having it in the smart contract is sufficient.
1 Like