Feat/add general approach #9
Conversation
| @@ -0,0 +1,122 @@ | |||
| --- | |||
There was a problem hiding this comment.
Can we make it more specific than "general approach"? It doesn't seem very concrete :D
If it is more of a research notes, maybe we should put it as research notes?
| status: draft WIP | ||
| --- | ||
|
|
||
| # Investor Onboarding |
There was a problem hiding this comment.
At a high level, it seems like this document splits into
- Investor Onboarding
- Asset Issuance
- Order Discover And Matching
- Regulator onboarding
- Private Data Oracles
Perhaps we can split that up into those four areas?
E.g. how to approach <this ~problem>
There was a problem hiding this comment.
I think we can make this like an index to different approaches/patterns?
can also split into "how to approach <this ~problem>" for easier navigation as well
| - manually through the offchain component of the bank, where the investor can do traditional KYC/AML and indicate the EOA for the bank to add to a list of whitelisted EOA via sending a transaction to a smart contract, this can be pretty trivial technological-wise and there is no privacy leakage beyond the fact that the onchain ID is for the specified Bank that whitelist the EOA; | ||
| - automatically through an onchain smart contract, where the investor can send an EOA along with a proof of KYC/AML compliance, and upon successful verification, the EOA will be added to the whitelist, such a proof needs to be privacy-preserving, i.e. the proof is unlinkable to the wrapped ID, aka a zkID presentation to the smart contract. | ||
|
|
||
| To preserve the anonymity of the EOA, we can leverage Stealth Address, i.e. instead of whitelisting the EOA, we can whitelist the Stealth Address, this allows the sender to derive a receiver address from this Stealth Address. |
There was a problem hiding this comment.
I think that's a good point, users should have the option to use multiple addresses by default, stealth address is an option; This could also be achieved by signatures + ZKPs;
| - PKI for Banks, can be done similarly to ENS | ||
| - Per Bank, a PKI of its onchain assets (also ENS for its onchain assets but under Bank?) | ||
| - To issue an onchain asset, it can: | ||
| - create an ERC directly; |
There was a problem hiding this comment.
Maybe we can specify here for clarity ERC-{20, 721, 1155} for example
3 participants
A technical slicing of implementing institutional privacy requirements