Cosmos-sdk: Delegation authorization ("KYC/AML whitelist")

[mdyring]

Summary

Introduce a mechanism whereby validators can choose if they accept anonymous delegations or want to cherry-pick.

Problem Definition

There is some ongoing discussion of KYC/AML requirements for validators, depending on jurisdiction and interpretation.

At the end of the day, I believe cosmos-sdk should support as wide a range of use-cases and jurisdictions as possible to support wide adoption.

For Cosmos Hub specifically: If some validators have concerns, they should be taken into consideration to ensure a healthy and diverse validator set from a very early stage.

If some validators choose to implement KYC/AML procedures, delegators are still free to choose accordingly based on their preferences and desire for anonymity.

It is worth considering that validators could set 100% fees to make it unlikely to receive delegations, but it does not seem like the right way to address it.

Proposal

I'd like to suggest a very simple whitelisting mechanism as follows:

• Introduce a "anonymous delegation" flag (boolean) for validators. Setting this to true means anyone can delegate.
• If a validator does not allow anonymous delegations, the validator must sign the delegation tx (alongside the delegator) for it to be accepted by the network.

So the validators that allows anonymous delegation, the workflow is as today.

If anonymous delegation = false, it could then look like:

1) Delegator goes through KYC/AML processing through validator website
2) Delegator constructs and signs the delegation TX
3) Delegator submits the TX to the validator website
4) If validator chooses to accept the delegation, it signs the TX and broadcasts it to the network

Of course, this requires the validator secret key to be used ever so often. So instead of a "anonymous delegation" flag, there could be a "delegation authorizer" pubkey associated with the validator. If this value is not populated, it has the same meaning as "anonymous delegation "= true.

This way, the validator can use different keys for validator and delegation authorization.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[zmanian]

My point of view is that this should be done via governance.

It needs a more detailed spec as well.

Possibly approve the idea via governance and then approve a spec and implementation via governance?

[mdyring]

I agree: post launch and with governance.

[jackzampolin]

@mdyring ping

[mdyring]

@jackzampolin pong :-)

On the back burner from our (validator.network) perspective, I'll drop a note in the validator chat room to see if anyone bites.

[dlguddus]

@mdyring Bite!

B-Harvest was a early backer of this utility.

This is just a brainstorming but, it looks like such 2 step transaction is quite a breaking change in SDK. So what I want to try to discuss is that maybe we can make such N-step functionality more generally?

It means that the state of blockchain changes only if whole N-step of transactions successfully pass. It might needs standard timeout feature for temporarity of availability of the transaction. It can be described as multi-entity-signed transactions.

I see quite broad range of use-cases for this generalized N-step transaction, including secured trading/payment or more structured transaction like @mdyring is proposing.

Sorry for little bit out of topic. I am definitely agreeing with pre-delegator-approval procedure.

[p3t3hill]

Valid8r supports blacklisting in the first instance. Whitelisting requires further investigation to the legal ramifications in different jurisdictions.

[alexanderbez]

Whitelisting seems easier to implement imho (regardless of agreed upon implementation). Blacklisting seems more state storage heavy. Also, not very sure what you're getting at @dlguddus, can you elaborate a bit? Only 1 tx happens on-chain afaict.

[dlguddus]

@alexanderbez

A state change happens with successful serialized designated N transactions.
Example as below.

1. User A broadcast a transaction with paying 50k USDCosmos and receiving 10k ATOM with 10 designated address and timeout limit of 1 hour which are specified in the tx.

2. 10 designated address owners broadcast transactions with paying 1k ATOM and receiving 5k USDCosmos before timeout limit.

3. when all 10 txs successfully passes the blockchain, the exchange among user A(ATOM buyer) and 10 users(ATOM seller) happens in the blockchain.

I want to discuss more generalized way of multi-entity-signed-transaction with specified agreement like this is whether "enoughly necessary" and "deployable" in the hub. Generalized means rules and procedure of how to specify and execute such general agreement format. Further generalization would be a script address like bitcoin. I don't see any reason why we should not have that in the hub.

BTW, I misread @mdyring 's proposal. Actually the combining execution of two txs happens offchain so it is irrelevant with my topic. Sorry for that! Because this is irrelevant with current thread, I will just stop this discussion here.

[7alisman]

Valid8r supports blacklisting in the first instance. Whitelisting requires further investigation to the legal ramifications in different jurisdictions.

With the newly released signalling from the SEC, and their definition of an "Active Participant" with respect to the new framework they laid out last month, I am even less a fan of a whitelist that I have been previously. We have discussed this on multiple occasions on the forums, but it was request that I put down some of my feelings here,

A good synopsis of the recent signals and my personal concerns can be found here: https://blog.circle.com/2019/05/23/our-take-interpreting-recent-signals-from-us-regulatory-agencies/

The following are just a few of the potential concerns I see for the creation of a whitelist/KYC

1. Privacy Laws and international jurisdictions and storage of personal data
2. AML / Tax / Revenue reporting: As soon as we are responsible for choosing who can participate, it is a matter of time before we are expected to disclose rewards and earnings to a slew of revenue agencies in multiple international jurisdictions.
3. Possible risk of defining ourselves (Validators) as a money service businesses (as soon as we control who can and can't delegate).
4. Even if a validator chose to "opt out" of the KYC, the fact that it exists, and a validator chooses not to use it, could possibly be misinterpreted by a regulatory agency as not following the spirit of the law. As a result I do not believe that choosing not to use a whitelist absolves us of the above concerns, but rather increases the potential risks.

A blacklist on the other hand, provides all the same protections we'd get from a whitelist, without the legal responsibilities. I'd rather a lettered agency approach me, and say "we have reason to believe address X is engaged in illegal activity and request that you remove the delegator from your pool", than be in a position where they come to me and say "you verified this individual and still provided your services, prove to me you are not complicit in the action being taken by the delegator".

My opinion may change if anyone can provide me a reason that is advantageous enough to us as a validator community to adopt that it offsets the possible legal risks, but until then, I will vote against a proposal for a whitelist.

[fedekunze]

seems like there's no consensus on this proposal. I'd suggest discussing this on the forum first. Closing