ERC994: Delegated Non-Fungible Token Standard

[Physes]

Delegated Non-Fungible Token Standard

EIP: <to be assigned>
Title: Delegated Non-Fungible Token Standard
Author: Philip Saunders <philip@nuhanse.network>
Type: Standard
Category: ERC
Status: Draft
Created: 2018-03-15

Simple Summary

Delegated Non-Fungible Tokens (DNFTs) are a proposed extension of the ERC721 standard designed with the use case of Ethereum-based registration of land and physical property in mind. NFTs are arranged in a federated, tree-like format (similar to DNS) where NFTs can delegate and sub-contract NFTs within a certain geospace.

Unlike digital assets (like CryptoKitties) physical property requires more than just an accurate identification in a database- it also requires legal validity within the context of physical sovereignty. DNFT zones can established by land registry authorities as a root DNFT encompassing a wide area, and can delegate DNFTs as subdivisions of the root zone to existing property holders as a way to upgrade land registries. This is intended to secure the following essential features:

• A non-conflicting geospace

• Legal validity and physical sovereignty

• Compatibility with financial contracts

Abstract

Non-Fugible Tokens were proposed as a way to give identity to external objects on the blockchain. There have been some speculative use cases for digital assets already created, however NFTs have inherent limitations as a standard to apply to physical property. DNFTs add two basic features- writs, which is a fungible representation of geospace that can be delegated. Writ quantities are recorded as an unsigned integer. In addition, there is height variable (also an uint) which represents the level of delegation (1st, 2nd, 3rd, etc.).

Motivation

To implement Non-Fungible Tokens as part of a comprehensive protocol for land and property registry- extending the functionality to allow root ownership by a zone authority, delegation of "child" NFTs (representing regular property rights) as a subset of a root NFT, as well as to incorporate a fungible quantity variable to provide a delimiter for delegated tokens.

Specification

A DNFT contains five elements:

1. A token ID. Every DNFT is identified by a unique unsigned 256-bit integer.

2. An owner address. This can be either an externally owned account or another smart contract (ordinate).

3. A metadata field. We specify a schema for deed files called ZML- Zone Markup Language.

4. A height variable. This represents the level of delegation.

5. A fungible unit of account (writs) which provide a delimiting factor on delegation.

A fungible unit of account is necessary so that zone implementors cannot delegate more land than what is under management.

The following is a diagram of an example DNFT zone implementation, with a delimiting number of writs and delegated from the root zone to four levels of abstraction.

Ordinates

DNFTs can be owned by other contracts, allowing for the creation of complex conditional agreements around property. In the Zone Protocol these are called ordinates. Ordinates can split ownership of a DNFT among multiple stakeholders using ERC20 tokens, and you can also create ordinates for things like lease agreements, rent contracts, property options and more.

Fungible Quantity Units (Writs)

DNFTs have a fungible quantity variable, which represents the amount of base geospace assigned to the property right. Writs are a two-dimensional unit of account (i.e. m^2). Alternatively a zone can opt to implement a three-dimensional unit of account (m^3) if desired. This means that a zone of 10000 m^2 containing 10000 writs at the base level could delegate (for example) 10 land leases, each with 1000 writs. It should be noted that writs are not meant to specify the actual boundaries; i.e. they do not have coordinates and are interchangeable. It is the associated deed file that contains all of the boundary info. Writs or cubits are simply a delimiting mechanism that describes the maximum amount of geospace that can be contained within the deed file.

Delegate and Revoke

There are two basic functional additions to ERC721: the ability to delegate and revoke. "Revoke" can be interceded by an ordinate contract which holds ownership of the DNFT between the leaser. This would prevent arbitrary revocations of property rights unless under pre-agreed terms (i.e. at the end of the term of a rent contract). For a freehold a similar ordinate would also be used on a permanent basis.

Proposed Interface

pragma solidity ^0.4.17;

/// @title DNFT Delegated Non-Fungible Token Standard

interface DNFT is ERC721 {

	/// @dev checks if _from is a delegate of _tokenId.
	function origin(uint256 _from, uint256 _tokenId) public view returns (bool);
	
	/// @dev gets the abstraction depth of _tokenId. 
	function getHeight(uint256 _tokenId) public view returns (uint256);
	
	/// @dev returns the balance of fungible geospace.
	function quantity(uint256 _tokenId) public view returns (uint256);
	
	/// @dev allows tokenholder to delegate new DNFT.
	function delegate(uint256 _tokenId, 
		uint256 _quantity, address _to) public;
	
	/// @dev allows owner to revoke a delegate NFT.
	function revoke(uint256 _tokenId, uint256 _delegate) public;

	/// @dev emitted whenever a new DNFT subdomain is delegated.
	event Delegate(uint256 _from, uint256 _tokenId, address indexed _owner);
	
	/// @dev emitted whenever an DNFT subdomain is revoked.
	event Revoke(uint256 _tokenId, uint256 _delegate);
}

origin:
Checks if the "from" tokenId is the child DNFT of tokenId. Returns bool.

getHeight:
Returns the delegation height of tokenId.

quantity:
Returns the number of fungible geospace units left to delegate.

delegate:
Allows the owner of a tokenId to delegate a new DNFT with a certain amount of geospace to a new owner.

revoke:
Allows the owner of a parent DNFT to revoke ownership of a child DNFT. This feature can be overridden by an ordinate contract.

Delegate (event):
Emitted for new token delegations.

Revoke (event):
Emitted on token revocations.

Rationale

The rationale of DNFTs is to provide object identities for physical property within zones.

Backwards Compatibility

DNFTs are compatible with ERC721 NFTs.

Implementation

Current working implementation as part of the Zone Protocol: https://github.com/Physes/DNFT.

[jewishmexicanguy]

Currently GPS is the most ubiquitously used positioning system. However, more secure systems and more accurate systems may arise. With this in mind, would multiple positioning systems be supported? Would this be up to the discretion of Multi Signature Root Authorities and the Sovereign entities in which they reside in?

[Physes]

The advantage of using an XML-based schema standard for metadata is that you can specify a "type" attribute for geolocation. In this case the type would be "GPS", then you could specify all of the relevant points. In the case of mulitiple positioning system you would specify it as "GLONASS". The main point is that once you have a large-scale zone, zones can't overlap. But that's a matter for the governance of the zone creation process.

[shrugs]

I like this. It might make sense to chat with FOAM about how they're tackling a similar problem.

re: implementation: I'd recommend extending your DNFT contract from ERC721Token and overriding methods rather than reimplementing it with different storage variable names. Any reason you chose otherwise?

I'm not super jazzed about the name; the token can be delegated, sure, but it's not the delegation that makes it unique, it's the fact that the NFT represents physical space. Any other naming options?

I'd also question the need for an XML-based metadata property. First, the contract should confirm to the ERC721Metadata interface which means returning json with various properties. You should add a custom type to the JSON Schema like geo and have that be the geo-specific metadata. My interface that only knows about name/desc/image should still be able to display your NFT tokens "correctly".

There's even an example gps type for JSON schema: http://json-schema.org/example/geo.json

[Physes]

I think FOAM might be dealing with a slightly different problem: namely an alternative coordinate system to GPS. Personally I don't see this as an urgent problem as GPS works pretty well, however I'm certainly open to collaboration. Where something like FOAM could be useful with the Zone Protocol is as the source of coordinates in the deed file- however it would work just as well to use GPS in my opinion.

I agree with extending ERC721, I'd like to take that approach. Basically what DNFTs would do is add extra mappings for the height, quantity and "parent DNFT" aspects while retaining the same lookup process for owner and metadata. I don't see a problem with that.

ZML could be done in JSON, however the reason why I chose that was inspired by Google's KML (Keyhole Markup Language) approach. Also having a "type" attribute for elements allows you to specify the protocols that you're using for things like identity and boundaries. For example:

<boundaries protocol="GPS">
    <point>
        <latitude>XYZ</latitude>
        <longitude>XYZ</longitude>
    </point>
    <point>
     ...
    </point>
     ...
</boundaries>

And for the identity component, i.e. <titleholder protocol="PGP"> XYZ</titleholder>. (with flexibility to allow for varying identity protocols/indicators that might be used within this element).

However it would be good to explore an implementation of ZML in a JSON schema also.

[AFDudley]

Mirroring what @shrugs said, I strongly recommend using https://tools.ietf.org/html/rfc7946 instead of inventing your own standard for encoding geographic data structures. I also strongly recommend leveraging OSM and the existing infrastructure around that. Hopefully, @kejace or @awright can chime in with some feedback.

[Physes]

@AFDudley I'll definitely consider that. Deed files are both for the purpose of geographic data structures and identity as well as other relevant factors. I've considered a few OGC (Open Geospatial Consortium) standards also both in XML and JSON but none seemed to have all the necessary requirements. I also considered just using a KML file. But this is a good question that will need further thought.

[mryellow]

First, the contract should confirm to the ERC721Metadata interface which means returning json with various properties. You should add a custom type to the JSON Schema like geo and have that be the geo-specific metadata

Agree that JSON and following ERC721Metadata is the obvious choice. XML overhead made it unsuitable for the task and it really has lost the war.

When dealing with geospatial geometry and coordinate systems another option is GeoJSON:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [125.6, 10.1]
  },
  "properties": {
    "name": "Dinagat Islands"
  }
}

http://geojson.org/
https://tools.ietf.org/html/rfc7946

edit: Of course all this doesn't matter as you're only putting a uri hash to lookup on IPFS or something.

[Physes]

I just wanted to delve into more detail on the "parent/child" arrangement of DNFTs in the implementation. I'm not sure this is the best way to do it but it seems to make the most sense.

Basically, instead of the parent keeping track of its delegates (children), each DNFT keeps a record of its parent via the parent mapping, which maps the tokenId of the child to the tokenId of the parent:

 // maps child delegate token to parent ID
  mapping(uint256 => uint256) private parent;

In the standard interface this is accessed via a public view method isParent:

function isParent(uint256 _child, uint256 _parent)
      public
      view
      returns (bool)
    {
      require(parent[_child] == _parent);
      return true;
    }

I'm not sure whether there should be something mapping in the other direction. The reason I wanted to do that was that normally tokens would be delegated via an intermediate ordinate contract which would manage it on behalf of both the parent and the child externally, laying out various conditions or limitations (such as blocking revoke for a period of time).

EDIT: Another reason for not needing to keep track of all children is that this information is going to be cached in each Zone's Deed File System (DFS). The plan for the DFS is that deed files (metadata documents in ZML) would be cached in a hosted git repository, so it would be fairly easy to track the chain of ownership up through the tree without having to implement it in the contract. However isParent is necessary to enforce security requirements for the revoke function.

The full range of mappings (which includes regular NFT and extends with three extra mappings):

  // maps token id to owning address
  mapping(uint256 => address) private owner;

  // maps token id to string metadata uri
  mapping(uint256 => string) private metadata;

  // maps token id to fungible quantity units.
  mapping(uint256 => uint256) private quantities;

  // maps child delegate token to parent ID
  mapping(uint256 => uint256) private parent;

  // maps token id to height index
  mapping(uint256 => uint256) private height;

  // maps token id to approved address
  mapping(uint256 => address) private approvals;

  // maps token id to list of owned tokens
  mapping(address => uint256[]) private inventory;

  // maps token id to the index of owned tokens
  mapping(uint256 => uint256) private index;

[Physes]

Hey everyone, so the white paper for The Zone Protocol has been published, explaining the background of DNFTs:

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3180835