FATIP-200 Activation & Expiration Standard

[drkatz]

A small standard to define activation and expiration periods for tokens and other data in the FAT ecosystem. Forgive the branch name.

[PaulBernier]

The specification doesn't define what it means for an asset to be "activated". What can't be done when an asset is inactive? If 'active' is not specified in this fatip, then that spec should be even more generic and it would only define a generic time range that can be applied to an asset. If I want to define a time range by asset 'cookie' is 'edible', do we need a new FATIP to define a range of edibility? Probably not.

[drkatz]

Thanks Paul, This is intended to be a more generic protocol defining simple intervals of user definable behavior. The idea being that any inheriting spec can use it to define it's own rules, such as lock up periods, trade activation/deactivation times, expiration and the like. As you mentioned it's not sensible to require specs for every use case.

For example, responding to @nklomp's simple example on discord for defining when a inhabitant is allowed to start spending tokens, and when the spending period ends would involve having FATIP-0 or FATIP-0 inheriting spec inherit this spec in it's issuance entry definition. Then in it's transaction validation criteria you would specify that transactions with timestamps outside the defined range are invalid.

[drkatz]

Addressing this in a commit soon :+1:

[drkatz]

@PaulBernier A simplified example of the JSON + Spec one case of a double inheritance could produce, from FAT-1(note that FAT-1 is out of date at this time):

• Issuance entry extends FATIP-200
  • Token extends FATIP-200

{  
   "name":"mytoken",
   "symbol":"MYT",
   "tokens":[  
      {  
         "id":"a",
         "activation":1900010000,
         "expiration":1900090000
      }
   ],
   "activation":1900000000,
   "expiration":1901000000
}

If you wanted to inherit the spec twice for different purposes in the JSON's root (two separate time ranged conditions), this isn't possible without using different field names for each instance of inheritance. I believe it would be acceptable for the spec to do this as long as they are clear that they are aliasing the field names for such a purpose.

[PaulBernier]

Should the standard require that {activation, expiration} is always part of a describing field and not at the root? Like:

{
  spendable: {
    activation: xxxx,
    expiration: yyy
  }
}

And this way the spec avoid any collision.

[drkatz]

Deprecated: Activation & expiration are better use cases for smart contracts and can be easily implemented there once ready. If we decide to revisit we can always re-open