ZK Hack Kraków

For any project built on top of Aleph Zero! Note: A single submission may qualify for both path and global bounty

- **In-circuit data encryption**: In the context of privacy systems with anonymity revokers (see for instance [this example](https://docs.alephzero.org/aleph-zero/protocol-details/shielder/anonymity-revokers)) one must provide encryptions of in-circuit witnesses, thus really implement in-circuit encryption. In this bounty we would like you to implement and benchmark a symmetric encryption scheme as a Halo2 circuit. An example basic design is provided [here in the doc](https://docs.alephzero.org/aleph-zero/protocol-details/shielder/snark-friendly-symmetric-encryption), and other useful resources include [this research paper](https://eprint.iacr.org/2023/520.pdf) and [this blog article](https://blog.taceo.io/how-to-choose-your-zk-friendly-hash-function/). - **User-side proving of Merkle paths in the browser**: When proving relations dealing with notes in privacy systems (akin to ZCash or TornadoCash) the most expensive part is proving inclusion in a Merkle tree. In [this repository](https://github.com/Cardinal-Cryptography/client-side-proving-benchmarks), we have included benchmarks of proving inclusion in a Merkle tree for circuits written in Halo2, compiled to WASM and running in the browser. We challenge you to propose some improvements that could lead to better prover efficiency. Some concrete ideas: - Direct optimization of Merkle proof in WASM (focus on chrome) — this does not require knowledge of Halo2. - Rewriting the circuit by reusing some columns or reducing the number of rows. - Using a different hash function. - Advanced: use a different proof system. (If you want to try this, then please contact one of the mentors, because not all stacks are viable for client-side proving). - **User-side proving of Merkle paths on mobile**: Apart from the web-browser benchmarks above, we would like to challenge you to run our merkle-tree circuits on mobile devices. In other words, the goal is to run the prover on a mobile phone, either Android or iOS, so as to yield as low as possible running times. It’s up to you to choose the details on how the prover is set up! - **Wrap zk-STARK into Halo2**: STARKs have good scalability, but poor verification time, which can be improved by wrapping STARK proof into SNARK. The goal here is to implement a circuit with efficient zk-STARK verification in halo2 and demonstrate efficiency of cryptographic primitives built on this system (e.g. Merkle proof, hashing, ECC signatures) **Judging criteria for hacker path**: - Measurable improvements of prover time (note that we expect no serious degradation in verifier time and proof size) - Quality of presentation - Viability - Universality of the solution - We prioritize solutions that are based on Halo2 proof system, although this is not a hard requirement

- **ZK-based games**: Many games might leverage hidden information, giving players an advantage of using secret strategies. Such games would often use a central coordinator (server) which holds the player’s secrets. ZK gives us the power to design games that don’t require a central coordinator, and instead could be deployed on a blockchain, with ZK-proofs replacing the central coordinator. We ask you to design and implement games with smart contracts hiding private information. Examples of gaming privacy are: card decks, secret abilities, planning of moves, sharing information with trusted players. Examples of ZK-based games: - [Dark Forest](https://blog.zkga.me/announcing-darkforest) - [On-chain Wordle](https://github.com/kroist/encryptedWords) - **General ZK apps**: If you're considering a non-gaming app, feel free to submit it under this 'wild card' bounty. Potential applications might include whitelisted private auctions, private DAOs, proof of personhood, or peer-to-peer lending. This list is not exhaustive but intended to inspire. Your innovative ideas are welcome! **Judging criteria**: - Viability of an app - In case of games: fun. How engaging and replayable is the game - Quality of the presentation - Novelty in the usage of ZK, how crucial ZK is in your game (can the game be build without ZK?) - Overall quality of UX and code

Thanks to our Prize Partner **ZKV**, the best projects (aka *Finalists*), the project selected by the partipicants (aka *Hacker's Choice*), and the best technical project (aka *Chewing Glass*) will share a prize amount of $20,000

**Description**: Step into the innovative realm of the Mina Protocol and the Protokit framework (a modular and privacy enabled application chain development framework for the MINA ecosystem). --> Build an application or library that reshapes privacy. This challenge seeks projects that harness Mina's lightweight blockchain to redefine secure transactions and interactions. By leveraging Protokit's frameworks - privacy-enabled modules, succinct zkVM, and seamless wallet integration, your creation should offer a new practical utility. **Requirements**: - The project must be implemented using protokit - Correct usage of the on-chain execution model using runtime modules (bonus for usages of hybrid execution model) - Demo UI that showcases the project (suitable projects only) - Tests required for projects that don’t have a UI, bonus for all other - Correct implementation of application in the provable code model **Judging criteria**: - Code/project quality - Usability - Documentation

**Description**: - Step 1 - [Complete Tutorial 1 of o1js](https://docs.minaprotocol.com/zkapps/tutorials/hello-world) - Step 2 - [Complete Protokit’s Quickstart](https://protokit.dev/docs/quickstart) **Requirements**: Complete both Steps and come show our team in-person at our booth. First 20 people will earn 100 MINA each! **Judging criteria**: - Submit Github repo with this completed tutorial - Cannot have existed before ZK Hack dates - Upon completion of this challenge, you must come by the MINA booth to show the team

**Description**: Develop a smart contract that links your blockchain address to your geographic location for KYC compliance, allowing us to ring fence users in unfriendly jurisdictions like US. It should integrate KYC data from trusted sources like Coinbase, Binance, or banks and record user activities such as PnL, trading volumes, and liquidation scores. This contract will enable a system where documented financial activity allows users to immediately access premium fee tiers on our DEX, Lighter. This setup motivates a shift from centralized exchanges like Binance to Lighter, rewarding users for their trading performance. The final product will be a user-friendly smart contract with a robust API, designed for easy integration across platforms (DEXes, other exchanges, social media), facilitating straightforward submission of activity proofs. Resources: - Lighter details: [Lighter.xyz](Lighter.xyz) - zkEmail for privacy-focused verification: [zkEmail](https://prove.email/) - zkP2P technology: [zkP2P](https://zkp2p.xyz/) - Contact [@manudepfyffer](https://t.me/manudepfyffer) and [@alexvelea](https://t.me/alexvelea) on Telegram for more info **Requirements**: - Only use zk where there would be an added privacy or scalability benefit. - Think about what activity is most relevant to exchanges (PnL, Volume, Liquidations) - Other requirements are outlined in description

**Description**: Hylé is a blockchain focused on verifying all types of zero knowledge proofs, enabling fast, cheap settlement. Hylé separates execution, settlement and storage to give you maximal flexibility. You can execute your smart contracts off-chain anywhere you like, on a rollup, on-premise or even client-side. You can store your data securely in your backend, IPFS, Arweave or any other long-term solution: Hylé provides the verifiable source of truth for your end user. With Hylé, you can build permissionless zk-applications and still decide if you make your data public or if you keep it private. On top of that, Hylé verifies all zero-knowledge proofs, so you can choose your proving scheme, your language, your prover, and still get instant finality and enhanced security. Our website: [https://www.hyle.eu/](https://www.hyle.eu/), our doc: [https://docs.hyle.eu/](https://docs.hyle.eu/). Best overall project using Hylé for settlement: Deploy a smart contract on Hylé and leverage its unique properties in a zkApp. **Requirements**: Needs to be deployed on at least one Hylé devnet, bonus if public devnet.

**Description**: Hylé does not specify what an account or user identity is. This opens up plenty of avenues for interesting identity providers. **Requirements**: Needs to be deployed on at least one Hylé devnet, bonus if public devnet, and offer an innovative deployment of identity providers.

**Description**: Smart Contracts can use permissionless private transactions via opaque state commitments. **Requirements**: Needs to be deployed on at least one Hylé devnet, bonus if public devnet, and use permissionless private transactions via opaque state commitments.

**Description**: Hylé only stores state commitments, so your state can be very fancy or very large. **Requirements**: Needs to be deployed on at least one Hylé devnet, bonus if public devnet, and offer an innovative use of verifiable off-chain storage.

**Prerequisite**: It can be *any zk-rollup prover* other than the following provers: Taiko, Starknet Stone, Polygon zkEVM. - the prover should accept a witness and generate a valid proof file - the verification should succeed using the proof as input 1. **Generating and registering a key to access the Gevulot Devnet**: - Follow the instructions [here](https://docs.gevulot.com/gevulot-docs/devnet/key-registration). 2. **Integration, packaging and deployment of a prover program**: - Gevulot allows you to easily deploy any arbitrary prover and verifier program on the network. It is very easy to develop or modify a prover or verifier to run in the network. Almost any program that can be compiled as an ELF binary for the Linux x86_64 architecture works, but in order to integrate the program with Gevulot and for it to be able to handle received workloads, it needs to work with the specified [gRPC protocol](https://github.com/gevulotnetwork/gevulot/blob/main/crates/shim/proto/vm_service.proto). For further details see the below instructions: - [Integration details](https://docs.gevulot.com/gevulot-docs/devnet/integration) - [Packaging](https://docs.gevulot.com/gevulot-docs/devnet/prover-verifier-packaging) - [Deployment](https://docs.gevulot.com/gevulot-docs/devnet/deployment) 3. **Demonstrate proof generation**: - Initiate sample *Run* transactions with sample inputs, and demonstrate proof generation and verification on Gevulot Devnet.

(e.g. using reth) **Prerequisite**: It should successfully run an EVM smart contract that performs a ZK verification of proof. - the deployed verifier should result in a successful verification 1. **Generating and registering a key to access the Gevulot Devnet**: - Follow the instructions [here](https://docs.gevulot.com/gevulot-docs/devnet/key-registration). 2. **Integration, packaging and deployment of a prover program**: - Gevulot allows you to easily deploy any arbitrary prover and verifier program on the network. It is very easy to develop or modify a prover or verifier to run in the network. Almost any program that can be compiled as an ELF binary for the Linux x86_64 architecture works, but in order to integrate the program with Gevulot and for it to be able to handle received workloads, it needs to work with the specified [gRPC protocol](https://github.com/gevulotnetwork/gevulot/blob/main/crates/shim/proto/vm_service.proto). For further details see the below instructions: - [Integration details](https://docs.gevulot.com/gevulot-docs/devnet/integration) - [Packaging](https://docs.gevulot.com/gevulot-docs/devnet/prover-verifier-packaging) - [Deployment](https://docs.gevulot.com/gevulot-docs/devnet/deployment) 3. **Demonstrate proof generation**: - Initiate sample *Run* transactions with sample inputs, and demonstrate proof generation and verification on Gevulot Devnet.

**Prerequisite**: It can be any prover from any use case. - it should use multiple witnesses as inputs - it should perform multiple proofs - the results of those proofs should provide the inputs of the recursive proof - verification should succeed 1. **Generating and registering a key to access the Gevulot Devnet**: - Follow the instructions [here](https://docs.gevulot.com/gevulot-docs/devnet/key-registration). 2. **Integration, packaging and deployment of a prover program**: - Gevulot allows you to easily deploy any arbitrary prover and verifier program on the network. It is very easy to develop or modify a prover or verifier to run in the network. Almost any program that can be compiled as an ELF binary for the Linux x86_64 architecture works, but in order to integrate the program with Gevulot and for it to be able to handle received workloads, it needs to work with the specified [gRPC protocol](https://github.com/gevulotnetwork/gevulot/blob/main/crates/shim/proto/vm_service.proto). For further details see the below instructions: - [Integration details](https://docs.gevulot.com/gevulot-docs/devnet/integration) - [Packaging](https://docs.gevulot.com/gevulot-docs/devnet/prover-verifier-packaging) - [Deployment](https://docs.gevulot.com/gevulot-docs/devnet/deployment) 3. **Demonstrate proof generation**: - Initiate sample *Run* transactions with sample inputs, and demonstrate proof generation and verification on Gevulot Devnet.

**Prerequisite**: It can be *any prover from any use case*, other than the following provers: Taiko, Starknet Stone, Polygon zkEVM. - the prover should accept a witness and generate a valid proof file - the verification should succeed using the proof as input 1. **Generating and registering a key to access the Gevulot Devnet**: - Follow the instructions [here](https://docs.gevulot.com/gevulot-docs/devnet/key-registration). 2. **Integration, packaging and deployment of a prover program**: - Gevulot allows you to easily deploy any arbitrary prover and verifier program on the network. It is very easy to develop or modify a prover or verifier to run in the network. Almost any program that can be compiled as an ELF binary for the Linux x86_64 architecture works, but in order to integrate the program with Gevulot and for it to be able to handle received workloads, it needs to work with the specified [gRPC protocol](https://github.com/gevulotnetwork/gevulot/blob/main/crates/shim/proto/vm_service.proto). For further details see the below instructions: - [Integration details](https://docs.gevulot.com/gevulot-docs/devnet/integration) - [Packaging](https://docs.gevulot.com/gevulot-docs/devnet/prover-verifier-packaging) - [Deployment](https://docs.gevulot.com/gevulot-docs/devnet/deployment) 3. **Demonstrate proof generation**: - Initiate sample *Run* transactions with sample inputs, and demonstrate proof generation and verification on Gevulot Devnet.

**Description**: Build a cryptographic tool that supports social good/that benefits society. Your project can focus on areas such as privacy, accessibility, or identity, but is not limited to these fields. **Requirements**: We welcome any application, provided you can demonstrate how it serves the greater good. **Judging criteria**: - Impact on public good - How ambitious is the problem your project addresses? - How many would benefit from it? - What additional applications could your project enable? - The usability of the project and its entry barriers - Economic barriers - Hardware barriers (possible decentralization)

**Description**: Keep it strange, build your protocol using lattice cryptography! When it comes to Rust, there are not that many lattice cryptography libraries available. Here we challenge you to be a pioneer and fill this gap with your contribution. Draw inspiration from resources like [https://github.com/CMMayer/Toolkit-for-Ring-LWE-v1.0](https://github.com/CMMayer/Toolkit-for-Ring-LWE-v1.0). **Requirements**: The project needs to use lattice-based cryptography. **Judging criteria**: - Quality of the implementation. - Relevance of the primitive implemented. We encourage you to implement a scheme that has the potential of being widely used by Rust cryptographers.

**Description**: The advent of generative AI models presents a challenge: distinguishing between content created by humans and content generated by AI. One approach to address this issue involves cryptographically signing human-created content. However, this solution has significant limitations. For example, suppose Alice takes a photo and signs it (cryptographically). If Alice or someone else wishes to crop the photo or adjust its size, the initial signature becomes invalid for the modified photo, requiring Alice to sign the modified file. This scenario is impractical and unworkable, as we cannot expect content authors to always be available to sign their modified content. One way to tackle this problem is to design a zk-proof system that allows to prove statements of the following type: “This piece of content was modified from a piece of content X that held a valid signature”. The proof of this statement can then be used as a sort of “signature” for the modified piece of content. **Note**: Keep in mind that the above is just an example. We welcome and expect projects addressing the provenance problem in other creative ways. **Requirements**: On Starknet/using Cairo **Judging criteria**: - Resilience against AI agents - Versatility - Efficiency **Some references**: - [https://mit-genai.pubpub.org/pub/uk7op8zs/release/2](https://mit-genai.pubpub.org/pub/uk7op8zs/release/2) - [https://direct.mit.edu/dint/article/5/1/139/109494/Provenance-documentation-to-enable-explainable-and](https://direct.mit.edu/dint/article/5/1/139/109494/Provenance-documentation-to-enable-explainable-and)

**Description**: Build a project that combines zk technology and machine learning. You might consider designing a protocol for one of the following: - Proving correct inference of a machine learning model - Proving correct training of a model - Federated learning - Others: surprise us with your creativity! **Requirements**: The project must be centered around the topics of machine learning and zero-knowledge proofs. **Judging criteria**: - Quality and originality of the cryptography underlying the project. That is, we will value projects that propose cryptographic protocols that are effective and creative in tackling the project’s goals. - Quality of the implementation. References (this list is not exhaustive by any means, we also encourage you look for your own references): - An introduction to zero-knowledge machine learning: [https://worldcoin.org/blog/engineering/intro-to-zkml](https://worldcoin.org/blog/engineering/intro-to-zkml) - [https://github.com/worldcoin/awesome-zkml](https://github.com/worldcoin/awesome-zkml) - [https://www.modulus.xyz/](https://www.modulus.xyz/) - [https://dev.risczero.com/zkvm/quickstart](https://dev.risczero.com/zkvm/quickstart)

**Description**: Avail is the permissionless unification layer for Web3. Build your project such that it adds to Avail’s core functionalities or enhance its ecosystem for users/developers. Projects can range anything from innovative bridging solutions, light client improvement, unique rollup constructions/tooling for Avail DA, Developer Tooling enhancements, DA Cost Calculators, Inscription Marketplace and much more. We’re looking for innovative projects that can help improve Avail’s ecosystem. Project Ideas: - Add p2p feature to [Avail's web LC](https://light.avail.tools/), that allows it to be connected to the light client p2p network ([repo](https://github.com/availproject/light-client-web)) - Build a bridge JS SDK that allows for easy interaction with the Avail bridge contracts and exposes all data from our [Bridge API](https://github.com/availproject/bridge-api) - **P2P AddressBook**: - Create a web app which uses the Avail Light Client in crawl mode to log addresses and timestamps of peers as they join a network - **Bonus points**: The p2p network could use websocket communication to establish connections with other Light Clients without needing a public multiaddress - **IoT WebApp:** Build an IoT web app of your choice on Raspberry Pi/BeagleBone/any suitable RTOS device using the Avail Light Client connected to a public Avail network like Goldberg [Check out this page for more ideas](https://avail-project.notion.site/Avail-DA-Dev-Onboard-Hackathon-Edition-6ce01faa760b41b79b3ea7758a6265e5?pvs=4) **Requirements**: - Needs to build directly on Avail DA - Project can be core protocol enhancements or developer tooling - Helps enhance Avail's ecosystem in some way (preferred) - Projects using Avail's light client P2P network are also eligible - Projects building upon or improving any of Avail's existing tools and technologies are eligible **Judging criteria**: - Technology Implementation - Presentation - Viability and potential for further development

**Description**: Build a DA cost comparison tool to showcase the cost efficiency of using Avail DA as the data availability layer over blobs in post-4844 Ethereum. Bonus points if you can showcase the cost efficiency across Ethereum L1 and major rollups and rollup stacks (Polygon, Optimism, Arbitrum, zkSync Starknet) if they used Avail DA. **Requirements**: - Must be user-friendly - Bonus points if the application is fetching dynamic data costs (static is also fine) **Judging criteria**: - Technology Implementation - Presentation - Viability and potential for further development

**Description**: Avail DA is a robust DA base layer for developers to spin up fast, cheap, and secure rollups. Build your project that utilizes AvailDA’s validity proven expandable blobspace meaningfully Anything from building a micro-rollup, appchain, CDK chain built on AvailDA, etc. works! Build anything on AvailDA across domains like Privacy, DeFi, NFTs/Socials, Gaming, and anything in general. Project ideas: - Use Stackr SDK to build a microrollup - Use Polygon CDK/Madara with Avail DA to build an application specific rollup - Build a Validium with Risc0/SP1 zkVMs built on Avail DA [Check out more ideas here](https://avail-project.notion.site/Avail-DA-Dev-Onboard-Hackathon-Edition-6ce01faa760b41b79b3ea7758a6265e5?pvs=4) **Requirements**: - Needs to build on a rollup stack that integrates with Avail DA - Needs to use Avail DA - Can be in any domain from Privacy, DeFi, NFTs/Socials, Gaming, and anything in general - Needs to be a new project. Any pre-existing project MUST mention what has been done beforehand and explicitly state what was accomplished during the hackathon **Judging criteria**: - Idea - Implementation - Presentation - Viability and potential for further development

**Description**: Build a liquid staking protocol for Avail either directly on the node, a substrate pallet, or on Ethereum powered by a bridge, or via any other means. **Requirements**: - A functional UI for the liquid staking protocol - Needs to be a new project. Any pre-existing project MUST mention what has been done beforehand and explicitly state what was accomplished during the hackathon **Judging criteria**: - Technology implementation - Presentation - Viability and potential for further development

This track encourages participants propose and implement ideas for enhancing core functioning, The focus areas include the development of Mini-zkCPU, Keccak Implementation, and Benchmarking. There will be 2 bounties categories in this track, **Mini-zkCPU** and **Keccak Coprocessor Optimization and Benchmarking**. ### Mini-zkCPU The zkEVM architecture ressembles that of a traditional CPU, featuring essential components such as registers, a program-loaded ROM, an ALU, and memory. This design enables efficient management of arithmetization, allowing state changes to be expressed through a set of constraints. The objective of this bounty is to implement a streamlined iteration of the zkCPU architecture, optimized and adaptable beyond the limitations of EVM transaction encoding. **Criteria:** * *Correctness and Completeness*: The implemented zkCPU should accurately adhere to the specifications and requirements outlined. * *Efficiency*: The zkCPU design should demonstrate improved efficiency compared to the existing architecture, particularly in terms of resource utilization and computational performance. * *Compatibility*: The implemented zkCPU should seamlessly integrate with existing zkEVM frameworks and protocols without introducing compatibility issues. * *Documentation*: Brief documentation covering the design, implementation, and rationale behind the zkCPU architecture should be provided to facilitate understanding and future development efforts. ### Keccak Coprocessor Optimization and Benchmarking Keccak plays a crucial role in Ethereum as the primary hash function, essential for transaction validation and storage compression, thus ensuring blockchain reliability and security. The zkEVM incorporates a dedicated coprocessor for executing and verifying Keccak hash computations. This bounty seeks to propose an optimized version of the Keccak coprocessor within the zkEVM, potentially removing restrictions aligned with the current design. Additionally, the performance of the optimized coprocessor will be evaluated based on metrics such as the number of Keccak operations, proving time, proof size, and verification time. **Criteria**: * *Optimization*: The proposed optimized Keccak coprocessor should demonstrate significant improvements in computational efficiency and resource utilization compared to the existing implementation. * *Performance Benchmarking*: Brief benchmarking results to validate the performance enhancements achieved by the optimized coprocessor. * *Security*: Measures should be implemented to ensure the security and integrity of the optimized coprocessor, including resistance to potential cryptographic attacks. * *Compatibility*: Compatibility with existing zkEVM frameworks and protocols should be maintained to ensure seamless integration and interoperability.

This track invites ideas on extending the Polygon zkEVM Stack with a few ideas. Some of them are mentioned below. ### Removing Censorship Resistance Censorship resistance is paramount to ensure the integrity and decentralization of the network. This bounty focuses on implementing mechanisms to remove censorship resistance, including thoughts like decentralized sequencing or encrypted transaction batching, etc. **Criteria**: * *Correctness and Soundness*: The implemented mechanisms should accurately and securely enable to present the concept of removing Censorship Resistance. * *Innovation*: Innovative approaches and enhancements to existing mechanisms are encouraged to strengthen censorship resistance within the zkEVM ecosystem. ### zkEVM Testing Frameworks/Suites Develop comprehensive testing frameworks for the zkEVM, covering stress testing, unit testing, and integration testing. Maybe try simulating high transaction volumes to assess zkEVM performance under peak loads, or validate interactions between zkEVM components to ensure seamless operation. Implement test coverage analysis and code review procedures to identify and address potential vulnerabilities. Consider integrating with existing testing frameworks and libraries to leverage community resources and best practices. **Criteria:** * *Coverage*: How well do the testing frameworks cover various aspects of zkEVM functionality? * *Effectiveness*: How accurately do the testing frameworks identify potential issues and vulnerabilities? * *Desired Output*: Testing frameworks for the zkEVM, including scripts, test cases, and documentation. Some of the repositories to look for: * [https://github.com/0xPolygonHermez/zkevm-node/tree/develop/test](https://github.com/0xPolygonHermez/zkevm-node/tree/develop/test) * [https://github.com/0xPolygonHermez/zkevm-rom/tree/main/test](https://github.com/0xPolygonHermez/zkevm-rom/tree/main/test) * [https://github.com/0xPolygonHermez/zkevm-prover/tree/main/test](https://github.com/0xPolygonHermez/zkevm-prover/tree/main/test) ### Forced Batching Implement forced batching mechanisms to optimize transaction processing and network efficiency in the zkEVM, Explore concepts such as transaction priority queues, dynamic batching algorithms, and fee-based incentivization to maximize transaction throughput and minimize latency. Consider compatibility with existing zkEVM protocols and standards to ensure seamless integration and interoperability. **Criteria:** * *Efficiency*: How effectively do the forced batching mechanisms optimize transaction processing and network efficiency? * *Scalability*: To what extent do the forced batching mechanisms improve the scalability of the zkEVM network? * *Desired Output*: Implementation of forced batching mechanisms within the zkEVM, along with performance analysis and scalability testing results. ### Resources [Polygon zkEVM Repository](https://github.com/0xPolygonHermez) Repository containing a few circom examples, some handy scripts and an example of a zkDapp built on top of Polygon zkEVM: - [https://github.com/RogerTaule/example-repo](https://github.com/RogerTaule/example-repo) Circom: - [Circom Docs](https://docs.circom.io). - [SnarkJS](https://github.com/iden3/snarkjs) (generating a Groth16/PlonK/FflonK from a circom) PIL: - [PIL documentation](https://wiki.polygon.technology/docs/category/polynomial-identity-language/) - [PIL-STARK repository](https://github.com/0xPolygonHermez/pil-stark) (generating a STARK from a PIL) zkASM: - [zkASM documentation](https://wiki.polygon.technology/docs/category/zk-assembly/) - [Polygon zkEVM ROM zkASM's implementation](https://github.com/0xPolygonHermez/zkevm-rom)

**Description**: Fhenix is an L2 on ETH that uses Fully Homomorphic Encryption (FHE) to provide privacy. For our track, we are looking for developers who are interested in building full-stack applications in the Fhenix ecosystem that use encrypted computation. This can be anything from on-chain poker, dark pools, confidential voting, etc. We’re open to ideas and look forward to seeing what you and your team come up with! **Requirements**: A successful submission will follow all of the requirements. We are looking for projects that have the potential to contribute something new and creating to the Fhenix ecosystem. This means that we would ideally like to see full stack applications that are ready to be hosted on a public domain and use encrypted computation. These projects should bring something new to the ecosystem, not specifically the field. We would like to see projects successfully integrated as a usable product for our testnet, so that other community members have the opportunity to participate as well. Test cases will also better help us discern between successful and unsuccessful projects. Aside from the product side of things, we would like to see collaborative and methodical increments to the underlying codebase. This means that teams should be pushing as often as is pragmatic for each dev. We don’t want to see a few single large pushes. **Judging criteria**: We are looking for projects that are creative and technically complex. The ideal project would be a novel application of our FHE operations, that hasn’t been seen before. This can be in the form of novel library integrations, applications or even contract logic. We are looking for robustness, as stated, we want to reward to promote projects that we believe will be contributing products in our ecosystem. Ideally we would like to see applications that show off the unique features that are idiosyncratic to FHE specifically. Basically, why do you need composable privacy, vs traditional point of attestation privacy.

**Description**: zkSync recently added support for several precompiles including ecMul, ecPairing, ecAdd, modexp and FRI Verifier. We would love to see hackers leveraging these to build innovative ZK-based applications on zkSync. **Requirements**: 1. Application use ZK tech and is deployed on zkSync Sepolia 2. A clear README.md with a short-sentence description of your app, team and background, installation/execution process that work, and problems you faced 3. A clear 2-4 minute video demo walking through your Dapp 4. Bonus points for producing a tutorial **Judging criteria**: - Innovation: How innovative your application is, and is it solving a clear problem? - zkSync specific: Are you using zkSync's specific features (Account Abstraction, State-differences)? - Documentation: Is you application well documented (description, code, problem faced)

**Description**: Build and implement popular cryptographic primitives that can be utilized by other developers. Some of these primitives may utilize our new gadgets that make bitwise operations more efficient. Examples (but not limited to): - Array lookup primitive - Merkle patricia tree, - Merkle mountain range, - BigInt library, - BLS signatures, - Threshold signature schemes (Frost, Arctic), - Efficient MSMs, - ASCII to/from base64 conversion, - Synamic input sha256 - And more!... Some starting work on Array lookup primitives [here in this repository](https://github.com/o1-labs/o1js/pull/1253) Total pot of 14,000 MINA SPLIT: - First: Up to 4,000 tokens - Second: Up to 3,000 tokens - Third: Up to 2,000 tokens *Multiple winners allowed in each place, prize amounts are decided based on code usability. + Honorable Mentions (projects that had a great attempt but didn't quite get over the line): Up to 1,000 tokens. **Requirements**: - The project must be implemented using o1js - Algorithms or implementation need to be correct (it’s acceptable to mock certain parts of the implementation, but it’s important to be able to see the core idea of the submission and follow the core design) - A demonstration of how the feature should be used (can be in the form of tests) - Project did not exist before zkHack **Judging criteria**: - Correctness of algorithm/implementation - Code/project quality - Usability - Utility and breadth of the applications the data structure makes possible - Documentation

**Description**: [See all details here](https://fairmath.notion.site/Fair-Math-zkHack-Krak-w-2024-bounties-187e8459eb5548fb9d621a8d4a75a30a) **Requirements**: [See all details here](https://fairmath.notion.site/Fair-Math-zkHack-Krak-w-2024-bounties-187e8459eb5548fb9d621a8d4a75a30a) TLDR: 1. Use one of the supported FHE libraries 2. Publish your project in a public repo on GitHub, under Apache 2.0 license 3. README.md file of your repo should contain instructions on how to execute your solution **Judging criteria**: Submissions will be evaluated based on the following criteria: 1. Correctness and accuracy 2. Execution time That is, the winner will be the fastest application whose output is correct and accurate.

**Description**: [See all details here](https://fairmath.notion.site/Fair-Math-zkHack-Krak-w-2024-bounties-187e8459eb5548fb9d621a8d4a75a30a) **Requirements**: [See all details here](https://fairmath.notion.site/Fair-Math-zkHack-Krak-w-2024-bounties-187e8459eb5548fb9d621a8d4a75a30a) TLDR: 1. Use one of the supported FHE libraries 2. Publish your project in a public repo on GitHub, under Apache 2.0 license 3. README.md file of your repo should contain instructions on how to execute your solution **Judging criteria**: Submissions will be evaluated based on the following criteria: 1. Correctness and accuracy 2. Execution time That is, the winner will be the fastest application whose output is correct and accurate.