ZKsync Builder LabAn Interactive Protocol Learning, Assessment and Developer Activation Platform

Token Mechanics Community Activation Program
1

Applicant: Willy (Zuhudev)
Project Lead: Willy (Zuhudev)
Project Duration: 6 months
Funding Requested: $16,665
Project Category: Developer Education, Developer Tooling and Ecosystem Growth
Initial Implementation: Kenya
Long-Term Reach: East Africa, Africa and the global developer community

1. Executive Summary

ZKsync Builder Lab is an interactive developer learning and assessment platform designed to help developers understand ZKsync architecture, experiment with protocol concepts, solve technical challenges and progress towards building applications within the ZKsync ecosystem.

ZKsync already provides developer documentation, quickstarts, tutorials and development tools. These resources enable developers to configure environments, create smart contracts and deploy applications. Builder Lab does not seek to duplicate these resources or replace official documentation.

Instead, it addresses a complementary opportunity: helping developers develop a deeper practical understanding of how the underlying architecture works through interactive experimentation, structured technical challenges and measurable learning outcomes.

The project’s central component will be an Interactive Protocol Simulator. It will provide browser-based educational models of selected ZKsync OS concepts, allowing developers to change inputs, observe state transitions, investigate execution scenarios and understand the relationship between sequencing, execution and proving.

The simulator will be supported by three components:

  1. Structured Learning Environment: Guided learning modules introducing ZKsync architecture, protocol concepts and development workflows.

  2. Practical Assessment Engine: Scenario-based exercises, debugging challenges and automated assessment to evaluate understanding.

  3. Guided Building and Verification: A practical development pathway that connects learning to smart contract deployment on the ZKsync OS Developer Preview testnet.

Together, these components will create a continuous learning experience:

Understand → Explore → Experiment → Assess → Build → Verify.

The initial implementation will be delivered over six months, beginning in Kenya. The project will conduct seven developer workshops and make the platform publicly accessible online.

The six-month targets are:

  • 200 registered developers.

  • 80 developers completing the foundational learning path.

  • 120 developers completing at least one practical challenge.

  • 50 independently verified testnet deployments.

  • Seven developer workshops reaching approximately 240 participants.

The project requests $16,665 to develop the platform, conduct developer activation activities, evaluate outcomes and publish reusable open-source infrastructure.

The long-term objective is to establish a practical developer learning resource that can support ZKsync education and developer engagement across African communities and beyond.

2. Problem Statement and Identified Opportunity

ZKsync has invested in developer documentation, development tools, quickstarts and educational resources. These provide developers with important instructions and technical references for building within the ecosystem.

However, access to documentation and the ability to follow a development workflow do not necessarily demonstrate that a developer understands the architecture or can independently reason about its technical behaviour.

A developer may successfully complete a deployment tutorial without understanding the underlying execution model, the relationship between protocol components or the technical implications of different execution scenarios.

This creates an opportunity to complement existing developer resources with an environment focused on interactive understanding and practical assessment.

2.1 The specific opportunity

Builder Lab will address the following learning and developer experience challenges:

Understanding complex architecture

Some protocol concepts are difficult to understand through written explanations alone. Developers can benefit from being able to interact with simplified models and observe how changes in inputs affect system behaviour.

Moving beyond tutorial completion

Following a tutorial demonstrates that a developer can complete a prescribed workflow. It does not necessarily establish whether they understand why each step works or can independently solve related problems.

Developing practical reasoning

Developers need opportunities to investigate technical scenarios, identify incorrect assumptions and understand the consequences of different inputs and decisions.

Demonstrating understanding

Learning platforms commonly record lesson completion. Builder Lab will add practical assessments that record whether developers can successfully complete selected technical exercises.

2.2 The gap Builder Lab addresses

The project focuses on integrating four capabilities into one structured developer learning experience:

  • Interactive exploration of selected ZKsync architecture concepts.

  • Scenario-based experimentation and technical diagnosis.

  • Practical assessment of developer understanding.

  • A measurable progression from learning to real development activity.

The distinction is important: Builder Lab is not claiming that ZKsync lacks quickstarts, deployment instructions or smart contract tutorials.

Its contribution is an interactive environment that complements those resources by making selected protocol concepts explorable and assessable.

2.3 Ecosystem relevance

ZKsync’s current documentation introduces ZKsync OS as the next-generation ZK Stack architecture, including its execution environment, sequencer and Airbender proving system.

This architecture creates an opportunity for focused educational experiences that help developers understand how the system’s components relate to one another.

Builder Lab will use the selected architecture as the foundation for its initial learning and simulator content.

Relevant official resources:

3. Proposed Solution

ZKsync Builder Lab will provide a browser-accessible platform combining interactive education, protocol simulations, practical challenges and guided development.

The platform will be designed around a progressive learning experience in which developers first understand selected concepts, explore them through simulations, complete assessments and then apply their knowledge through development exercises.

3.1 Component One: Structured Learning Environment

The learning environment will provide a structured introduction to ZKsync architecture and the technical concepts relevant to developers.

The initial release will contain at least four modules.

Module 1: Introduction to ZKsync

  • The role of ZKsync within the Ethereum ecosystem.

  • An introduction to the ZK Stack.

  • ZKsync’s network and ecosystem architecture.

  • An introduction to ZKsync OS.

Module 2: Understanding ZKsync OS Architecture

  • State transitions and execution.

  • The role of the sequencer.

  • Execution environments.

  • The relationship between execution and proving.

  • The role of the Airbender proving system.

Module 3: Understanding Developer Workflows

  • Development environment configuration.

  • Foundry and Hardhat workflows.

  • RPC endpoints and network configuration.

  • Smart contract compilation and testing.

  • Relevant development tools.

Module 4: Building on ZKsync

  • Creating a basic Solidity smart contract.

  • Compiling and testing a contract.

  • Deploying to the selected test environment.

  • Interacting with deployed contracts.

  • Connecting a simple frontend.

Each module will include learning objectives, explanations, practical examples, exercises and links to relevant official documentation.

The curriculum will complement official resources rather than reproduce existing documentation.

3.2 Component Two: Interactive Protocol Simulator

The Interactive Protocol Simulator will be the central technical component of Builder Lab.

It will provide deterministic educational models that allow developers to explore selected ZKsync OS concepts through direct interaction.

Developers will be able to change inputs, observe state transitions, investigate outcomes and understand how different parts of the architecture relate to one another.

The simulator will be an educational model, not a replica of the production protocol. It will not claim to implement a live sequencer, production execution environment or cryptographic proving system.

Initial simulator scenarios

Scenario 1: State Transitions and Transaction Execution

Developers will interact with a simplified state-transition model.

They will:

  • Submit simulated transactions.

  • Modify transaction inputs.

  • Observe changes to the simulated state.

  • Compare successful and unsuccessful execution outcomes.

  • Investigate why different inputs produce different results.

The objective is to help developers understand the relationship between transaction inputs, execution and resulting state.

Scenario 2: Sequencing and Transaction Ordering

Developers will explore a simplified sequencing model.

They will:

  • Submit multiple simulated transactions.

  • Change their ordering.

  • Observe how ordering affects the processing sequence.

  • Compare resulting state under different scenarios.

  • Investigate controlled examples of invalid or conflicting operations.

This scenario will help developers understand the role of sequencing in processing transactions.

Scenario 3: ZKsync OS Execution and Proving Architecture

This scenario will focus on an important characteristic of ZKsync OS.

The architecture uses a shared codebase that is compiled to different targets: x86 for the sequencer runtime and RISC-V for the Airbender proving system. Execution and proving operate as separate services while sharing the same program and semantics.

The simulator will provide an educational representation of:

  • The relationship between the shared state-transition logic and its different compilation targets.

  • The role of the sequencer runtime.

  • The role of the proving service.

  • How execution results relate to proof generation and verification.

  • Why shared program semantics matter.

The exercise will not attempt to generate actual ZK proofs or reproduce the production proving pipeline.

Simulator interaction and assessment

Each scenario will include:

  • An explanation of the concept.

  • Configurable inputs.

  • Interactive state or process visualisation.

  • Guided exercises.

  • Expected and unexpected outcomes.

  • Technical explanations.

  • Assessment questions or practical tasks.

The simulator will use deterministic TypeScript state machines. Its outputs will be reproducible and testable, allowing the team to create reliable exercises and automated evaluation.

Each model will explicitly document its assumptions and limitations to prevent educational simplifications from being mistaken for production protocol behaviour.

3.3 Component Three: Practical Challenge and Assessment Engine

The assessment engine will evaluate whether developers can apply the concepts they have explored.

It will include at least five practical challenges.

  1. State Transition Challenge: Demonstrate understanding of transaction inputs and resulting state changes.

  2. Sequencing Challenge: Investigate transaction ordering and identify how it affects processing outcomes.

  3. Architecture Challenge: Identify the roles and relationships of selected ZKsync OS components.

  4. Debugging Challenge: Diagnose controlled technical scenarios and select or implement an appropriate correction.

  5. Development Challenge: Complete a guided smart contract exercise and submit a deployment for verification.

The assessment engine will provide:

  • Automated evaluation where appropriate.

  • Hints and explanations.

  • Retry opportunities.

  • Feedback on incorrect answers.

  • Challenge completion records.

  • Progress tracking.

The system will prioritise practical understanding and problem-solving rather than memorisation.

3.4 Component Four: Guided Development and Deployment Verification

Builder Lab will connect interactive learning with practical development.

Developers will follow a guided smart contract workflow using supported tools such as Foundry or Hardhat.

The workflow will cover:

  • Creating a development project.

  • Writing a basic Solidity contract.

  • Compiling and testing the contract.

  • Configuring the target network.

  • Deploying the contract.

  • Interacting with the deployed contract.

Target network

The initial integration target will be the ZKsync OS Developer Preview testnet.

The current official documentation provides a public Developer Preview environment with EVM-compatible development workflows and support for familiar tools such as Foundry and Hardhat.

The network will be confirmed and tested during Month 1. If the environment changes during implementation, the team will use the currently supported official development environment and document any changes.

Deployment verification

The platform will independently check publicly observable deployment information, including:

  • Network and chain ID.

  • Contract address.

  • Deployment transaction hash.

  • Transaction success status.

  • Available contract bytecode.

Verification will use public RPC endpoints and supported blockchain explorer or API services.

The platform will not require users to submit private keys or expose wallet credentials.

The purpose of this component is to connect the learning journey with a verifiable building outcome, not to duplicate the deployment instructions already provided by official ZKsync documentation.

3.5 Component Five: Builder Profiles

Each developer will have a profile recording their progress through Builder Lab.

The profile will include:

  • Completed learning modules.

  • Simulator exercises completed.

  • Practical challenges passed.

  • Development exercises completed.

  • Independently verified deployments.

Profiles will provide a transparent record of platform activity.

They will not be presented as formal professional certifications or guarantees of developer competence.

4. Developer Journey

Builder Lab will connect the different components into one structured pathway.

1. Understand: Complete learning modules introducing selected ZKsync concepts.

2. Explore: Interact with simulator scenarios to investigate protocol behaviour.

3. Experiment: Change inputs, compare outcomes and investigate controlled technical scenarios.

4. Assess: Complete practical challenges and receive feedback.

5. Build: Follow a guided smart contract development workflow.

6. Verify: Deploy to the selected test environment and submit the transaction for independent verification.

7. Demonstrate: Record completed activities and verified outcomes in the developer’s Builder Profile.

This structure makes practical understanding and building activity central to the learning experience.

5. Differentiation from Existing ZKsync Resources

Builder Lab recognises the value of ZKsync’s existing developer ecosystem and will complement rather than replace its resources.

Existing resource Existing value Builder Lab’s contribution
Official documentation Technical explanations and references Interactive exploration of selected concepts
Developer quickstarts Environment setup, contract creation and deployment workflows Scenario-based learning and technical assessment
Community tutorials Practical examples and learning materials Connected simulation, assessment and progress tracking
External developer courses Broader programming and blockchain education ZKsync OS-focused interactive learning
Workshops and hackathons Developer engagement and project creation Continued learning and structured practical progression

Core differentiation

The primary innovation is the integration of interactive protocol models with practical assessment.

A developer will not simply read about sequencing or execution. They will interact with a simplified model, observe how changes affect outcomes and complete an exercise demonstrating their understanding.

The guided development and deployment workflow will then connect that learning to practical building activity.

Builder Lab’s value is therefore not the number of tutorials it contains. It is the connected experience of exploring, experimenting, assessing and demonstrating understanding.

6. Developer Validation

The project will conduct structured feedback sessions with approximately 15–20 developers who have experience exploring ZKsync or related Ethereum development environments.

This research will take place during the first project month and inform the prioritisation of simulator scenarios, learning modules and assessment challenges.

The research will investigate:

  • Which official ZKsync resources developers currently use.

  • Which architecture concepts are difficult to understand.

  • Where developers struggle when moving from tutorials to independent problem-solving.

  • Which technical scenarios they would find useful to explore interactively.

  • What debugging and learning challenges they encounter.

  • Whether practical assessments would improve their learning experience.

The project will document the findings and explain how they influenced the initial platform design.

The interviews will not be represented as completed research before they have taken place.

7. Target Beneficiaries

The primary beneficiaries will be:

Solidity Developers: Developers familiar with Solidity who want to understand ZKsync OS and explore its development environment.

Ethereum Developers: Developers seeking to expand their knowledge and build applications within the ZKsync ecosystem.

University Students: Students interested in blockchain development who need structured learning and practical exercises.

Early-Stage Web3 Developers: Developers with basic programming experience who need a more guided introduction to ecosystem-specific concepts.

Hackathon Participants: Developers seeking practical learning resources and opportunities to demonstrate working applications.

Independent Builders: Developers exploring ZKsync and looking for opportunities to improve their technical understanding.

Secondary beneficiaries will include university technology clubs, developer communities, hackathon organisers and ecosystem contributors who can use the platform as a learning resource.

8. Implementation Plan and Timeline

The project will be delivered over six months through defined technical and community activation milestones.

Month 1: Technical Validation and Foundation

Activities:

  • Review official ZKsync OS documentation and development resources.

  • Conduct 15–20 developer feedback sessions.

  • Confirm the target architecture and test environment.

  • Define the technical architecture.

  • Finalise the learning curriculum.

  • Specify simulator scenarios and assessment requirements.

  • Develop the initial platform interface.

Deliverables:

  • Technical architecture document.

  • Developer feedback and validation report.

  • Confirmed architecture and network scope.

  • Learning curriculum.

  • Simulator and assessment specifications.

  • Initial platform interface.

Month 2: Learning Environment and Simulator

Activities:

  • Develop the four initial learning modules.

  • Implement the simulator framework.

  • Build the first three interactive scenarios.

  • Implement controlled debugging exercises.

  • Establish progress-tracking infrastructure.

  • Conduct functional and technical testing.

Deliverables:

  • Four learning modules.

  • At least three functional simulator scenarios.

  • Initial progress tracking.

  • Test results and technical documentation.

Month 3: Assessment and Public Release

Activities:

  • Implement the assessment engine.

  • Develop at least five practical challenges.

  • Integrate the guided development workflow.

  • Implement testnet deployment verification.

  • Test the complete developer journey.

  • Publish the initial platform release.

  • Conduct the first developer workshop in Nairobi.

Deliverables:

  • Functional assessment engine.

  • Five practical challenges.

  • Guided smart contract development workflow.

  • Deployment verification functionality.

  • Public platform release.

  • Nairobi workshop report.

Month 4: Developer Activation

Activities:

  • Conduct workshops in Kisumu and Mombasa.

  • Conduct a workshop at Mount Kenya University.

  • Support platform onboarding.

  • Introduce participants to interactive exercises.

  • Monitor practical challenge completion.

  • Collect feedback and improve the learning experience.

Deliverables:

  • Three completed workshops.

  • Participation and activity records.

  • Platform feedback report.

  • Documented improvement priorities.

Month 5: Continued Developer Activation

Activities:

  • Conduct a workshop in Eldoret.

  • Conduct a workshop at the Technical University of Mombasa.

  • Conduct a workshop at Egerton University.

  • Support practical challenge completion.

  • Encourage guided development and testnet deployments.

  • Collect feedback and monitor progress.

Deliverables:

  • Three additional workshops.

  • Updated platform functionality.

  • Practical challenge records.

  • Deployment verification records.

Month 6: Evaluation and Sustainability

Activities:

  • Evaluate platform usage and developer participation.

  • Assess learning and challenge completion.

  • Review verified deployments.

  • Consolidate workshop outcomes.

  • Finalise technical documentation.

  • Publish the final source code and project report.

  • Establish the maintenance and regional expansion plan.

Deliverables:

  • Final public platform release.

  • Open-source repository and documentation.

  • Final evaluation report.

  • Sustainability and regional expansion plan.

9. Measurable Outcomes and Success Indicators

The project will evaluate success through platform adoption, practical learning outcomes, verified development activity and community engagement.

Indicator Six-month target
Registered developers 200
Developers completing foundational learning path 80
Developers completing at least one practical challenge 120
Independently verified testnet deployments 50
Developer workshops 7
Workshop participants 240
Structured learning modules At least 4
Interactive simulator scenarios At least 3
Practical assessment challenges At least 5

Measurement methodology

Registrations: Unique registered platform accounts.

Learning completion: Developers completing the defined foundational learning path.

Challenge completion: Developers passing at least one practical assessment.

Verified deployments: Unique successful contract deployments that meet the platform’s verification requirements.

Workshop participation: Attendees recorded across the seven workshops.

The project will separately report attendance, registrations, learning completion, challenge completion and verified deployments.

It will also track conversion between stages to identify where developers disengage and where improvements are needed.

10. Technical Architecture and Implementation

Builder Lab will use a modular architecture designed for maintainability, testing and future expansion.

Frontend

  • Next.js.

  • React.

  • TypeScript.

The frontend will provide the learning environment, simulator, assessments and developer profiles.

Simulator

  • Deterministic TypeScript state machines.

  • Modular scenario architecture.

  • Reproducible inputs and outputs.

  • Automated scenario tests.

Backend and data

  • Next.js API routes.

  • PostgreSQL.

  • Supabase where appropriate for authentication and database infrastructure.

The backend will manage user progress, assessment results and platform records.

Smart contract development

  • Solidity.

  • Foundry or Hardhat.

  • Supported ZKsync development tooling.

Blockchain integration

  • Public ZKsync RPC endpoints.

  • Blockchain explorer and API integrations where available.

  • Contract deployment and transaction verification.

The architecture will separate educational simulation logic from actual blockchain interactions.

The platform will not execute arbitrary untrusted user code on its backend or require users to provide private keys.

Technical scope will be finalised during Month 1 following confirmation of the target architecture and supported development environment.

11. Team and Relevant Experience

Willy (Zuhudev) — Project Lead and Full-Stack Blockchain Developer

Willy will lead product direction, technical architecture, platform implementation and project delivery.

Responsibilities:

  • Overall technical direction.

  • Platform architecture and development.

  • Interactive simulator implementation.

  • Learning and assessment system integration.

  • Blockchain integration and deployment verification.

  • Technical testing and milestone delivery.

Relevant previous work includes CKB Builder Lab, an interactive developer onboarding platform developed under the Nervos Spark Program.

This work provides relevant experience in designing and implementing browser-based developer learning infrastructure, guided learning experiences and practical challenges.

Project evidence:

Charles Luke — Full-Stack Developer

Charles will contribute to frontend development, backend implementation and blockchain integrations.

Responsibilities:

  • Frontend development.

  • Backend implementation.

  • Platform integrations.

  • Developer experience improvements.

  • Testing and technical support.

Charles also contributes to CryptoGalaxy, a Kenyan Web3 community involved in developer education, campus engagement and blockchain community activities.

Relevant links:

Delivery and Accountability

The team will work through defined technical milestones and maintain the project source code in a public repository.

Progress will be documented through working demonstrations, code contributions, testing results and milestone reports.

Each milestone will have identifiable acceptance criteria so that funding can be assessed against completed outputs rather than general activity.

12. Budget and Funding Allocation

Total funding requested: $16,665

The budget covers platform development, testing, seven developer workshops, project evaluation and contingency.

A. Platform Development — $6,500

The development allocation is based on an estimated 260 hours of technical work at a blended planning rate of $25 per hour.

Development activity Estimated hours Allocation
Architecture and frontend development 60 $1,500
Interactive learning modules 40 $1,000
Protocol simulator development 60 $1,500
Assessment engine 40 $1,000
Testnet integration and deployment verification 40 $1,000
Testing, documentation and release 20 $500
Total 260 $6,500

These are planning estimates for the blended development effort, not a claim that every task will be performed by one individual.

B. Developer Workshops — $8,400

Seven workshops will be conducted across Kenya at an estimated cost of $1,200 each.

Expense Cost per workshop
Venue and logistics $250
Refreshments $250
Transport $250
Learning materials and connectivity $150
Facilitation $200
Documentation and reporting $100
Total per workshop $1,200

Seven workshops × $1,200 = $8,400.

C. Reporting and Evaluation — $250

This allocation will support:

  • Consolidation of platform performance data.

  • Workshop outcome documentation.

  • Final evaluation.

  • Preparation of the final project report.

D. Contingency — $1,515

A contingency allocation of 10% of the $15,150 pre-contingency budget will cover reasonable unforeseen implementation or operational costs.

Budget Summary

Category Amount
Platform development $6,500
Seven developer workshops $8,400
Reporting and evaluation $250
Contingency $1,515
Total funding requested $16,665

The budget prioritises the development of reusable technical infrastructure while allocating resources to practical developer activation and measurable evaluation.

Funding will be tied to agreed milestones and demonstrable outputs.

13. Sustainability Plan

Builder Lab will be developed as an open-source resource intended to remain accessible beyond the initial funding period.

Open-source availability

The platform’s source code, technical documentation and contribution guidelines will be publicly accessible.

Modular architecture

Learning modules, simulator scenarios and assessment challenges will be developed as modular components so that improvements can be introduced without rebuilding the entire platform.

Technical maintenance

The team will maintain core functionality, address technical issues and update integrations as the supported ZKsync development environment evolves.

Community contributions

Developers and ecosystem contributors will be able to suggest improvements, contribute learning content and propose additional challenges.

Continued developer engagement

The platform will remain available to developers who want to continue learning and building after the initial workshops.

The team will use feedback and platform activity to prioritise maintenance and improvements.

14. Long-Term Regional Expansion Plan

The initial six-month implementation will establish Kenya as the starting point for a broader developer education and activation initiative.

The long-term objective is to expand Builder Lab’s reach across East Africa, other African markets and eventually the international developer community.

Expansion will be gradual and partnership-led, based on adoption, community demand and the results of the initial implementation.

Phase 1: Establishment in Kenya — Months 1–6

Activities:

  • Deliver seven developer workshops.

  • Build relationships with university technology clubs and developer communities.

  • Identify active developers interested in continued ZKsync development.

  • Evaluate participation, platform adoption and practical completion.

  • Document a repeatable regional activation model.

Expected outcome: An established Kenyan developer network and a tested model for practical developer education and community engagement.

Phase 2: East African Expansion — Year 1–2

Potential initial markets include Uganda, Tanzania and Rwanda.

Activities:

  • Identify local developer communities and university partners.

  • Establish relationships with community organisers.

  • Organise introductory and practical developer sessions.

  • Identify local representatives to coordinate activities.

  • Adapt engagement methods to local developer communities.

  • Track participation and continued platform usage.

The online platform will remain accessible to developers across the region, including those unable to attend physical workshops.

Expected outcome: An emerging East African developer network supported by local partnerships and accessible learning infrastructure.

Phase 3: Wider African Expansion — Year 2–3

Potential markets include Nigeria, Ghana, South Africa, Ethiopia and Egypt.

Expansion will be guided by developer demand, available partnerships and the capacity of local organisers.

Activities:

  • Partner with local blockchain communities and university programmes.

  • Support community-led workshops and learning sessions.

  • Collaborate with hackathon organisers and developer groups.

  • Identify local facilitators and community ambassadors.

  • Encourage cross-country developer collaboration.

Expected outcome: A broader African network of developers using Builder Lab and participating in ZKsync-related learning and development activities.

Phase 4: International Accessibility and Partnerships — Year 3 Onward

Activities:

  • Support international developer education initiatives.

  • Enable community-led learning sessions.

  • Encourage contributions from developers across different regions.

  • Explore cross-regional hackathons and collaborative programmes.

  • Establish partnerships that support long-term platform accessibility.

Expected outcome: An internationally accessible developer learning resource supported by regional communities and educational partners.

Regional Expansion Strategy

The expansion model will follow three stages:

Community Identification → Local Activation → Sustained Engagement.

The project will rely on partnerships with existing communities, universities, meetups and developer organisations rather than establishing permanent physical offices in every country.

The long-term ambition is to create a shared developer learning and onboarding resource that connects regional developer communities to the wider ZKsync ecosystem.

15. Risks and Mitigation

Changes to ZKsync Architecture or Development Environments

Network availability, development tooling and protocol architecture may change during implementation.

Mitigation: Confirm the target architecture and supported test environment during Month 1. Keep integrations modular and validate the development workflow before public release.

Inaccurate Educational Simulations

Simplified simulations could create misunderstandings if they do not accurately represent the concepts they teach.

Mitigation: Document each scenario’s assumptions and limitations, review the technical content against official resources and test the scenarios before release.

Overlap with Existing Educational Resources

Some proposed learning content may already be available through official ZKsync resources or third-party courses.

Mitigation: Position Builder Lab as complementary infrastructure. Prioritise interactive experimentation, scenario-based assessment and the connection between learning and demonstrable outcomes.

Low Workshop-to-Platform Conversion

Some participants may attend workshops without continuing to use the platform.

Mitigation: Introduce practical exercises during workshops, provide structured onboarding and encourage participants to complete challenges after the sessions.

Scope Expansion

Adding too many modules, simulator scenarios or integrations could affect delivery timelines.

Mitigation: Maintain the defined initial scope and prioritise the minimum functional release. Additional features will be considered only after core milestones are delivered.

Long-Term Maintenance

Changes to supported networks and development tools may require ongoing maintenance.

Mitigation: Use modular architecture, public documentation, open-source contributions and a defined maintenance approach.

16. Milestone Acceptance and Reporting

Funding will be tied to demonstrable project outputs.

Milestone Evidence required
Technical foundation Architecture document, research summary and confirmed network scope
Learning environment Four accessible learning modules and documented learning objectives
Simulator At least three working scenarios with tests and documented limitations
Assessment engine Five functional challenges with evaluation and feedback
Development workflow Guided contract exercise and successful testnet verification
Public release Accessible platform, public repository and technical documentation
Community activation Seven workshop reports and attendance records
Final evaluation Usage metrics, challenge completion, verified deployments and final report

The team will maintain public project documentation and provide milestone reports showing completed work, outstanding issues and evidence against the agreed acceptance criteria.

17. Expected Ecosystem Impact

Builder Lab aims to produce a practical learning and developer activation resource that can support the ZKsync ecosystem beyond the initial project period.

By the end of six months, the project aims to deliver:

  • A publicly accessible developer learning platform.

  • Four structured learning modules.

  • Three interactive protocol simulator scenarios.

  • Five practical assessment challenges.

  • A guided smart contract development workflow.

  • Testnet deployment verification.

  • Builder Profiles recording completed learning activities.

  • Seven developer workshops across Kenya.

  • 200 registered developers.

  • 120 developers completing at least one practical challenge.

  • 80 developers completing the foundational learning path.

  • 50 independently verified testnet deployments.

The longer-term value will be measured not only by how many developers are introduced to ZKsync, but also by whether they can understand selected technical concepts, solve practical problems and take verifiable steps towards building within the ecosystem.

The open-source platform will provide a foundation for continued learning, community contributions and regional developer engagement.

18. Conclusion

ZKsync Builder Lab addresses an opportunity to strengthen the connection between developer education and practical understanding.

Rather than creating another documentation website or standalone tutorial collection, the project proposes an interactive environment where developers can explore selected ZKsync OS concepts, experiment with protocol behaviour, diagnose technical scenarios, complete practical assessments and progress towards building applications.

The Interactive Protocol Simulator is the project’s central innovation. The learning environment, assessment engine, guided development workflow and deployment verification provide the supporting pathway from understanding to practical application.

Beginning with seven workshops and a publicly accessible platform in Kenya, the project will establish a foundation for wider regional expansion through partnerships with developer communities and educational institutions.

With a six-month implementation period and a funding request of $16,665, Builder Lab aims to deliver measurable developer learning outcomes, practical development activity and reusable open-source infrastructure.

The goal is to help developers move beyond following instructions to understanding the architecture, reasoning through technical behaviour and building on ZKsync with greater confidence.