Finance has been regulated from the beginning of time. For crypto, Web3, and RWA to take off, and be used in the real world, we need compliant DeFi. I do not believe this to be an opinion. It is a fact. And if you don’t like it, it doesn’t change the fact. Look at your dollar bill. There’s probably a president there. And if you look at British Pounds, you’ll probably find the Queen. Compliance isn’t optional. It is a feature of money, and it is a feature of money movement. Just because you’re a crypto bro who likes annoymity doesn’t change a damn thing.
Now that we have acknowledge the real world that we all live in, what are the barriers to Web3 adoption?
Lack of regulatory clarity from primarily the US regulators
Lack of Web3 tools to come into compliance
Point 1 is out of our control, but is a matter of time. Point 2 is rapidly evolving. The IC has the potential to the leader in compliant DeFi if we build the tools. We have the best tech after all.
I am really excited to see verifiable credentials launch in 2024, and I am really excited to see Helix launch in 2024. Helix will enable self-custodied, yet KYC’d, wallets to transact on a decentralized orderbook. I am also super excited to see the GDPR compliant European subnet and subnet renting, with the Swiss subnet as the first, as this will enable projects with strict compliance to launch.
I would like the Foundation to think about other ways to push forward ways for dApps to create compliance tools. Let’s work with the Swiss government to be first to market. Lets go ICP!
I think about this a lot. Decentralization is possible but it is going to be a VERY DIFFICULT road to try and have an unregulated & completely anonymous system and market on a massive scale. Pseudonymity with the possibility for seemingly anonymous movement is optimal at best. In almost any place in the world you will find government to some degree. I sometimes think people who aggressively value anonymity in crypto really just don’t trust themselves to not do something illegal.
Internet Identity still needs to be improved where it’s VERY simple to make a new account. It’s still far to complicated for the average user. We need UAT where a nontechnical person is able to navigate it easily
Easy way to solve that is do it like Cosmos ecosystem governance. Embed ICP AI with each proposal that give it a summary. The voter can further quiz the AI with more questions if necessary. The tool is already there.
Thank you for your thoughtful post on compliance! I fully agree with you that compliance is a cornerstone of Web3 adoption and that having mechanisms / tools to enable dapps to help be compliant can be a big advantage. This is definitely something we will think more about for the Internet Computer’s roadmap in 2024 and beyond.
Do you already have specific things in mind in this domain that you can share with us?
Thank you for triggering this excellent discussion and many thanks to everyone who has contributed their thoughts. An update of the public roadmap is currently in the making and the discussions here will help to further shape it. Some of the items mentioned here are already contained in the roadmap, others are great ideas to consider. Hope the great discussion here is continuing like this!
ZK or other identity solutions that prove sanctions compliance, country of origin, uniqueness, accredited investor status, etc without compromising egregiously on privacy.
Gitcoin Passport, Coinbase Verifications, Ethereum Attestation Service, Reclaim Protocol, etc.
My dream is to be able to just attach a cryptographic string to a transaction and have that transaction thus be compliant. Simple simple simple for developers, as little burden as possible for users, replicating the pii as little as possible.
I would like my 2024 wishlist to be part of this thread, I’m going to post my list…I encourage everyone else to do the same, so I hope I don’t just dominate the conversation.
Since genesis canisters have been severely limited in their total Wasm binary size (total size of code and data essentially), and this limit has been essentially priority #1 for @demergentlabs to remove to enable the full glory of TypeScript, JavaScript, Python, and GraphQL applications on the IC.
We must finish increasing the Wasm binary limit! This limit was lifted partially in 2023, but developers still can’t directly deploy large Wasm binaries with dfx, making the changes somewhat useful but still cumbersome and difficult.
Luckily @dfinity seems very close to delivering an initial solution to this problem.
Rust and Motoko devs have a very nice dfx.json experience. They get tidy and small dfx.json files with “type”: “rust” or “type”: “motoko”, and much of the underlying complications are abstracted away.
Azle and Kybra and other language CDKs don’t have these benefits yet, but dfx extensions promises to provide a solution so that they can be on par with Rust and Motoko.
We’ve been pushing for this since 2022, and development on it seems slow or stalled, so I’m putting this at a medium likelihood of shipping.
Wasi stands for WebAssembly System Interface. It’s a low-level standard for Wasm modules that essentially allows OS-level API access. This provides standard access to things like the file system, environment variables, and (tcp?) sockets.
We have a nice polyfill of Wasi working on ICP right now, it’s powering both Azle and Kybra. It works well.
I would like to see it improved though. I want to see the missing Wasi functions implemented, especially the socket functions. There will be pushback on this, but I wonder if there is a way to implement sockets at least if scoping their functionality down to provide HTTP functionality only.
I would also like to see the polyfill bumped up to an official integration into the replica or Rust CDK…I don’t know, something more than just a polyfill.
Wasi lays the foundation for allowing Azle and Kybra and other CDKs to support as many OS APIs as possible, opening the door to as many PyPI and npm packages as possible.
I’m not sure I can overstate the importance of this one…various people have brought this up, it has come up relatively often in the forum, I’ve been heavily involved in building one of these things for ICP that unfortunately has dropped out of traction…
WE NEED A DATABASE ON ICP.
Not an ICP-specific database that is immature, not severely limited data structures with some features of a database…no we need an actual database that people have already heard of, that’s trusted, that’s robust and mature.
We need Postgres, MySQL, MongoDB, SQLite, vector DBs, etc etc etc.
Even Sudograph, the GraphQL database I built specifically for ICP, is something that I’m rethinking. We’ve definitely deprioritized it for the moment.
Instead we’re aiming to enable as many JavaScript/Python databases that already exist as possible, that’s why Wasi and other low-level API support is so crucial to us.
We want people to be able to grab their favorite DB off-the-shelf.
Once that is a reality, of course we will look into the benefits of an ICP-specific DB. I still think Sudograph could provide one of the best developer experiences possible, but a good-enough experience is better than that in the short-term I believe, and there still isn’t a good-enough DB experience on ICP that I know of.
Look…ICP has some pretty “neat” HTTP funtionality. It does work for some use cases, maybe a good amount of use cases. But both incoming and outgoing HTTP functionality is still limited.
I don’t have many detailed specifics for this, but reducing latencies, cycle costs, allowing HTTP outcall queries, and essentially moving towards the most full-featured HTTP capabilities possible (think browser/Node.js fetch, or the most popular HTTP client library of your favorite language)…that should be the goal.
If ICP is to be adopted as a mainstream backend technology, we need to improve the HTTP capabilities so that the trade-offs aren’t so appalling.
I’m still not sure what this will look like, as Candid is so integral to the ecosystem as it is now.
But perhaps there are ways for JSON and Candid to interoperate, and abstractions that could be built to remove as much developer complexity away from the end developer as possible.
Let’s make ICP a decentralized server environment, letting devs use the tools and technologies they already know and love.
