fcolavecchia
commented
6 years ago Aragon Nest payments with fluidCash
A nice feature is that providers do not need to be different!
Let's assume that developers Steve (a0x=0x4170706c65...) and Bill (b0x=0x4d6963726f73...) uploaded an awesome project for funding to Aragon Nest. This proposal is so good, they get the funding, at a burn rate of 70 ETH/month(!). Aragon Nest can define a fluidCash as:
s0x = (0x61726167 ...), for the Aragon's funds address,
p0x = (a0x, b0x, a0x, b0x,...), for Bill's and Steve's addresses, and
PETH = ( 40, 30, 40, 30, ...) for the distribution of the burn rate.
Setting up a monthly time condition in the cl array, Aragon can deliver payments of the Nest project at the specified burn rate with fluidCash.
(disclaimer: I am a developer at fluidCash....).
mariapao
renexdev
Aragon Nest Proposal: fluidCash, a layer for liquid payment in Aragon
Abstract
The blockchain technology has brought unimaginable ways to conceive how an organization can be run and governed. The decentralized autonomous organizations(or DAOs) [#DAODef] concept is a powerful example of that. The DAO model aims to empower organizations with transparency and decentralization of their governance structures (through liquid democracy[#liqDemDef] for instance). One approach to the DAO schema is currently being implemented and developed by the Aragon project as defined in their white paper [#AragonWP]. Despite the several advantages that DAOs present, introducing novel manners of running organizations to society could represent a great challenge. Our society is already accustomed to an existing system that somehow works, even though cumbersome and obscure.
A massively DAO adoption is far to be a reality nowadays, but creating a softer transition to what people could start to use may change the trend. One way we can prompt society (thought as a multiple communities) to use DAOs, is by introducing transparent and agile payment mechanisms for exchanging value.
A very common situation arises when organizations offer services to individuals (or group of them) involving many actors in the service's chain. For a complex service's chain the actual system works with hidden intermediaries that brings many problems at the time to estimate service's costs, or when the service fails. For instance, when a client needs to known when the service is ready to use, or when the provider has to collect her/his reward. We propose addressing these challenging problems introducing the concept of fluidCash into Aragon. fluidCash will be a seamless layer for tokens transfers, where multi-peer to multi-peer(or m2m for short), transactions are involved in the payment processes.
[#DAODef]: Decentralized autonomous organizations, Wikipedia.
[#liqDemDef]: Liquid democracy, Wikipedia.
[#AragonWP]: L. Cuende and J. Izquierdo, Aragon Network: a decentralized infrastructure for value exchange.
fluidCash
An entity (or a group of them) [#EntitiesDef] that belong to a DAO can exchange value by providing or subscribing to a set of services. In this context, the actors involved in a generalized chain of service can be defined by four vectors storing the subscriber's addresses, the provider's addresses, the subscriber's costs and the provider's rewards as follows:
s0x =(s1, s2, ..., sN) for the subscriber's addresses
S$ =(S1, S2, ..., SN) for the subscriber's costs
p0x =(p1, p2, ..., pM) for the provider's addresses
P$ =(P1, P2, ..., PM) for the provider's rewards
In the current model the service will be a set of ordered payments P$ to each of the providers p0x. To manage the payments we define a conditional logic array of size M (the same size as the provider's vector involved in the service's chain):
cl (s0x, p0x, tend) =(cl1 ,cl2 , ..., clM).
that establishes the conditions to authorize payment to each provider. Each clk component, with k = 1,2, ... M, contains the signature (voting) logic function F() that receives an address argument and returns a true/false (1/0) value, whether this address agrees to the payment or not. The vector tend represents an additional condition for an execution time in each clk, such as time[#timeblocks] must be less than the predefined tendk.
Once the actors are defined, the service consist of a bundle of several peer to peer transactions that we call drops. Each of these drops has a signature (voting) logic, the actor's address, and the actors's expected reward. A particular service's chain is completed when all the M drops are executed. The signature (or vote) of the drops is built in the cl array as a set of logical operations between the input signatures (or votes) F(s0x), F(p0x) and service timeout conditions. The cl(s0x,p0x,tend) array will be instantiated with specific addresses and payments that must be triggered in each drop.
fluidCash, defined in the precedent paragraphs, is a general multi-peer to multi-peer chain of payments where time is an additional actor. fluidCash is an concept that generalizes the simple exchange of tokens, and could be understood as a tree of multisig transactions with multiple outputs.
fluidCash provides a very general way to model payments, although we conceive fluidCash within the context of an Aragon application. Therefore, the amount of tokens that the service requires to proceed are obtained from the Vault with the proper permissions given by the Kernel. Moreover, the fluidCash layer can be used to model very complex payment processes where one of the payees in the main service's chain can trigger another fluidCash instance.
On the payee side, the drops (that is, the amount of tokens each participant in the service claims), can be collected by the providers involved once each service step chain is completed. This can be interpreted as the default behavior, but, again, many other outcomes can be instantiated, such as payments dependent on previous ones. In a similar fashion, if the chain is broken, the next payment steps can be halted and the token returned to the organization vault. Or partial payments can be send to those providers that accomplished their work delivering the service. All these possibilities can be defined within cl(s0x,p0x,tend).
The abstraction of fluidCash is a boilerplate to very different payment processes, such as healthcare practices, academic courses, package delivery, payroll, etc.
[#timeblocks]: The earliest block number mined with that operation.
[#EntitiesDef]: According to Aragon documentation, an Entity is any actor that is represented by an Ethereum address, such as a multisig (an account that needs multiple signatures before executing an action), an app, or a simple private key controlled account. https://wiki.aragon.one/documentation/aragonOS/#entity
fluidCash has the following specs:
Case Study: healthcare
Let us assume that Bob (0x12...) does not feel well, and decides to see his primary care doctor, Alice(0x34...). He schedules an appointment with her. At that point, a medical service starts and the fluidCash mechanism is put in motion. Bob, as a patient signs (votes) to start of the service (and collapses who will be the actors for such a service), enabling the allocation of tokens for it. Besides, all the payees addresses are included into the m2m transactions: doctor(0x34..), office assistant(0x56...) and the hospital(0xAF...). The fluidCash mechanism instantiate the following arrays:
s0x = (0x12...), for the subscriber's address
p0x = (0x34..., 0x56..., 0xAF...), for the provider's addresses
The amount of ANT's for the specific medical care practice are stored in the vector:
PANT = ( 60, 10, 30).
In the same way, the total cost for the service (100 ANTs) is obtained from the required payments PANT, such that SANT= (100).
In this example there will be three drops: one for the doctor, one for the secretary and another one for the hospital and two signs (votes): one in the patient's checkin (at tcheckin) and the other when the doctor ends the consultation (at tend).
The signature (voting) logics for this service would be the following
cl (s0x,p0x,tend)=(cl1,cl2,cl3)
where the components are
cl1 = F(0x12...) && F(0x56...) && (t1 < tcheckin)
cl2 = F(0x12...) && F(0x34...) && (t2 < tcheckin + tend)
and
cl3 = cl2.
The function F(0x...) evaluates to true or false (1 or 0) when address 0x... signs (votes), while && represents the logical and operator. When Bob arrives to the doctor's office, he checks in with assistant Charles (0x56...) at time t1, the first drop is executed and payment to Charles is signed: Bob agrees that the service has started while Charles acknowledges that Bob checked in. This conditions set cl1 to true and the first payment is released. When Bob's finishes his visit to doctor Alice at time t2, a second drop is executed, also signed (voted) by Bob, accepting that the medical service has been provided, and by Alice, the care provider. This conditions set cl2 to true and Alice and the hospital get the payments for the service, because the payment condition is the same. Since all the initial tokens in SANT were dropped, fluidCash finishes.
Deliverables
fluidCash layer implemented in a set of contracts with the following features:
A basic Aragon-app that allows end-users to easily setup services payable by fluidCash.
A set of tests for common user cases
Grant size
Funding: From $42.3k in ETH, payable monthly.
Success reward: Up to $12k in ANT, given out when all deliverables are ready.
Application requirements
The Team:
See team.md for further details.
Legal structure:
Open Source
Development timeline
Three quarters along 2018 scheduled as:
First and second quarter
Second and third quarter
We aim to have a close and fluid relationship with Aragon-dev team in order to fulfill all Aragon compliance requirements.
Future work:
Incorporate the use of discount coupons for a particular service.
Incorporate a layer for multi token payment. Flipper0x?
Compatibility with future ERC proposal ERC-721?
UX integration of the service app
Further notes:
We will be glad to discuss and improve any point of the present proposal.