# GrayBox - KYC & AML
###### tags: `KYC` `Whitepaper`

## AML (Anti Money Laundering) and KYC (Know Your Customer)

We would have to hold our core values of privacy and anonymity. So we would have to think of some kyc function that plays in but covers the bad actor fraudulent exit. So as for how actor data is saved and verified we would have three groups. Platform founders, Token creators (company owners) an investors (token owners).

#### Platform Founders :
Identification will be public like any platform creation. This builds trust. (Unless your name is Satoshi Nakamoto).
Participation and development would require multisig and timelock agreements.
There shouldn't be an always available admin key (GODKEY). A similar process to the GrayBox implementation specified below can be used in creating timelocked godkeys. This is where delegates (of developers) can vote the timelock availability of a godkey locked in the grayBox.

#### Investors / Token owners :
We don't need their ID unless we are taking fiat and converting to tokens. This has strict KYC and AML regulations. So when they create their wallet and buy tokens the banks/exchanges already take their ID.

#### Token Creators (Company Owners) :
ID is put into GrayBox. In this case the GrayBox is like a Trust (Or Shell Company). This keeps Company ID but allows the company to mint tokens. However with less transparency the less trust is available. (We will have to figure out how this virtual Trust/Shell would work).
We can also have law firms work for/on the platform with their own tokens which companies can be verified with.
Or each company is verified by law firms that are liable for their actions.

## Here are steps in case we want to use the DAO to regulate in real time without law firms. (However law firms can participate as a node)

### Now our problem is what happens if Token Creator exits in a way that defrauds the rest of the token holders?
- So a GrayBox multi-signature ID extraction would function like any normal Trust/Shell Company related fraud. However much quicker.
- The signature percentage needed to open a GrayBox would not be a specific number but an equation. Your token amount carry vote weight. So vote weight + % of unique votes = GrayBox Keys. (scalable and quick execution) (More on this later).
- There are no quick withdraws of a high amount of tokens. The equation of risk vs withdraw amount. Some exchanges take up to 28 days. These are AML regulations. We will have to devise a way to quicken this AML investigation via use of ZKP over DAO.

### So the main question will be, how do we create a scalable regulatory system for quick token exit, via DAO?
- We can use a quorum slicing consensus algorithm which is also an available token. It is like insurance. So we have these P2P Regulation Tokens (we can change the name later) which you can acquire cheaply and avails you to scrutinize transactions. PRT is a sort of PoS - to regulate Token. You become part of the acting regulatory body. This group can only be formed by investors (token holders excluding exiting actor). This helps against sybil attacks.
- Unique regulators are chosen via a QS; selecting necessary delegates depending on availability. Delegate considerations include; available online, previous PRT work (Reputation), tokens held (high risk = better work), dashboard activity, and other attributes.
- Delegates with best delegate qualifications have highest chance of seeing actual exiting actor ID. Which means that each validator/regulator only sees what they need to see. There are different delegate classes depending on reputation. Any leaks will cause the loss of your PRT (P2P Regulation Tokens).
- Identity within a GrayBox (Trust) is in classes. Each tier is available to P2P regulators (DAO) depending on the risk factor of your exit.
- With only a few hundred holders of PRTs we can cut large token withdraw times to 1 day or less. This is 27 days faster than others.
- With the DAO regulating and approving withdraws, any bad actor leaving the scene will be at the hands of the DAO and each regulator will lose PRT & Reputation. Liquidated PRT should help alleviate bad actor exit.

### Assumptions: @Mothra
--For participants curating and coding on the platform.
- At the launch of the Smart Contract, the founders pledge a time frame their own tokens are released. The community can assume founders who have committed to a token lock up duration, will leave at the end of the duration.
- Such an individual can leave before the duration, understanding their token amount cannot be released until the initally committed date.
- Such an individual can also extend their relationship with the organization, by committing publicly through another token lock-up amount, to be reasonably determined based on the amount of extended time pledged.

#### Also possible for developer vs community trust agreement and transparancy :: @MarkFiji
we could have a donate back - timelocked - royalty feature? So you give 100% but 10% royalties for a period of time which are locked to only when you've done some agreed upon work. Then when you get your royalties in the native token to keep the market value alive or even move it up. The timelock is similar to the timelock stake tokens idea for developers but in this case the foundation isn't holding it but rather the community is. In reality the functions are on the same smart contract so the community at least feels like they are responsible for upping the value of the tokens so developers can work harder as they feel like they are paying the devs. And good work would mean the devs upping the tokens. Like a symbiotic relationship. When in fact its exactly the same function as a regular PoS timelock.

#### Godkey
Private keys are iffy. It depends on which door you're opening. The best bet for private key is via GrayBox so there are classes and those classes of keys are unlocked via smart contract during a vote. So different issues require different class votes. Classes being developers, token holders, company owners, etc. Big attacks that require votes quickly also go through the same process with a delegating quorum that can produce a 'god key'. These delegates already have staked tokens because they are in the dev team class and only a few from reputation weighted other classes. God keys are very controversial but with graybox I think we are fine.We can even have a stake buffer for developers where they have to put in more stake (into a timelock) for them to delegate a godkey quicker. We must keep in mind that because we are using cosmos, they do not verify events from ethereum. They are accepted into the cosmos state based purely on the signatures of current validator sets. So its possible for validators with more than two thirds of stake to purely create events in cosmos not existing on ethereum. So there needs to be an alert from both systems.

### Decentralized Docker @sascha1337
> **[12:20 PM] Sascha1337**: i had this idea of decentralized docker images that run on IOTA Qubics or AKASH that execute AI OCR and like the video verification of ID online - postident and save that data but hardcore encrypted with multisignature. Like DCMA, filehoster, can have bad data, but on Request especially if its crap everyone agree, its removed Start embedding iframe with {} at where you want to embed the note. Choose to embed a HackMD note and specify the note ID. [1:42 PM] Sascha1337: im already forking the hackmd open source thing and IPFSifying it plus the discord addons.
[1:43 PM] Sascha1337: can also store some indexing on IOTA testnet hornet community node implementation
push test net first, COSMOS SDK , based on tendermint
foundation -> tender -> cosmos -> EVM emulator cosmos module = Pegged $ATOMxCMPMNT coin able to list on BSC(edited)

## Gravity Bridges @MarkFiji

https://github.com/cosmos/gravity-bridge