# <svg class="" fill="#e6007a" width="23" height="25" viewBox="0 -5 50 45" xmlns="http://www.w3.org/2000/svg"><path d="m21.1695 9.42485c4.4769 0 8.1062-2.10983 8.1062-4.71243s-3.6293-4.71242-8.1062-4.71242c-4.477 0-8.1063 2.10982-8.1063 4.71242s3.6293 4.71243 8.1063 4.71243z"></path><path d="m40.6292 24.3756c-2.3277-1.3674-5.9251.8139-8.1063 4.6636-2.23 3.8497-2.3277 8.0575 0 9.376 2.3277 1.3673 5.8763-.8139 8.1063-4.7125 2.23-3.8008 2.3277-8.0086 0-9.3271z"></path><path d="m21.1695 45c4.4769 0 8.1062-2.1098 8.1062-4.7124s-3.6293-4.7124-8.1062-4.7124c-4.477 0-8.1063 2.1098-8.1063 4.7124s3.6293 4.7124 8.1063 4.7124z"></path><path d="m1.70935 24.3756c-2.327703 1.3185-2.230038 5.5263 0 9.3271 2.23003 3.8986 5.77854 6.0798 8.10624 4.7125 2.32771-1.3185 2.23001-5.5263 0-9.376-2.1812-3.8497-5.77855-6.031-8.10624-4.6636z"></path><path d="m9.82353 6.58455c-2.3277-1.36734-5.87622.81389-8.10625 4.66355-2.230032 3.8497-2.327698 8.0575 0 9.376 2.32769 1.3674 5.92505-.8138 8.10625-4.7124 2.23007-3.8008 2.32767-8.00865 0-9.32715z"></path><path d="m32.5229 6.58455c-2.3277 1.3185-2.23 5.52635 0 9.32715 2.1812 3.8986 5.7786 6.0798 8.1063 4.7124 2.3277-1.3185 2.23-5.5263 0-9.376-2.23-3.84966-5.7786-6.03089-8.1063-4.66355z"></path></svg> Smart Contracts Plaza Tooling - PROPOSAL

- Applicant: **[PlayProject](https://playproject.io/)**
- Contact: **[@ninabreznik](https://x.com/ninabreznik)**
- Requested funding for the Milestone I (MVP): **164,400 USDT**

# Introduction
We would like to kindly thank everyone for taking the time to vote and/or comment on our [903 proposal](https://polkadot.polkassembly.io/referenda/903). We had an unexpectedly large voter turnout, with over 160 million DOT in total, which clearly shows that smart contract tooling on Polkadot is an interesting topic. The project received over 60% support; however, during the confirmation period, it was voted against and ultimately failed with 46.3% AYE and 53.7% NAY.

During the voting period, we conducted additional research to help voters understand the context and how our proposal fits into the Plaza vision and received a lot of valuable feedback on how we can further improve our proposal and mitigate the risk for the DAO by splitting it into milestones and executing them sequentially.

Overall, our research, combined with the feedback, suggests that the best MVP and the first milestone would be **a minimalistic testing playground** to help us test the PolkaVM, compiler and ethRPC adapter before they go live. Subsequently, in future milestones, once all components, the compiler, ethRPC adapter and the PVM are stable and ready for end users (Solidity developers), we will be able to create a Hardhat (which can also be used in Foundry, which lacks a plugin system) and retrofit other existing tooling.

# Problem

Polkadot has the best, secure and scalable tech, but a severe lack of real user adoption:

**1.** Scalability Groundwork has been laid for Polkadot's scalable multi chain world.
**2.** Polkadot has so-far relatively uncoordinated actions and is fragmented into many chains which creates the need for users, apps & wallets to coordinate.
**3.** While many projects currently benefit from having their own chain, despite the hard work of Wallet and Frontend Developers, the long tail of contract developers and users must spend a lot of time, money & effort to coordinate difficult async interaction, juggling composability of assets, accounts and state across a complex multi chain landscape. Developers also have high time & money costs for building chains, like for example coordinating collator sets and handling block explorers, indexing, bridging, exchange integrations and other overhead.
**4.** Those costs are worthwhile and necessary once scaling capabilities are needed.
**5.** But for lack of real users, there is no scaling pressure currently to merit the level of ecosystem fragmentation.
**6.** Because even a single parachain can use a large number of cores to process transactions, logically sequential, synchronously composable and validated in parallel across many cores utilizing elastic scaling. It scales to thousands of TPS today and much further over time. Conservatively, even a single chain scales up to tens of millions of daily users.

# Solution

As an ecosystem we should work together to build **Polkadot Plaza**, a tooling supported batteries-included single system chain and focus on scaling it up until it hits its scaling limits. This will bring most value and lowest switching costs for Ethereum builders. Once the organic pressure on Plaza reaches the point of bursting, the pressure will be relieved by dapps utilizing the multi chain capabilities and spinning out apps, users, and system functionality, which is enabled by easy migration of contracts to dedicated chains in order to save costs. Similar behavior can already be observed naturally by mature Ethereum dapps migrating out to Ethereums Layer 2 solutions today to lower costs and increase performance.

Ethereum has the largest user base and those users could then be funneled to Polkadot Plaza by enabling beloved and popular mature Ethereum dapps to migrate easily. This can be achieved by giving them the same interfaces and UX while providing a cheaper and faster execution layer without compromising security and offer additional functionality from Polkadot's unique cross-chain interactions like XCM and bridges. Migrating Ethereum dapps means migrating their users to the Polkadot ecosystem and also the liquidity. The biggest problem is user inertia, so the less changes for a users basic journey experience, the better for winning them over.

To support [**Rob's vision of the Plaza system chain**](https://www.rob.tech/blog/plaza/) we prepared [**our take on the marketing strategy**](https://hackmd.io/@T6Wf5EsOQKe-6wyPjJPtuw/HkC2lL2dR).

Following Rob and Giotto, who say we don’t need more unused tools, our team suggests to create a **tooling supported funnel to bring users to Polkadot Plaza in multiple stages**. Following the feedback from Shawn, Thibaut and others, we try to aim for the most minimal first milestone possible, which also does not depend on any deliverables from external teams.

**1.** In the first stage, we propose a first milestone to build out a **testing playground**, that supports inspecting, scripting, testing, debugging and hooking into a classic EVM pipeline, in parallel to the Parity Smart Contract Teams building out their Plaza deliverables (PVM, EthRPC adapter, revive compiler and Paseo integration).
**2.** Once completed, we will propose a second milestone to leverage the testing playground in order to turn then available Partity Smart Contract Teams' deliverables into drop-in replacement components for the EVM pipeline to **enable a PVM pipeline**, that will allow solidity developers to compile, deploy and interact with Smart Contracts on Polkadot Plaza (through the Paseo test network).
**3.** Once we achieve this stage, we are finally ready to **retrofit the existing Solidity tooling (Hardhat, Remix and maybe VScode**) and enable Solidity developers to try out Polkadot PVM and start transitioning to Polkadot.
**4.** Lastly - a fourth milestone can be proposed to bring the most advanced solidity developers to a Polkadot native developer environment, where they can discover the full functionality of Plaza and interact with other ecosystem services they wouldn’t be able to easily discover and interact with from inside of their existing solidity tools. This step is also useful for our native Polkadot developers, whom we don’t want to send to tooling maintained by other ecosystem, but rather offer them Polkadot first tooling. This step will be discussed in the future and can focus on **turning the testing playground into a real developer facing playground and/or simply focus on Polkadot native CLI tooling**.

# Milestone I - (2024 Q3/Q4): Testing Playground (MVP)

We plan to setup a **compile-deploy-interact EVM pipeline** and a Testing Playground in a Metamask enabled web environment, which is most commonly used by Ethereum dApps. This approach will enable hooking into that pipeline to allow inspecting, testing and debugging all the capabilities of Parity Smart Contract Team deliverables (PVM, revive compiler and EthRPC adapter). This approach will enable us to turn those deliverables into EVM pipeline drop-in replacement components needed for retrofitting existing Solidity tooling, such as HardHat and Remix plugins, in future milestone(s).

The main benefit and focus is to test the full flow of compiling, deploying and interacting with solidity based smart contracts on Plaza and to help understand and identify missing features, debug issues and to ensure everyting works as a drop-in replacement for the equivalent EVM based flow for web dApps using MetaMask and similar wallets.

# Budget (MVP)

**Requested amount:** 164,400 USDT
**Estimated length of work:** 1,370 hours
**Estimated rate:** 120 USDT

The proposed milestone is based on [our comprehensive research](https://hackmd.io/@T6Wf5EsOQKe-6wyPjJPtuw/Bk_A8RYPC) of four years of solidity surveys and analyzing similar work from zkSync.

|ID|Tasks| **Total Costs (USDT)**|
|--|-----|-----------------------|
|01|Conduct extended Ethereum Smart contract tooling research and compile a report | **14,400**|
|02|Create web testing playground with a console to log outputs | **16,800**|
|03|Integrate solidity contract templates selection to cover solidity language features to select from when testing the pipeline | **14,400**|
|04|Create module to fetch and cache any prebuilt solidity compiler version to compile Solidity into EVM-compatible bytecode | **18,000**|
|05|Create module to enable deployment to EVM based networks (e.g. Moonbeam or Ethereum testnet Sepolia) | **18,000**|
|06|Create module based on web3js/etherjs to interact with deployed smart contracts via RPC to node | **18,000**|
|07|Create a hookable EVM pipeline with scripting capabilities and add it to the console | **21,600**|
|08|Extend pipeline with Solidity compiler logic | **8,400**|
|09|Extend pipeline with deploy to EVM based network via Metamask | **8,400**|
|10|Extend pipeline with an ABI based interaction logic | **8,400**|
|10|Integrate a test runner to define and execute test suites and report results | **18,000**|
| |**Total** |**164,400**|

> All deliverables will be 100% open sourced under the MIT license.

See [detailed excell table](https://docs.google.com/spreadsheets/d/1WQfU8T-popBcBHNbIV1xDsKp9SFqiRsSlVyHz9ijDaU)

# FAQ

**1. What is the problem you are trying to solve with the "minimalistic playground in the browser"?**

In the first milestone we are trying to create a testing playground to be able to support the Parity Smart Contract Team once their deliverables (revive compiler, PVM, Paseo support with EthRPC adapter) become available. It won't include any fancy editor or styling that would make it a smooth experience for solidity developers, because we do not target them with our first milestone.

---

>**2. Who are the target users of this playground?**

In the first and probably second milestone, the target users will be internal, more specifically our team and the compiler and PVM developers.
For more details, see section [First target audience](#First-target-audience)

----

>**3. How is this playground going to help these users?**

For internal users, the main benefit and focus is to test the full flow of compiling, deploying and interacting with solidity based smart contracts on Plaza and to help understand and identify missing features, debug issues and to ensure everyting works as a drop-in replacement for the equivalent EVM based flow.
The benefit of the testing playground is also to allow us to effortlessly hook into every step of the process in the same web environment solidity web dapps interact with popular wallets, such as MetaMask.

----

>**4. What can be done with this playground that couldn't be done with a Remix plugin?**

When we originally developed the Remix plugin system, we did not architect it in a way that would allow to tap into any arbitrary part of Remix. It was rather designed as a system to allow some limited extensibility and to grow it over time based on feature requests.

For internal users, in theory a Remix plugin might be able to satisfy all our needs, but in order to hook into any part of the compile, deploy, interact pipeline for EVM, we would need to re-implement what Remix natively does inside a plugin and basically do the entire work we would do for the testing playground with the additional overhead of wrapping it in a Remix plugin. It would also restrict our ability to utilize the UI in arbitrary ways in order to help us test and debug once revive compiler and PVM deliverables are available. For example if we figured out we wanted to visualize compiler output or logs full screen to compare or get insights in specific parts, Remix is not designed to allow that.

-----------

>**5. Why is this playground a prerequisite for creating a Hardhat plugin?** I understand the value of creating a Hardhat or Remix plugin, but I'm struggling to see the value of the "minimalistic playground in the browser".

A HardHat plugin, just like any other existing tooling can only be retrofitted with stable "Plaza components" and put in front of existing solidity developers, once those components exist. The testing playground approach will help us create those minimal well tested general components to compile, deploy and interact, so we can fully control and hook into every part of the EVM pipeline in a browser environment to have access to the most commonly used MetaMask Wallet, for testing, inspecting and improving the components.

Once they become stable and ready to be re-used, we will implement them into more complex professional environments, such as Remix or HardHat or VScode plugins etc., as part of the funnel to bring existing solidity developers to Polkadot.

-----

>**6. Why not create a plugin from the start?** Why is there a need to create a new online editor? Past feedback suggested avoiding new tools unless there's a strong justification. Did I miss an explanation?

Starting with the testing playground will enable us to to hook into the compile-deploy-interact pipeline to test all the capabilities and which will help us develop and test all the modules we need for retrofitting existing Solidity tooling, such as HardHat and Remix plugins, in the next milestone(s).

----

>**7. Couldn't this also be achieved through a Remix plugin?**

As mentioned above, Remix plugin system wasn't designed to hook into any arbitrary parts of the pipeline, nor to make it scriptable. Doing a Remix plugin might still be possible but there is a risk that we would need to do things plugins don't support which would have a significant overhead since we would have to write all the code that we would otherwise write for a testing playground plus wrapping it in the plugin. Additionally, every time we will run a test, we will also have the Remix code as an extra overhead we need to step through while debugging, which will cause more complexity and will make the milestone bigger and more expensive.

----

>**8. Are you sure that their recommendation was to create a "minimalistic playground in the browser"?** The [last feedback I read](https://forum.polkadot.network/t/plaza-smart-contract-editor-ide-project-proposal/8657/10) suggested avoiding new tools initially and focusing on plugins instead.

After sharing the research about the existing solidity tooling and discussing all the technical pros and cons with the Smart Contract Team and thinking also about the marketing funnel towards Polkadot, we agreed the best approach would be to build a minimalistic playground and the plugins. In our previous proposal we wanted to start with the playground and the plugins in parallel, but Shawn and Thibaut pointed out we should really focus on the most minimal first milestone that doesn't depend on any other external party.

To sum up, as we all agree building yet another tool that no one uses, is not the approach we want to take, what we would like to contribute is a tooling supported funnel strategy to transition solidity developers from other ecosystems onto Plaza/Polkadot.

After the initial comments Smart contract lead and also Rob agree a minimalist playground is a reasonable pathway forward, although we should also focus on plugins, which is exactly how we now want to procees: first testing tooling, then plugins and lastly (maybe) a real user facing playground.

---
[Rober Habermeier's tweet](https://x.com/rphmeier/status/1809982692110577870) on our [903 proposal](https://polkadot.polkassembly.io/referenda/903)
[](https://x.com/rphmeier/status/1809982692110577870)

---
[Alex Theissen's - Parity Smart Contract Team Lead - comment](https://forum.polkadot.network/t/plaza-smart-contract-editor-ide-project-proposal/8657/14) on our [903 proposal](https://polkadot.polkassembly.io/referenda/903)

---
[Alex Theissen's comment](https://polkadot.subsquare.io/referenda/903) on our [903 proposal](https://polkadot.polkassembly.io/referenda/903) (sadly no direct link to the comment is available, so search Alex and 3rd hit is the comment)
[](https://polkadot.subsquare.io/referenda/903)

----

>**9. Did the team request this?** Will they be able to use your first delivery for this purpose?

Yes, the Smart contract team suggested we implement the EVM flow first because they would like to test their compiler and PVM against that setup and also make sure ethRPC works with Metamask and other wallets. We were discussing if this should be via Remix plugin or a minimal testing playground and the idea was to do both in parallel. But in order to make our first milestone smallest as possible (as Shawn suggests) we would recommend to first do the testing playground as it has the least overhead.

----

>**10. Could you elaborate on this replacement process?** Which kind of node will this playground work against?
> - Will it work against a Frontier-based node?
> - Will you contribute to the ethink project and built on top of it?
> - Will you fork the `@acala-network/eth-rpc-adapter` and adapt it for your own needs?
> - Will you create a custom solution?
> - Something else... Another solution that I don't know about, or one that's currently under development, perhaps?
>
>What trade-offs have you considered, and which path will you take to replace the EVM with the PVM?

In the first milestone we plan to focus on the EVM flow, so we don't need to work against the ethRPC adapter.Most likely we will make the deployment work on Ethereum Sepolia test net or Moonbeam.

In Q4 Paseo test node will most likely already support PVM so our plan was to use Paseo, but if it will not be ready until then, we will decide for the best option by the time we apply for the next milestone.

# First target audience

In the first and probably second milestone, the target users will be internal, more specifically our team and the compiler and PVM developers.

For internal users, the main benefit and focus is to test the full flow of compiling, deploying and interacting with solidity based smart contracts on Plaza and to help understand and identify missing features, debug issues and to ensure everyting works as a drop-in replacement for the equivalent EVM based flow.
The benefit of the testing playground is also to allow us to effortlessly hook into every step of the process in the same web environment solidity web dapps interact with popular wallets, such as MetaMask.

## Parity Smart Contract & Compiler Team (core partner)
Our main focus is to start with onboarding Solidity developers, hence this team is our most important partner and will deliver crucial inputs we absolutely depend on and without which we cannot deliver our project.

Main components we plan to integrate and test with our testing playground:

> * [revive-solweb compiler](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949)
> * [browser PVM (polkaVM runtime)](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811)
> * [EthRPC PVM adapter](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375)
> * [polkaVM on AssetHub { Paseo, Polkadot, Kusama }](https://polkadot.polkassembly.io/referenda/885)

The Parity smart contract team has been working on those deliverables for some time now and progressed quite far, so we are expecting the first deliverables in Q3 and Q4 within 2024.
[<img src="https://imgur.com/BZtu15R.png" style="width:95%">](https://www.youtube.com/watch?v=ahtBhzwmjY4)

### 1. Solc-revive web compiler
**first alpha version expected at end of Q3 2024 (audit ready)**

> [Forum - solrevive - solidity on polkaVM](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949)

The initial release will only compile a subset of existing contracts, but in a few months after more testing & refinements, will compile all of them. The Parity Compiler Team plans to combine the pvm compiler with with a solc to YUL frontend to enable compiling solidity smart contracts. Having solc web compile to YUL and then revive wasm recompile to polkaVM in the browser (evm/wasm) avoids scaling server costs later on. The compiler pipeline is:

> solidity source === solc compiler ===> YUL IR === revive compiler ===> RISC-V => polkaVM-linker => PolkaVM (uploaded on-chain for execution)

This approach was used by zksync for zksolc and helps with re-using existing tooling and avoids creating a solidity dialect. The YUL to polkaVM revive recompiler can be combined with many compiler frontends in the future to support more smart contract languages. This is preferable over a complete solidity compiler for lack of docs and complete solidity specs and many never finished half baked solidity features. The alternative would be to re-implement and keep up with solc, the single source of truth reference implementation, which is hard and more work. Lastly, it will enable deterministic output, which is needed for source code verification, by comparing compiler output with onchain contract bytecode.

### 2. browser PVM (polkaVM runtime)
**first alpha version expected at end of Q3 2024 (audit ready)**
> * [Forum - polkaVM](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811)

This is the contract execution engine implemented as a runtime module. The execution environment (a pallet with required host functions) is targeted by the revive compiler. The engines execution layer needs to allow contracts to implenent the same business logic as EVM contracts and keep the same calling conventions between caller and callee.

The polkaVM itself is a Risc-V based contracts runtime and in comprehensive benchmarks shows much better performance than WASM and EVM runtimes.
* It has very competitive startup and compilation times, much better than pallet-contracts or pallet-evm.
* Additionally, for Polkadot native tooling we are counting on the wasm runtime based on polkaVM, which will be able to run ink! as well as solidity and cross-validation against other EVM and WASM interpreters or even eBPF as a bonus will be possible too.
* The Parity smart contract team assured us a "pallet-contracts" version running in the browser will be feasible and allow gas estimation.
* It will initially come with very limited debugging support, no step by step debugging, but will be able to run contracts and estimate gas.
* It will also enable the tooling to see when calls pass or fail and allow printing to the console.
* A stepping debugger will only become feasible in Q2/Q3 of 2025 when polkaVM will offer execution traces.

### 3. EthRPC PVM adapter
**first alpha version expected at end of Q3 2024 (audit ready)**

> * [Forum - EthRPC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375)
> * [Proposal - EthRPC](https://polkadot.polkassembly.io/referenda/723)

RPC exposed by a chain node speaks to the node's runtime via the runtime API.
EthRPC is a compatibility layer to translate Ethereum RPC calls to Polkadot RPCs (similar to Frontier) and exposes endpoints in compliance with [Ethereum RPC](https://ethereum.github.io/execution-apis/api-documentation/) for the UI to speak to.

All EhtRPC compliant tooling, wallets (like MetaMask), etc... will just work. Our tooling will enable web3.js based Metamask to deploy utilizing a node's EthRPC adapter layer. In the future, a Metamask snaps plugin might even enable client side compatibility without the EthRPC adapter layer.

The Parity smart contract team will need to add aditional features for deleting contract code via special endpoints so custom web3.js based libraries can utlize those as well. This only requires changing endpoints and the node will use the web3js RPC adapter.

### 4. polkaVM on AssetHub { Paseo, Polkadot, Kusama }
**first alpha version expected at end of Q3 2024 (audit ready)**
**integration into AssetHub at end of Q4 2024 (audit ready)**

> * [polkaVM on AssetHub { Paseo, Polkadot, Kusama } (proposal 885)](https://polkadot.polkassembly.io/referenda/885)
> * [Hybrid System Chains (forum post 7089)](https://forum.polkadot.network/t/hybrid-system-chains-make-polkadot-permissionless/7089)

Having polkaVM integrated into AssetHub on Polkadot (and Kusama) and initially on [Paseo](https://faucet.polkadot.io/paseo) will allow us to iterate quickly. Especially if a contract, next to its input and output, might offer dapps to rely on underlying chain protocol data, such as block and transaction data, gas prices, storage state, etc..., which can be supported once the protocol logic is implemented in other runtime modules. All it requires for RPC to provide such data is the runtime to have logic translating substrate chain data to Ethereum chain data.

**Deployment** to AssetHub powered by polkaVM instead of of a chain powered by pallet_evm will enable us to deploy init code. Until ready, we plan to work against Moonbeam or simply eth/web3 without running contracts in browsers, but once available, compiling and deploying to polkaVM powered Paseo testnet allows us to refine the developer experience for this as well. Even though polkadot.js will enable the entire process natively, the EthABI needs a helper library. Initial prototypes could use polkadot.js for node communication and use web3.js to encode/decode contract inputs. It is annoying to have both dependencies, but might be okay for an early prototype.

Finally, deployment deviation only affects the developer side and we will try to support it with tooling.
The [new transaction for deployment](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions) allows to instantiate a contract via hash instead of code. Contract deployment follows [EIP-712](https://eips.ethereum.org/EIPS/eip-712). The needed bytecode can be provided via "factory dependencies". It will upload the code without instantiating it and then exist as "onchain constructor", allowing anyone to just supply the hash of the code in a custom EIP-712 transaction type to instantiate new contract instances, once this custom functionality is exposed via a web3.js based library.

# Team
We are neither new to web3, nor to Polkadot. We have been actively participating and working in the Polkadot ecosystem since 2019. We previously talked about [this proposal on AAG](https://www.youtube.com/live/K38dccT2jBc?si=u4rxUg7SR9dW2TdP&t=5023) in July.

We worked for many years with the Ethereum Foundation on solidity smart contract tooling and spoke during the first Web3 summit.
[](https://www.youtube.com/watch?v=VeNVFvCOg3I&t=800s)

---

## 2016-2019: Ethereum Ecosystem
From 2016 to 2019, we worked with the Ethereum Foundation on various special projects and helped to launch the [Remix IDE](https://github.com/ethereum/remix-ide/graphs/contributors) among other initiatives.

In parallel, we founded the ["Play Project"](https://github.com/ethereum/play), a Web3 infrastructure and UX research company focused on work revolving around developer UX, smart contracts, and decentralized P2P storage solutions.

We [architected](https://github.com/search?q=org%3Aethereum+author%3Aserapath&type=commits) and [implemented](https://github.com/search?q=org%3Aethereum+author%3Aninabreznik&type=commits) many parts of the Remix IDE core components (including file explorer, the terminal, the basic tiling window manager as well as the **Remix plugin system** to allow other ecosystem projects to better integrate with the IDE.

Over the years, we also hosted numerous Solidity workshops and listened to the experience and struggle of new developers in-person. We also gave many talks about smart contracts and other topics at numerous Web3 conferences worldwide, such as:
* [ETHToronto](https://www.youtube.com/watch?v=nAI_Cr5Y8JY&t=752s)
* [ETH Taipei](https://www.youtube.com/watch?v=GLCpykkb7Oc&t=6s)
* [Web3 summit](https://www.youtube.com/watch?v=VeNVFvCOg3I&t=684s)
* multiple [Ethereum Devcons](https://www.youtube.com/watch?v=NEhpPRFbTAQ)
* **ETHCC**, **ETHGlobal Sydney**, and many more...

One relevant highlight is an [event during the Ethereum 2019 Devcon in Osaka, organized by us to talk with the Core Solidity Team, tooling creators and many audititing companies about how to improve the state of contract verification.](https://www.youtube.com/watch?v=NEhpPRFbTAQ&t=238s)

## 2019: Polkadot Ecosystem

During a **Dat conference** (p2p data replication technology), we met Joshua Mir (jam10o), an early member of the Kusama Council and a Kappa Sigma Mu member, and discussed how the Polkadot architecture is such a good fit in the European context and shortly after, while we were mentoring hackathon participants during the EthBerlin Zwei event, we sat down with him to flesh out the idea for the DatDot parachain — a peer-to-peer data availability parachain bridging the Polkadot and Dat ecosystems, similar to Filecoin or todays Polkadot Crust, but for Dat instead of IPFS.

**This was the turning point for us at PlayProject** that shifted our attention from Ethereum towards Kusama/Polkadot and we joined the **Polkadot ecosystem** by giving a [talk at the web3 summit in Berlin](https://www.youtube.com/watch?v=VeNVFvCOg3I&t=684s) about the vision to combine the DatDot parachain with a verfiable smart contract search engine.

It included ideas for storing verified Solidity source codes in a decentralized version control system built on Dat, utilizing the DatDot parachain to gurantee data availability, but it was quite a bit ahead of its time.
[(see smartcontract.codes screencast)](https://smartcontract-codes.github.io/assets/search-engine_and-editor-demo.mp4)

Our [DatDot parachain project](https://datdot.org/) received a grant from the Web3 foundation and allowed us to start the work on DatDot as a crucial component of the idea presented during the first Web3 Summit as a parachain bridge project between the Polkadot Ecosystem, Ethereum and the Dat Ecosystem.

After achieving the milestones, we received additional treasury funding in 2022 (still in its Gov 1 phase) to continue working on DatDot and advance the parachain concept further, which is now nearing testing phase in 2024.

<style>
/* Use https://unbounded.polkadot.network/ */
#doc, body {
--brightpink: hsla(328, 100%, 55%, 1);
--background: #181a1b;
--boxes: hsla(328, 100%, 20%, 1);
--titles: #e6007a;
--text: #ddd;
--tablehead: hsla(328, 100%, 30%, 1);
--tablecells: hsla(328, 100%, 10%, 1);
--tablecells: var(--background);
--links: hsla(328, 100%, 55%, 1);
--listnumbers: var(--titles);
--quotes: #999;
}
#doc blockquote, .ui-content blockquote {
color: var(--quotes) !important;
}
#doc h1, #doc h2, #doc h3, #doc strong,
.ui-content h1, .ui-content h2, .ui-content h3, .ui-content strong {
color: var(--titles) !important;
letter-spacing: -.02em !important;
}
body, .ui-view-area, .ui-content, #meta-title-tags > div {
background-color: var(--background) !important;
}
#doc, .ui-content {
color: var(--text) !important;
}
#doc summary, .ui-content summary {
cursor: default !important;
margin: 0 !important;
padding: 0 !important;
}
#doc details, .ui-content details {
background-color: var(--boxes) !important;
background-color: var(--background) !important;
border-radius: 10px !important;
padding-left: 30px;
padding-right: 30px;
padding-top: 0px;
padding-bottom: 0px;
margin-top: 0px;
margin-bottom: 0px;
}
#doc summary::marker, .ui-content summary::marker {
content: '';
}
#doc a, #doc a:hover, .ui-content a, .ui-content a:hover {
color: var(--links) !important;
}
#doc table, .ui-content table {
border: 0 !important;
font-size: 11px !important;
background-color: var(--background) !important;
}
#doc thead {
border: 2px solid var(--brightpink) !important;
border-radius: 10px !important;
border-bottom: 1px solid black !important;
}
#doc tbody, .ui-content tbody {
border: 2px solid var(--brightpink) !important;
border-top: 1px solid black !important;
}
#doc th, .ui-content th {
border: 1px solid black !important;
background-color: var(--tablehead) !important;
}
#doc td, .ui-content td {
border: 1px solid black !important;
background-color: var(--tablecells) !important;
}
#doc ul, #doc ol, .ui-content ul, .ui-content ol {
list-style: none !important;
}
#doc .marker, .ui-content .marker {
color: var(--listnumbers) !important;
}
#doc ul li::before, .ui-content ul li::before {
content: "•";
color: white;
display: inline-block;
width: 1em;
margin-left: -1em
}
</style>