FATIP-201 Address Workflow Standard

[drkatz]

This standard defines a mechanism for classifying addresses and for controlling the flow between address classes. The standard uses a simple graph structure to define the relationships between address classes, allowing for arbitrary class workflows to be enforced in a token economy.

This proposal can be discussed on the FAT Discord: #201

This standard & PR is meant to lay the groundwork for collaboration with real potential end users of the FAT token system. A consensus will be reached on a medium of simplicity & specificity for this standard which allows it to cover a majority of use cases, without excessive or overly specific functionality.

A simple summary of features in the initial PR (* = future):

• Define address classes:

  • User defined address classes
    • Absolute token balance limit
    • Metadata
  • burn - The class representing the token burn address
  • general - the set of all addresses not covered by the above sets

• Define address class workflows:

  • Place directed edges between classes to define trade
    • Class cycles (A => B => A) and self cycling (A => A ... => A => B) are allowed to denote inter class trading and middleman enforcement
  • In the future be able to set transfer rate limits (tokens/block for example)*

• Assign an address to a class on an address by address basis:

  • Define token balance limits on an address by address basis, overriding class balance limit.
  • Metadata
  • In the future be able to set transfer rate limits on an address by address basis (tokens/block for example)*

• Update syntax & operation:

  • Update/add address class,
  • update/add/remove participating address in class
  • update/add class workflow

[PaulBernier]

I don't see in the spec the resolution of class conflicts being mentioned. If an address is part of 2 classes, with different rules, we should have a paragraph about the priority rule I suppose?

[nklomp]

• Wouldn't it be more clear in the example to place the coinbase after the government? It is the government in the example providing the coinbase to the recipient.

• If you want to use aid as an example, which in itself is a nice example of a system like this, it might not be really wise to allow recipient cycles ;)

• I find class a bit confusing, but that might be me. It suggests to me you have other address classes besides FCT, which Factom has. So maybe something like "Role" would be a better fit.

• I am not convinced of the class - class relationship as it is modeled now, would prefer tuples in one object and have that as an array or suboject, as it would be way easier to extend in the future (will elaborate more on the discord channel). Also it isn't immediate clear that the class actually means recipient-class or target-class in the workflows part.

[drkatz]

1. Coinbase should not, and actually can not come after any other node. In the graph it represents the abstraction of birth of tokens into the ecosystem, if you will. The coinbase transactions could certainly be issued directly to the recipients, or they could be issued to the government's accounts for distribution over time. Regardless, It's important to note the issuer is not necessarily any node in the graphed class relationship. The issuer is merely some authority "pulling the strings" of the token dynamics in the implementation of the spec.

2. Sure, sorry for piggybacking your original example. I feel it's important to include some type of cyclic relationship in the base example to demonstrate the capabilities of the standard, but this can be revised in name to make it align better with that example.

3. I'm not great at naming things heh. I like "role" but let me brainstorm to see if we can't find something even better

4. Let's talk on discord, interested to see your elaboration on using tuples(or here is fine too!).