[Discussion] Can (and should) Maker require acceptance of TOS on-chain prior to interaction?

I’m fairly certain that I’ve only seen this on UIs, and we don’t control any to my knowledge.

But is there a way to require an affirmative acceptance of a Terms of Service or End User License Agreement on-chain for a wallet the first time it interacts with the protocol?

If so, do we want to pioneer this kind of permissioned permissionlessness? A way to self-whitelist.

I see lots of applications such as self-attestation of being an accredited investor to waiver of liability to agreements to use arbitration, etc.

I will admit I don’t know how useful it is legally in major jurisdictions, and will defer to the various lawyers in the DAO on the usefulness of such a contraption.

I believe 1inch started to ban Americanos like you and I from aggregating via their dApp—are you suggesting in a nicer way that Maker should consider the same path? Easier way would be to lift the Dust parameters to 100,000 DAI, IMO.

I mean — If you want to take it the accredited investor route — why not a Dust of 1,000,000 DAI

My thought was a TOS or EULA would:

  1. Be consistent with our stance that the actual protocol is just open source software by conforming to (what I perceive as) industry standard practice

  2. Can include all kinds of granular requirements for any jurisdiction that gives us problems as they can all be in the same TOS

  3. Waive any perceived liability arising from use and/or require arbitration, preventing another BT headache

  4. Is a more permissionless way to make the protocol “permissioned” as long as self-attestation by users is legally useful — rather than use blunt tools like raising dust

Reconsider your involvement in DeFi if you think MakerDAO should do this.

1 Like

I remember this type of on-chain Terms of Service acceptance implementations from 2016-17, when there were some big hopes for integrating legal and smart contracts into a single consistent set of rules.

Putting aside the important “permissionless vs. permissioned” debate which thanks to 1inch, Aave Arc etc. seems to be relevant again, there might be some value in such a solution in terms of liability protection. There are also challenges (incomplete list, just what immediately comes to mind):

  • Who would act as a service provider? Typically you have a person who provides a service and requires acceptance of its terms. For example, for services provided on oasis.app, a major external front-end to Maker Protocol, that will be the entity indicated in their ToS. In the case of the Protocol itself, it seems to me that the narrative that a user interacts with a set of autonomous smart contracts with no operator / service provider is usually very useful.

  • I am not sure if it would be possible to actually display the contents of any ToS / disclaimer, how the acceptance process would look like, whether it is technically feasible (and legally meaningful) to have the acceptance required for bots / direct Protocol access / other DeFi protocols which plug into Maker, etc.

4 Likes

1 Like