owned this note
owned this note
Published
Linked with GitHub
# NEAR Human Community SBT
###### tags: `NDC`
Author: Robert Zaremba.
Repository:
## Summary
Near Social Polls is the first smart contract to get feedback for the community related to the NDC creation of all related protocols. Requirement is to verify humanity, and only let humans to express the opinion. The Near Social Polls is not a governance body. It's main mission is to measure community opinions.
This is the first version of the "i-am-human" protocol for the [NDC DAO](https://hackmd.io/NlFbUcC6TsaeLr7oAAdtdw?view) -- see this document for more details.
Note: Near Social Polls doesn't conflict with the proposed [NDC DAO](https://hackmd.io/NlFbUcC6TsaeLr7oAAdtdw?view). In fact, the NDC DAO also proposes Polls as a support mechanism for measuring opinions.
## I Am Human
The protocol will consist from the following smart contracts:
1. SBT Human Community -- a DAO smart contract issuing a Human SBT (details below).
2. I-am-human smart-contract: An algebraic class representing the ever-evolving proof of humanity
3. Blocklist
2 & 3 are described in the [i-am-human spec draft](https://hackmd.io/@robert-zaremba/Sy-t503li#Specification).
## SBT Human Community DAO v0.1
Issuer and maintainer of the Human Community SBT.
Functionality:
1. The contract will contain a list of highly reputable accounts: admins. In the initialization we will provide the initial set of addresses representing know, reputable people. They have to be KNOWN in the sense that they have made several appearances *on screen* in working groups such that their characteristic face and/or voice is known to several others, and REPUTABLE in the sense that they are *constructively* participating members of the Near community with opinions that are generally heeded and respected by several others.
2. Admin can add new admins with approval of 2 other admins.
3. Admin can remove existing admin with approval from 2 other admins.
4. Any admin can issue an SBT to any NEAR address.
5. Any admin can revoke an SBT from any NEAR address.
Registration:
1. Anyone can register using TypeForm
### DAO functions
Parameters
```rust
admins: LookupSet<AccountId>;
admins_to_add: LookupMap<AccountId, u8>;
admins_to_remove: LookupMap<AccountId, u8>;
/// minimum amount of approvals to add or remove an admin
min_admin_approvals: u8;
/// maximum duration in seconds for an SBT before it will reach expiration
max_sbt_ttl: u32;
/// address of blacklisted accounts
blacklist: AccountId
```
Admin functions:
```rust
/// Any admin can add a new `proposed_admin`. Once the `proposed_admin`
/// will get enough approval, he will be added to `self.admins` set.
/// If this is the first approval, then a new entry in `self.admins_to_add`
/// will be created.
fn add_admins(&mut self, proposed_admin: Vec<AccountId>);
/// Any admin can request to remove any existing admin.
fn remove_admins(&mut self, proposed_admin: Vec<AccountId>);
/// admin can issue new SBT. One holder can have only one SBT.
/// Panics if the receiver already owns an SBT or is blacklisted.
fn sbt_mint(&mut self, receiver: AccountId, ttl: u32);
/// any admin can renew and extend an existing SBT
fn sbt_renew(&mut self, holder: AccountId, ttl: u32);
/// any admin can recover an SBT, by moving it to a `new_holder`.
/// `old_holder` will be added to a blacklist.
fn sbt_recover(&mut self, old_holder: AccountId, new_holder: AccountId, ttl: u32);
```
Queries:
```rust
fn sbt_total_supply(&self) -> U64;
fn sbt_token_for_owner(&self, account: AccountId) -> Option<Token> {}
/// returns list of admins
fn admins(&self) -> Vec<AccountId> {}
```
We will also implement all other functions mentioned in the proposed SBT [NEP-393](https://github.com/near/NEPs/pull/393).
### Known Issues
Below we list known issues, which we won't address in v0.1 (PoC), but we will address them in v1.
#### Registration
In v1, we don't have a clear way how use will register himself, and how admins will pick up his registration. Noak is creating an off-chain flow for that.
#### Recoverability
Recoverability is a function to recover SBT in case user lost acccess to his account or the account was hacked.
Unfortunately, recoverability in v1 doesn't work because we can't re-verify user (since we don't store KYC data, we can't verify claims).
## Version 1 (or v0.2)
TODO:
+ Upgradeability mechanism.
+ We will need to decide who and how can upgrade the smart contract.
+ update admin process (maybe we don't need admins?)
### Drafts
Ideas to be used for v2 design
#### Registration
on chain submission with a small fee. Then any admin can "pick" the application, and he will receive a fee back to his account as a small reward. But the fee should be small. Maybe 0.5 N? 0.005 N will be charged for the storage fee.
+ what information do we need to store for registration? Any personal information?
#### Recoverability
We should have sort of recoverability. Few ideas:
1. Store hash of verification documents on chain. Once a user wants to recover his account, he needs to present the documents again to the verifiers and the verifiers check if hash of the documents (in alphabetic order) matches the one stored on chain. Maybe, to increase a useability, we should have a map of hashes (document name -> hash)?
2. Other idea is to have kind of Merkleized KYC data.
## Considerations
+ This is one of the DAOs for the Near Proof of Human (aka I-AM-HUMAN)
+ The proposed protocol should be extended with other SBTs, like facial recognition.
## TODO:
1. Find a good name for this SBT family
2. approve parameters:
1. 1 approval or 3 approvals in total for adding / removing admin
2. admin doesn't need an approval to add / revoke SBT.