# 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://docs.google.com/drawings/d/1Su9jkPbJfMxxev62a2FjdmNeP48X_pDuopeEHwIgCuY/edit?usp=sharing

### Scheme v1


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