---
# System prepended metadata

title: Solidarity

---

# Solidarity

## Motivation

...

## Init phase

Bob manually fills out a form (name, email, phone number,...) then he receives:

- a VISA debit card
- a badge with 2 faces: 
    - QR code pointing to his own Ethereum address
    - QR code pointing to the Splitter contract

## Workflow

*Scenario 1*

1. Alice makes a 10 DAI tx to Bob. 
2. Bob buys himself a sandwich. 


*Scenario 2*

1. Alice makes a 10 DAI tx to the homeless of Paris.
2. Bob buys himself a sandwich. 

*Scenario 3*

1. Alice uses Solidarity rDAI app.
2. Bob buys himself a sandwich.

*Scenario 4*

1. Alice uses an Ethereum service/app. She's ok to give 1% to the homeless of Paris.
2. Bob buys himself a sandwich. 

## Design issues

### Sablier

* Who pays for the gas?
* Define the behaviour when the contract receives tx in ETH, wETH, other ERC20s.
* Is the contract 'Sablier-friendly'?
* Do we want to update the stream in function of the articles bought by Bob? i.e. "*IF* alcohol, *THEN* cut the stream"

### DAO

* A DAO to replace `owner` (i.e. the ability to add or remove addresses). Ideally with access to `addAddr` and `rmAddr` of the Splitter contract. 

## What's happening under the hood

### Init phase

1. Bob gets his VISA card and 'QR card'
2. We open a 10 DAI/week stream

### Scenario 1

1. Alice makes a donation to Bob 
2.
3.
4.
5.

### Scenario 2

1. Alice makes a donation to the homeless of Paris.
2.
3.
4.
5.

### Scenario 3

1. Alice uses an Solidarity rDAI app.  
2.
3. 
4.
5.

### Scenario 4

1. Alice uses a service/app and gives 1% to the homeless of Paris.
2.
3. 
4.
5.

## Solidity contract description

Contract Splitter:

* import DAI contract

**Variables**

- `pool` is a mapping of addresses
- `owner` is the admin/association
- `vault` is the number of DAI held (only if there's *too much*)
- `active` is a bool (valid beneficiary)
- `start` is the amount sent to new beneficiaries

**Init**

* msg.sender is the `owner`
* `start`is set
* input the first beneficiaries' address
* the first addresses are active

**Modifiers**

* function `setStart`: only the owner can set `start`

**Functions**

* Fallback function: 
    * manage weird incoming tx
    * eventually triggers the `hold` function
    
- function `hold`: 
    - if too much money, then hold and reserve it for new registered addresses. 'Too much' = `start`* 4 * 6 (say `start`= 50 DAI, 'too much' = 1200 DAI )

* function `split`: 
    * when you receive a tx in DAI, divide the amount by the number of registered addresses in the pool and make a DAI tx to each one of these addresses.

- function `addAddr`: 
    - 1 address is added to the pool. 
    - If msg.sender is not `owner`, throw. 
    - If the contract is holding some DAI, send `start`

- function `rmAddr`: 
    - the owner removes an address from the pool

**Getters**

* function `activeBeneficiaries`: returns the list of active beneficiaries
* function `cashFlow`: total amount of DAI transfered to beneficiaries AND spent IRL


## Solidity contract (v0.1)

```





``` 


## To do (ETHParis 2020)

* Implement and test the 1st iteration of the Splitter contract (scenario 1 & 2)
* Publish the rDAI app (scenario 3)
* Pre-edit a function call (in JS) that send 1% to the Splitter contract. Any service can integrate in their frontend. (scenario 4)
* Define the KYC process
* Test the debit card thing
* Make sure we can integrate Sablier
* Create a UI to see the money flow
* Publish a website to welcome donations
* Estimate VISA costs
* Estimate gas fees
* Edit documentation

## The road to V1

*What do we want in V1?*

- Without merchant partnership (VISA debit card) OR with merchant partnership (Keycard)
- Sablier full integration
- Can handle ETH, wETH, BTU, rDAI
- At least 3 security audits (including KYC process)

## Debit cards & partnerships with merchants

If we can have only one merchant willing to accept DAI, we can use [Keycard](https://keycard.tech/) (by Status). 

Otherwise, we'll just use (and pay) VISA.

- Monolith: https://monolith.xyz/
- Contis: https://www.contis.com/

Here's what Monolith is saying:

> Akeel, [4 Feb 2020 at 13:46:20]:
> 
> Yes I’ve chatted with compliance around this on what i can say and what I can’t.  I think what could be useful is if folks signed up for monolith and got a card, that way you could KYC and also ensure they had a wallet/card which they could use.  Logicaly they could theoretically save the seed and only use it when they needed to log into the app and transfer from cypto to fiat
> 
> Defo for the kid example it could work, but there are age limits for signing up for a card (as its a bank account at the end of the day)
> 
> but would be good to troubleshoot, and I know we’ll be at EthCC so if its around the same time - could make sense to figure out a way to work together!"

## Story telling

* Defiscalisation des dons = x3 donations
* We give a debit card (loaded with 50 DAI) to people in need. 
* The [Tobin Tax](https://en.wikipedia.org/wiki/Tobin_tax) story: "In crypto, we love to undust old theories in economics and implement them thanks to the *almighty* blockchain."

## Project name suggestions 

- Safe Stream
- Sol
- SolidarityCard
- SCard
- Tobin
- Trikle down
- Trickle - ❤️
- Trickle DAO - ❤️
- Trikl
- SolStream - ❤️
- SoSoStream - ❤️
- SolidariTEE - ❤️

## Resources

- xDAI burner wallet: https://xdai.io/
- What's a 'burner wallet': https://www.xdaichain.com/for-users/wallets/burner-wallet
- My tests with Sablier
    - https://app.sablier.finance/stream/328
    - https://etherscan.io/tx/0x59ac0f08b54e1958e0ba22afb0c9098105f97a86bbd3ff0f47c178b0b3058d3c
* C-layer: https://www.c-layer.org/
* bDAI: https://btu-protocol.com/bdai/

## Schemes 

### Scheme v2

![](https://i.imgur.com/jrxjWBa.png)

https://docs.google.com/drawings/d/1Su9jkPbJfMxxev62a2FjdmNeP48X_pDuopeEHwIgCuY/edit?usp=sharing

### Scheme v1

![](https://i.imgur.com/Ot9Utou.png)

https://docs.google.com/drawings/d/1-mhC4jaGWBVQdSMHAiwMutXOExY7a4ie3KWc3z9EdPg/edit?usp=sharing


