ETHBerlin isn’t true to its values: ><<<<<<<<<<<<>>>> <<<<<<<<<<<<>>>>

• Consumerism everywhere. <<><<<<<
• Centrally organized. <<<>>>>>>
• Sponsored company experiences. <<<>>>>><<<>
• Tasty food. <<>><<<>>

Core values of ETHBerlin have been violated. <>>

They must be restored. <<<<<<<<<<

Our answer: aggressive non-compliance. <><<<<<<<

(and now check our highly entertaining slides)

The Problem We Solve

The organizers of ETHBerlin claim to value decentralization and independence. But why are only few highly selected companies allowed to give talks or host experiences? Where is the stage for hackers?!

Our motivation for this hackathon is to make an immediate impact and make ETHBerlin better for everyone.

That’s why we hijacked the screens (but we can’t tell you how).

We displayed a board where people could quickly post their own events, and join existing events like talks, workshops, or even jams.

Transforming ETHBerlin from pure consumption into a co-created experience.

For more info, have a look at the README or our slides

Challenges we ran into

ETHBerlin was not amused by our aggressive non-compliance, and they took our board down after a few hours. But the work continues, with the goal of bringing hackers together.

But we do. not. sleep.

GCal!

The issue it addresses is our reliance on centralised systems, particularly Google Calendar, even among those who advocate for decentralisation. It’s tough to break free from Google Calendar because of its ingrained network effects and the varying technical abilities within groups.

We often face problems like confusion over meeting links—one person might be in Jitsi while another is in a Google Meet link that was automatically added. In larger groups, especially with over 400 or 500 invites, Google Calendar struggles and centralisation issues become apparent. Sharing data with Google allows them to create detailed shadow profiles, and the political centralisation of SaaS tools can create opacity between teammates. For instance, in an organisation like Berlin, different teams may miss each other’s meetings due to separate calendar feeds. This lack of transparency can be problematic during critical moments when reaching out to the community is essential.

ZKAL offers a solution by providing a self-hosted calendar feed with a web-based widget that integrates multiple .ICS feeds. This allows for a gradual transition away from Google Calendar. Users access it through Semaphore, maintaining anonymity while proving group membership. They can RSVP publicly within the Semaphore group, which is useful for organisational transparency. Additionally, users can add events anonymously while still providing their email addresses for follow-up.

ZKAL supports multiple ICS feeds, decentralising calendar administration so different rooms or groups can operate on various systems without needing an all-or-nothing switch from Google Calendar. This approach respects the busyness of our lives and the challenges of change.

Challenges

As a developer returning after 10-15 years away, I’ve faced challenges adapting to new development patterns. I chose Svelte for its simplicity and small components but found most Web 3 APIs and SDKs are geared towards React. I encountered issues with ESM versus CJS while using Vite with Svelte and had to dig deep into libraries like Zupas and Semaphore to resolve these.

During this hackathon, I also managed night shifts at SDP’s help desk and assisted with setup tasks. Despite previous hackathons where I couldn’t submit my projects due to various frustrations, I was determined to submit this time despite the stress.

Tech

The technology used includes Svelte for its straightforward components and node adapter for easy deployment on Docker containers. It also uses Semaphore libraries and is configured through .env files.

The problem AntiPrivacyNFT solves is that it reveals NFT wallet ERC20 Positions

Challenges you ran into

Building the UI and Caching all assets 10K NFT collection. Need to find a more accurate Pricing tool and build a more robust database

Technology used

The problem the project solves is that onchain social profile front-end depends on the client. now you can personalize it yourself and share it with everybody.

Challenges you ran into

storing theming on IPFS and onchain

Technology used

NextJS for app Live URL: https://deso-profile-theme.vercel.app/

Base for Smart Contract and onchain activity Smart Contract: https://github.com/MaxBrych/ETHBerlin24-ThemeStorage-Smart-Contract

Whirl

Whirl aims to enchance privacy to Atomic Swaps from Bitcoin to Ethereum. We are utilizing P2P transactions Bitcoin’s SPV and Tornado Cash for Privacy

The problem Whirl solves

Whirl is a project that helps people swap cryptocurrencies privately and securely. It uses technologies like Next.js for the frontend, expressjs for the server, and Tornado Cash to hide transactions. By using bitcoinjs-lib and Solidity, Whirl makes sure that trades are safe and private, protecting users’ information in the digital world

Challenges you ran into

There are too many mathematical problems and Theoretical difficulties encountered in implementation

Technology used

Next.js, expressjs, Poseidon Hash, Tornado Cash, bitcoinjs-lib, Solidity

The problem CodeKarma solves

A CLI tool to check that the code you write uses dependencies that align with the social values written in your manifesto.

Challenges you ran into

Unable to resolve this issue in our project scrum board for integrating with Github Actions https://github.com/users/ltfschoen/projects/2?pane=issue&itemId=64579450

Technology used

Deno, Github Actions, Docker, Nektos Act, TypeScript

Team members

Luke Schoen Sven Buschbeck

The problem [zkTRIPSTER] solves

+Bug bounty programs in the DeFi space can be hard to run and maintain, not always honored, and may not always offer sufficient compensation for white hats. This can lead to a lack of incentive for hackers to report vulnerabilities, which can ultimately result in a less secure DeFi ecosystem. Previous work had laid down essential tools for proving vulnerabilities via ZK proofs.

+Without the conditional payment infrastructure, however, parties must trust an inherently trusted intermediary to exchange vulnerability information for reward which limits their usefulness.

+From Vendors’ perspectives, it is often cheaper and easier to pay white hats to remain quiet and drag patch the vulnerability as long as possible. All the while, black hats may find and exploit the vulnerability, leveraging Vendors’ slow response act. Public vulnerability disclosure is the only effective way of keeping Vendors accountable and efficient in patching vulnerabilities.

Challenges you ran into

1. Running the example code
2. Dealing with limitations of zkvms

Technology used

Solidity React Node zkProofs SP1 risk 0 VM EVM VIEM Rust CSS

The problem Canonical Frontend Registry solves

People get scammed by fake frontend / compromised frontends.

We propose a Web extension + smart contract which are used to verify that frontends at a particular ENS domain are legit / not compromised. Developers can attest that they own the ENS domain of a particular web frontend and then can upload the hashes of their most recent frontend builds to a contract.

When someone goes to the frontend, the web extension will get each file as it is pulled down by the index.html and hash it, checking against the information in the contract.

Challenges you ran into

Time, API restrictions in the browser for accessing cache, complexity of ENS contracts.

Technology used

Solidity, ENS, Javascript

The problem our platform solves

Our project aims to bring trust between pseudonyms in the context of freelancing so that no information beyond what is necessary is exchanged to the other party. We have taken a reputational system from a deep market, and moved it on-chain into a smart contract capable of storing this information in a way that cannot be falsified or censored. Specifically, we keep track of the reputational history of both those requesting work and those performing it so that we can eliminate the need to know the identity of the other party in every transaction that requires digital delivery.

Challenges you ran into

Integration of the 3 worlds, be, fe and crypto. Last one we didn’t beat. Developing a new economic mechanism to align incentives.

Technology used

Web2: Django, React

Web3: Wagmi, Solidity

Searcher Execute - rely on MEV searchers for on-chain actions

Searcher execute allows any searcher to execute desired tasks onchain.

While this architecture looks similar to a paymaster, the idea here is to simplify for onchain interactions and to decentralize the execution layer.

While users need to initialize transactions, this library and standard is for a decentralized searcher type execution of desired actions with a small expectation of compensation beyond the price of gas configurable by the user.

Examples of desired actions include:

1. burning an NFT after a certain amount of time
2. withdrawing from escrow contracts as needed into another smart contract
3. legacy handlers for defi
4. setting up “limit” orders
5. decentralized way to handle liquidation incentive searchers by wrapping a proprietary algorithm in a standard

Registry address:

https://sepolia.etherscan.io/address/0x23e887a11d9aff21691704ded79b332fb8bb7e9d

Example implementation:

https://github.com/iainnash/searcher-execute/blob/main/src/examples/NFTBurnTime.sol

The idea is that we can meter the gas required and return double the gas used to fund a searcher to execute a type of action we want.

Searchers can either utilize the requested timestamps for actions or if the timestamp is shown as zero, simulate all functions shown in the registry in an expectation of profit.

Users of the protocol do not need to pick one provider but can just change parameters or scripts if operating conditions change and just need to fund the contract to pay the searchers for their execution.

The idea is this standard is searcher and agent agnostic and released as a hyperstructure solidity SDK.

Challenges you ran into

• Determining a need, calculating refund amounts and economics.
• Deploying a demo project without operating searchers on testnet.

Technology used

• Solidity
• EVM
• MEV

The problem DevPazz solves

I was inspired by the fact that all developers could forget their passwords and be unable to access their SSH. Devpazz eliminates passwords by integrating QR codes through Externally Owned Accounts (EOA) wallets.

Challenges you ran into

As I tried bypassing SSH’s default authentication mechanism with a PAM file, I ran into issues, so I couldn’t get it to work bypassing traditional SSH authentication methods was very complicated, which hindered our progress. Also, I had limited knowledge of C, leading to integration issues.

Technology used

Node.js, React, and Express.js, React native., Elliptic curve cryptography for digital signatures

The problem PriMaci solve: eliminating the need to trust into public parties and private voting with MACI

Technology used: MPC (Multi-party computation), eliptic curve cryptography, Poseidon-hash based encryption+ MACI Protocol (Minimal Anti-Collusion Infrastructure)

Challenges: running and adapting MACI to MPC; conversion of cryptogrphic primitives to MPC circuits; understanding MPC dsl;

The problem [PROJECT NAME] solves

Catacombs do not try to solve any problem, its goal is to actually create problem so player can enjoy solving them.

Having said that, Catacombs is a game designed for decentralised networks. Its game mechanics is sybil resistant and cater for human players rather than bots:

It remove the usefulness of sybil by requiring player to deposit a stake to play one character and encourage player to have several character.

It make the game more human by reducing the need to transact to the minimum and instead let the gameplay play in the social layer. In Catacombs player play once a day with as many character as they chose. Each move is fully resolved onchain.

But in order to make their move, they simultaneously perform a series of action locally and play a single player experience akin to “rogue-like” games. Once they are happy with it, they also choose a strategy to play on that day against the other players.

The next day is when players reveals their move and get to discover what other have been doing. This encourage social game-play as we can regroup stand a better chance

Challenges you ran into

it was hard to reduce the scope to get something working. I also took the oportunity to explore different coding techniques and mechanics. In particular, I make use of a local EVM to remove the need to duplicate the solidity logic in the frontend, something always needed when involving commit+reveal scheme where you need to display the result of their action before they are revealed.

Unfotunately there was issues in the browser environment that took time to resolve.

It was in the end not possible for me to put all the things together and the playable version only explore the minimum. The contract is where most take place

Technology used

Solidity, Typescript, Svelte. Webgl

The problem [CVWhisper: the Vagabond CV] solves

A cheap and reasonably anonymous proof of work record.

1. Hiring is expensive: it’s normal to spend 10-15k EUR to hire a new developer in Berlin.
2. Of that, at least 3k is spent on figuring out whether the whole experience the candidate claims to have is fake.
3. Umbrellas, unofficial employment, and informal coding sessions are not outliers but the fabric of the system. People may want to have more than one CV, sometimes with little to no interactions between them, so no fingerprints and IDs will come to save us.
4. People with very different professions and skill sets may want to join the party.
5. Companies don’t mind paying to verify their employees: it’s a nice extra bonus.

Challenges you ran into

There are interesting competitors in the market, like

https://www.velocitynetwork.foundation or https://indorse-staging-bucket.s3.amazonaws.com/Indorse+2.0+Light+Paper.pdf

They are doing a great job but are a bit too KYC-focused to stay versatile. As an employee, you have to reveal A LOT about your identity, and even non-profit organizations pay a fixed tax of 2500 USD per annum to use the system. As an employee from a third-world country, you are almost doomed to fail their KYC; as an independent crypto-buddy or a journalist, you have to tell way too much about your identity.

On the other hand, something like https://www.deepskills.io (https://www.deepteams.org, https://deepworkstudio.notion.site) may nicely fit in. Their main focus is blockchain-based verification of getting things done and building a community, and their history may be organically used in our CVs

Technology used

JS/Solidity.

Nice 2 have:

• NEAR (human-readable account names with hierarchy!)
• Zupass (convenient auth)

Chimera is a wallet extension that manages multiple adresses with one mnemonic phrase.

The Problem Chimera Solves User wallets and transaction histories can be tracked, linking this data to individuals. This creates a significant privacy issue. Chimera reduces traceability and improves overall user experience by managing multiple temporary addresses with a single seed phrase.

How It Works? Users start by creating a wallet. Then, choose how many temporary addresses they need. Chimera makes a dashboard showing all these addresses. Dashboard shows all active addresses, transaction histories and other details. Chimera has an algorithm to pick the best number of addresses for each transaction for lowest gas fees.

Challenges you ran into

The eth-hd-wallet library we use has no typescript support. Eth-hd-wallet required deleting existing wallets to fetch all wallets, which took a long time to resolve due to the lack of documentation.

###Technology Used

-Express.js library -Eth-hd-wallet library -React -Plasmo

###Future Improvements Support multiple non-EVM networks, allowing users to manage temporary addresses across different blockchains from a single interface. App for IOS and Android.

https://chimera-wallet.xyz/

The problem R55 solves

R55 brings innovation to Ethereum by showing how the smart contract developer world can be if we have more VMs in execution clients. More VMs reduce vendor lock-in, potentially bring in different optimizations, increase language & compiler diversity, enable millions of new developers to be easily onboarded into Ethereum, and allow for off-the-shelf robust tooling to be used directly for smart contracts. We shouldn’t fight over one or another smart contract language, we should just use all of them!

Challenges you ran into

This was a crazy technical project to execute in 2 days, and we’re happy with the PoC we achieved. The main challenges were the sheer complexity of every module we had to build:

• Compiler for Rust to RISCV + Ethereum syscalls
• Assembly runtime + ELF linker
• Deployment code
• RISCV64 interpreter with Ethereum syscalls
• Modifying revm which we’ve used but not contributed to before

Technology used

• Rust for the whole project but also for new smart contracts
• C for test smart contracts
• rustc, cargo, LLVM
• RISCV64
• rvemu fork for RISCV64 execution
• revm for everything Ethereum

View site here: https://ethevacuations.breadchain.xyz/

The problem Eth Evacuations Donation Tracker solves

ETH Evacuations (ethevacuations.xyz) is a project to help evacuate those suffering under some of the worst human conditions possible in Gaza to evacuate and assist those who have already been evacuated with stabilizing their lives. It is being led by Kat Young who is receiving donations and then coordinating how the crypto gets directly into the hands of Gazans. While her website is well designed and gives all the information people need to understand what she’s doing, visitors can’t see what donations she has received already or as they are happening that is mobile friendly. Today at ETH Berlin, she will be interviewed on stage by Joshua Davila and we would like to use this moment to encourage those in the audience to donate and watch the donations come in real time. We’ve created a webpage that will be shown during the interview so that people can see donations live as she speaks about her experience.

Challenges you ran into

Challenges we faced included the difficulty to find a good indexing service that shows on-chain data in real-time across several chains at once and then organize the transactions into one list. Most of the other challenges we faced revolved around design and displaying the data in a way that makes sense to people watching the site and encourages donations.

We also had a launch event on Saturday which lessened the amount of time we had to work on it :)

Technology used

• Ethereum, Optimism, Arbitrum, Gnosis
• Moralis API for indexing
• React, NextJS, Netlify Cloud Function
• Figma for design

The problem PeerPack solves

It solves the problem of BigTech companies shutting down centralized package distribution systems for opensource ecosystems.

Challenges you ran into

• dependency resolving
• project management and cooridnation

Technology used

• IPFS
• Brenthy & Walytis

Intro and Objective

My main objective at EthBerlin4 was to explore the cool space around AA and get my hands dirty. The result of this is a paymaster contract that enshrines and rewards a certain set of social norms.

You follow the norms (include a certain message in your UserOp)? Society rewards you (the Paymaster sponsors your UserOps gas).

You want to change society (the types of messages the Paymaster promotes)? You’ll have to build a movement (sacrifice ETH that will help future UserOps).

Messages can take the form of “the internet should be free”, or they could be anything society (or a sufficiently determined individual) determines them to be.

Future thoughts

This is clearly a quite simplistic version of rewarding positive UserOperations and incentivizing good social behavior in blockspace, but i find the idea quite fascinating to take further.

Thanks for a great hackathon experience!

BE repo

https://github.com/bobetbat/assaver-fe

The problem AS SAVER solves

Submit your address to subscribe for push notifications if one of the blacklisted addresses sends you tokens or any other transactions

Challenges you ran into

Ensuring valid address entry and up-to-date blacklist management were significant challenges. Integrating reliable push notifications and maintaining a user-friendly interface added complexity. Securing user data and preventing misuse were top priorities.

Technology used

rpc, pwa, notifications

Unlocking the Future of Real Estate with Cross-Chain Tokenization

The problem Neth solves

Neth is designed to tokenize real estate assets using NFTs (non-fungible tokens) and facilitate cross-chain transfers of these NFTs. This contract integrates several advanced features and libraries to provide robust functionality, including:

• ERC721 standard from OpenZeppelin for NFT implementation.
• Chainlink’s Cross-Chain Interoperability Protocol (CCIP) for cross-chain messaging.
• Chainlink’s FunctionsClient for off-chain data retrieval and computation.
• SafeERC20 operations for secure token transfers.
• ReentrancyGuard for reentrancy protection.

Challenges you ran into

We ran into various technical challenges during smart contract development. Here are some of the key challenges we faced: Cross-Chain Functionality:

• Consistency and Synchronization: Maintaining data consistency across multiple chains and synchronizing state changes.

• Cross-Chain Relays: Setting up reliable and secure cross-chain relays to ensure messages are accurately and promptly transmitted between different blockchain networks.

• Handling Failures: Implementing graceful handling of message or transaction failures across chains.

Technology used

solidity, hardhat, openzeppelin, nextjs

The problem SilentVote solves This project addresses the need for secure and anonymous voting systems. By leveraging Zero-Knowledge Proof technologies, it ensures that the integrity and privacy of the voting process are maintained without compromising user identity.

Challenges you ran into

Integrating Zero-Knowledge Proof technologies for secure email verification. Ensuring real-time updates for voting results. Handling Telegram bot interactions seamlessly.

Technology used

Frontend: React Backend: Node.js Authentication: Zero-Knowledge Proof for email verification Bot: Telegram Bot API

The problem Pomar solves

Current education systems are centralized and quickly become outdated. This is no different in Web3. Builders face a paradox where access to peer-to-peer guidance is fragmented and often limited by geographic boundaries. The rapid evolution and complexity of emerging technologies only exacerbate these challenges, making it even harder for developers to find the mentorship they need. Our platform addresses these issues by creating peer-to-peer spaces where mentees can join mentors on a quest to learn something mutually beneficial. This enables personalized, secure, and privacy-focused learning journeys, fostering innovation and growth in the Web3 space.

Challenges you ran into

1.	Zupass Integration: Integrating Zupass for non-biometric identity verification presented significant challenges. We identified numerous improvement opportunities to enhance user privacy and security without compromising usability.
2.	Team Dynamics: We faced setbacks due to the loss of two team members during the project, which required us to quickly adapt and redistribute tasks to maintain progress.
3.	Ensuring Privacy and Security: Balancing privacy and security with usability was a significant challenge. We needed to ensure that mentors and mentees could interact anonymously without compromising the integrity of their identities.
4.	Creating an Inclusive Environment: Designing a system that accommodates diverse users from different geographic regions, each with unique learning needs and constraints, required a thoughtful and flexible approach.
5.	Rapid Technological Changes: Keeping up with the fast-paced nature of Web3 technologies to ensure our platform remains relevant and effective was an ongoing challenge.
6.	Integrating Feedback Mechanisms: Developing a mutual feedback system that is simple yet effective in promoting accountability and maintaining high-quality interactions.

Technology used

1. nextjs
2. zupass
3. zuauth
4. material-ui
5. supabase

Established systems are failing.

Carnation is an experiment in decentralized and encrypted communication with a focus on music as transport vessel carrying hidden messages. It empowers users to broadcast their voice and coordinate with others securely and privately all while safeguarding their anonymity.

Contribute with an audio file (wav, flac) and weave in an encrypted message into to subsonic frequencies. This hidden channel allows for discreet communication.

Carnation prioritizes anonymity, letting your voice be heard without compromising your safety. It thrives on community. It’s a space for collaboration, where people can unite and coordinate towards a shared vision.

Imagine the underprivileged individuals and collectives whose message is embedded in the music, broadcasted for all to hear, yet only those who know where to look can decipher it.

We have created CLI for encryption of the message into the wav file which is then uploaded onto ETHSwarm decentralized data storage. We have deployed our frontend via Scaffold-ETH2 and deployed our smart contracts for auction of the 24h playlist NFT (funding mechanism for data storage) on ETHSepolia.

Explore our Tech Stack diagram in our slides – here

The problem zk-twitter solves

ZK-twitter enables another avenue for ETHBerlin hackathon participants to connect with each other by dropping ZK-Proveable data (called PODs) into a publicly accessible feed

Challenges you ran into

It was difficult to find the right music to listen to while I coded (^:

Technology used

Zupass, Vercel, my brain

What’s the problem?

Online platforms in both Web2 and Web3 are being overrun by bots, leading to several critical issues:

- Spam and Scams: Bots flood platforms with unwanted messages and fraudulent schemes.
- Disinformation and Manipulation: They spread false information and manipulate public opinion.
- Reduced User Trust: The prevalence of bots erodes trust among genuine users.
- Distorted Metrics: Bots create misleading data, affecting the accuracy of platform analytics.
- Security Risks: They pose significant security threats.
- Exploitation of Tokenomics: Bots exploit the economic models of blockchain projects.
- Invasion of Privacy: They invade users' privacy.
- Disruption of Communities: Bots disrupt the functioning and harmony of online communities.

Addressing these issues is crucial to maintaining the integrity, security, and trustworthiness of online platforms.

How does PROOF OF GAMERHOOD solve this issue?

Implement a bot counter mechanism that requires users to prove they are human by playing a randomized (AI-unfriendly) mini-game during the signup process. Upon successful completion, users are issued a non-transferable ERC-721 token with a randomized expiry date.

This solution yields the following benefits:

• High entry Barriers for Bots
• Token is Reuseable on any (d)apps
• No biometrics compromised
• Extendable with proof of machine hood
• Evolvable into a SDK
• Multiple Business Model Options

Challenges encountered

While scoping of proof concept we decided for sake of time to exclude the SDK tooling as well as proof of machinehood and rather focus on demonstrating the underlying concept.

Technology used

Javascript, Hardhat, OpenZepplin, Node.js, HTML, “Snake Classic” ;)

Links

• https://github.com/Ender13120/proof-of-gamerhood
• https://github.com/Ender13120/node-multiplayer-snake
• https://t1p.de/POGHETHB04

🔓 Trigger Warding

CLICK ME FOR TRAILER!!! IT’S VERY NICE

The problem Trigger Ward solves

Programmable, encrypted & triggerable data vault. Upload and encrypt any file anonymously and have a natural language “trigger” initiate when to decrypt and publicly release the data.

Social Examples:

1. Whistleblower and Journalistic Safeguards: Automatically release decryption keys to unlock encrypted evidence or investigative reports if a whistleblower or journalist is silenced, harmed, or goes missing.
2. Protest Coordination: Encrypt and schedule the release of protest plans to prevent authorities from preempting demonstrations, ensuring activists can gather and act in safety.
3. Misconduct Deterrence: Enforce accountability by revealing the identity and actions of individuals if they engage in unethical or harmful behavior, acting as a deterrent against misconduct.

Technical problems Trigger Ward solves:

1. A crypto economically backed mechanism for verifying long tail data on-chain, using an Optimistic Mechanism. This lets Trigger ward verify natural language statements on-chain.
2. A data bridge between Ethereum and Nillion to enable programmable execution of arbitrary Nillion code from Ethereum. This is a general purpose warding mechanism that can be re-used in a number of other contexts wherein actors are economically incentivised to behave correctly

Challenges you ran into

1. Using the Nillion SDK was very janky. It is very raw (only released in the last few months) and connecting to their testnet requires permissioning. We had to hack deep into their implementation to fix a number of bugs to get things working as expected.
2. Figuring out how to more generally how to expand the usecase of a dataCrypt to be opened by a natural language trigger. Constructing a robust mechanism for this that is economically sound.

Technology used

1. Contracts: Solidity, Hardhat, foundry
2. DataCrypts: Nillion Nada contracts, Python
3. Warden: typescript
4. Frontend: React, typescript, nextjs, tailwind

**Please see the resources section of our readme for in-depth information on how the protocol works, the economic security, demo videos and detailed contract interaction examples!

CLICK ME FOR DEMO VIDEO!!! IT’S ALSO VERY NICE

The problem P2PMentorship.com solves:

https://p2pmentorship.com/ P2P Mentorship is designed to bridge the knowledge gap in the rapidly evolving field of web3 technologies. By creating a community-driven environment, the platform enables users to seek assistance from knowledgeable mentors and gain insights into the latest advancements in the web3 space. Whether you’re a beginner looking to understand the basics or an experienced developer needing specific guidance, P2P Mentorship offers a supportive and interactive learning experience.

Key Features:

• User-Friendly Interface: Easy-to-navigate platform allowing seamless connection between mentors and mentees.
• Expert Mentors: Access to a network of experienced professionals in various web3 technologies, including blockchain, smart contracts, decentralized applications (dApps), and more.
• Real-Time Q&A: Users can ask questions and receive prompt, personalized responses from mentors.
• Diverse Learning Resources: A wealth of resources including tutorials, articles, and videos to supplement learning (tbd).
• Community Engagement: Forums and discussion groups to foster community interaction and collaborative learning.
• Progress Tracking: Tools to monitor learning progress and set personal development goals (tbd).

Challenges you ran into:

• To create a super simple and easy onboarding experience for the hackers.
• To get people to try it in the hackathon, we had to create the basic MVP version till Friday, or Saturday morning, and then we had to reach out to a lot of people on Saturday to share the project link with them and they had a really positive reaction to the project, and about 6 people actually asked questions on the p2pmentorship.com, and got mentorship using the project.

Technology used:

• Nextjs
• Vercel

Pitch Deck:

https://pitch.com/v/p2p-mentorship-umb5ts

New front-end design work in progress:

https://p2pmentorship.com/home

Team:

Thank you, from Team P2PMentorship.com

• Daniel - daniel.zarzecki047@gmail.com
• Yash - yashgo0018@gmail.com
• Ranjit - devgodev@gmail.com

The problem Chainmail solves

Chainmail empowers and incentivises whistleblowers that would otherwise be too afraid to reveal vital information for fear of safety or reputational damage. By using Zero-Knowledge Proofs, we can prove the authenticity of emails while ensuring the privacy and anonymity of the seller. By using a marketplace as a mechanism of delivery, Chainmail provides additional incentive structures for those in possession of this information.

Challenges you ran into

Philosophical: There are many challenges with Chainmail. By far the most important of which is to ensure that the platform is used for public good and not abused for the solicitation of dangerous secrets such as: -> state secrets -> blackmail campaigns -> sale of stolen data -> corporate espionage

The implementation of a DAO governance structure to ensure the right kind for censorship and a curated buyer list will help solve this issue.

Technical: We had to come up with a good delivery mechanism that ensures the most trust-minimised approach whilst also operating under the limitations of the ZK circuits Chainmail is built on. We decided on a flow where both the seller and the buyer provide a stake of authenticity as a declaration of good faith under the transaction. When the buyer purchases an email, they provide a public key that the seller then uses to encrypt the email body when fulfilling the order.

As the hash of the body is provided in the ZK proof, when the buyer decrypts the email they can verify that it is the same email they have purchased.

If there is anything wrong, they can open a dispute which will then be sent to the DAO for adjudication, with the malicious party losing their stake of authenticity if they lose the outcome.

Technology used

Zero Knowledge Proofs built on top of ZK-Email (https://zkemail.gitbook.io/zk-email) Solidity Smart contract for the marketplace and on-chain verification React front-end for the application (and client side proving)

White Paper Here - FOSS Find provides a meaningful overview of (Web3) FOSS projects and communities in the shape of an intuitive interface, which offers powerful insights to help organizations and individuals benefit from and contribute to them. The problem that this solves is the difficulty of finding & choosing the most suitable (i.e. the best, or ‘healthiest’) FOSS projects/tools, for example for sustainability. Existing explorers of the FOSS landscape are not widely deployed and/or not very accessible, and often focus on metrics that are simply less than helpful.

Challenges we ran into:

* Coordination & communication, (specific team member & overall) time contraints
* Which metrics are relevant (let alone the best)?
* Researching & comparing with existing solutions
* Where to get the metrics from?
* CHAOSS API turned out to be incomplete and needs manual triggering of ingest of data scraping of metrics is slow due to rate limits & missing parallel processing

• Technology used: GitHub, LibreOffice, CryptPad, Matrix/Element, Google Drive, Thunderbird, Brave, Notepad++, Java, Node.js (Nestjs Framework), Javascript, PenPot, TypeORM, Postgres DB, HTML / CSS, EJS, Flask (python)

CloakMyFox

CloakMyFox brings fingerprinting resistance to Metamask. A fingerprint is essentially a list of characteristics that are unique to a single user, their browser, and their particular hardware setup. This project aims to enhance privacy and security for Metamask users by mitigating the risks associated with browser fingerprinting.

For my PoC, I forked Metamask and added the following fingerprinting resistance features.

Features

• Inject Ethereum Provider object only for whitelisted domains
• Avoid provider announcement for web2 websites
• Detection of wallet address leaks through cookies
• Site-specific randomised addresses (wip)

Challenges you ran into

I found debugging the Chrome Extension API code quite challenging. Some of the fingerprinting resistance techniques I wanted to implement were not possible with the existing APIs exposed by Chrome. I did not have access to Manifest V3 methods, which made me lose some time.

Technology used

Javascript, Chrome Extension API

The problem zk0fficers solves

Currently, credentials and identity is a trust based system when it comes to authenticating. At the moment, chances are any time that you want to complete KYC, you’re taking a photo of your entire identity, and shipping it off to a server whose security practises you have to trust.

This is obviously not ideal, and zk0fficer looks to provide an initial solution to reusing existing credentials anonymously.

zk0fficer allows for the reusing and validation of existing digital credentials, while keeping your credentials private. You can present your credentials to the zk0fficer, and they can validate their legitimacy, without knowing anything about them.

Challenges you ran into

This would have been a much nicer user experience if users could tap an NFC chip to retrieve their signed message they are trying to prove and reuse - but it costs $99 to use NFC chips on apple devices (and that’s after being approved!!). Aside from that, the general development was smooth, with the exception of a few API rate limits that we had to work around.

Technology used

• Aztec/NoirJS: We wrote our zero knowledge circuits to prove credentials privately in Noir, and compiled them to both WASM and Solidity contracts for testing/implementation
• Hardhat/Solidity: Our unit tests for our ciruits and proofs are all within our hardhat project (./protocol) in the repo
• NextJs: This is what our example site is built with, using Vercel to host.

For our pitch deck - we build an example site here: https://zk-officer.vercel.app/. Here’s some example accounts that you can (hopefully 🤞) use our front end with:

There’s some example videos of how to use these values in our Github README.md

The problem ZuPass Collab solves

• Onchain Community Identity for ZuPass Groups
• Trustless Group Collaboration
• Privacy Preserving Workspace

Challenges you ran into

Setup of Zupass with Permissionless Versioning issues with viem Identity Creation without using any types of Wallet Signature Connecting Private Key with the ZuPass Group

Technology used

ZuPass Groups Permissionless.js by pimlico ERC4337 compatible Safe Fileverse Collaboration Smart Contracts IPFS

CypherSmith is solving wallet address reusability & anonymity problems

Problems

Reduced Privacy: When an address is reused for multiple transactions, it becomes easier for third parties to track and analyze transaction patterns associated with that address. This compromises the privacy of both the sender and receiver, as their transaction history can be inferred from the publicly available blockchain data.

Linkability: Reusing addresses enables outside parties to link multiple transactions to a single user or entity. By analyzing transaction flows and patterns, adversaries can gain insights into the financial activities of individuals or organizations, potentially leading to identity disclosure or targeted attacks.

Security Risks: Address reuse increases the risk of security breaches and unauthorized access to funds. If an address is compromised or associated with a vulnerable system, all subsequent transactions made using that address are susceptible to exploitation, putting users’ funds at risk.

Impact on Fungibility: Fungibility refers to the interchangeability of units within a currency system. Address reusability can impact fungibility by introducing tainted coins-coins associated with undesirable activities or histories. This can lead to discrimination against certain coins and undermine the fungibility of the entire currency system.

Solution

Wallet dApp which automates the process of stealth wallet creation and management. The dApp allows to generate stealth addresses on demand for an asset receiver using elliptic curves and ephemeral keys, referencing the ERC-5564 Proposal.

Stealth addresses are generated by asset sender but the private keys are available only for the asset receiver. It is not possible to tie the stealth address to asset receiver for an outside actor.

The general usage flow of the dApp is the following:

1. Receiver registers to the platform, generates stealth meta-addresses and stores them on-chain.
2. Sender fetches the stealth meta-addresses of the receiver from the chain.
3. Sender uses the meta-addresses to generate a stealth wallet address for the receiver and sends assets to them.
4. Receiver scans the announced transaction events and finds out which stealth wallets belong to them.

Challenges we ran into

Implementing cryptography methods for private data exchange.

Trying to concentrate while also chatting with nice people around the venue :)

MVP

URL: https://cypher-smith-2c2dbbd35078.herokuapp.com/

Smart Contracts

Registry: https://sepolia.etherscan.io/address/0xD3Bef33f23A173a9b3f25f68fdaec476bcD75f75#code

Announcer: https://sepolia.etherscan.io/address/0x75b5Ac7Fee622ebd4368cF97d8F8cAA2cde2A54A#code

Stealth: https://sepolia.etherscan.io/address/0xEb49229fB71F68a03E46f19Ffa7A72b8b312AB5d#code

Technology used

Web: NextJS, React, Chakra, Heroku.

Smart Contracts: Solidity, Hardhat

The problem Zukofi solves

Often, hackathons have a Hackers Choice Award for participants to select their favourite project. These are usually held in public which can lead to quid pro quo arrangements and other privacy issues. Other than the lack of privacy, public voting has other drawbacks such as the current tally of votes influencing the future decision of voters.

Zukofi (or ZuQuoFHE from Zuzalu, quadratic voting and FHE) allows participants to prove that they are an ETHBerlin hacker and allows them to vote on projects. Each participant has a fixed budget for voting and the cost of each extra vote to a project scales quadratically. The participants encrypt their votes on the client side and send the encrypted votes to a server along with a ZK proof of inclusion showing that they are a ETHBerlin hacker.

The server checks that the voter is eligible by verifying the ZK proof of inclusion and checking that the voter hasn’t already voted. It then checks that the vote is valid and doesn’t exceed the budget. If both checks are passed, the server adds the vote to the current tally using homomorphic encryption.

Once the voting has finished, the server decrypts and reveals the final tally.

Challenges you ran into

FHE libraries are slow and heavy. To check that a vote is valid, the voter should ideally send a ZK proof that the vote was encrypted correctly and the cost of the vote is within the budget. Unfortunately, creating this proof is too expensive to do on the browser currently. So instead of the ZK proof, we homomorphically calculate the condition that cost of votes is less than or equal to the budget, decrypt this result and assert that this is true. This is a decent compromise, but it assumes that the decryption key is available during the voting phase which might not be the case if we use timelocked encryption.

Verifying the ZK proofs on-chain requires writing a custom SNARK verifier so instead we just use a central server for now. But conceptually, one can replace the server with Ethereum or any blockchain.

Technology used

• Zama TFHE library
• Zupass

The problem BlockWhisper solves

In today’s digital age, privacy, and identity crises present significant challenges, particularly within the blockchain space. Despite the promise of decentralization, many systems still expose individuals to risks of identification and retaliation when reporting sensitive information. Existing whistleblowing platforms, such as SecureDrop and GlobaLeaks, primarily cater to individual organizations and do not leverage the potential of blockchain technology to provide a truly decentralized, anonymous, and self-governing reporting system.

BlockWhisper aims to address these gaps by offering a decentralized platform that enables anyone to anonymously share sensitive information without fear of identity exposure, harassment, or legal repercussions. Our platform ensures that no single entity controls the information, thus preventing censorship and promoting transparency. BlockWhisper can ensure full anonymity while maintaining a reputation system. This way, users can build trust in the platform without revealing their identities.

Keywords: Freedom of speech, Anonymity, Decentralization

Challenges you ran into

Throughout the hackathon, we faced several challenges. While we managed to address the critical ones, there are some edge cases that are still open for further investigation.

Enable free transactions Users should not face the issue of having to acquire ETH anonymously for transaction fee funding.

https://eips.ethereum.org/EIPS/eip-2711#sponsored-transactions -> withdrawn https://eips.ethereum.org/EIPS/eip-3074#another-sponsored-transaction-eip -> draft https://eips.ethereum.org/EIPS/eip-4337#paymasters -> draft Solution: We mimic faucets to fund user accounts, thereby alleviating them from the struggle to onramp anonymously.

Decentralized Reputation Scoring Without Public Accounts to Ensure Anonymity: The score is implemented as a snapshot, calculated for any new submission, and attached to the new submission’s data structure utilizing a zero-knowledge proof. Herein, we do not prove exact qualities but abstract ones to avoid identity leaks. A proof could be something like “the anon submitted greater than ten submissions before”, “the anon’s submissions have a mean reputation (upvotes/(upvotes + downvotes)) greater than 50 percent”, “the anon’s worst submission has a score greater than 20 percent” or similar. This effectively supports a feedback cycle—mandatory for any self-governing system—without publicly disclosing an identity or even a pseudonym, which links submissions. We employ the technique of hierarchical deterministic wallets to create single-use wallets that mint a soul-bound NFT as proof of authorship (PoA) over a submission.

Technology used

Frontend: Typescript, Next.js, hCaptcha | Backend: Solidity, Ethereum | ZKP: Circom, snarkjs

The problem [EdGapBridger] solves

In this era of hyper-acceleration, AI and Web3 technologies are speeding up societal inequalities like never before. Education equality and access to digital skills are crucial to prevent further societal divides.The EdGapBridger Hackathon aims to empower the next generation by providing them with the digital skills and education they need to thrive in the digital age.

Challenges you ran into

Being not a coder but a social engineer (a sociologist by training) and motivated by being a mom of a teenager, I’ve eagerly worked all night but still ended up with messy code. Well, you grow with your challenges and my super power is my off chain network anyway.

Technology used

Fracaster Frames (is that what has to go here?)

The problem shovel-bootstrap solves

Developers who want to consume data from blockchains face challenges such as setup complexity, data scaling, and privacy. In this project, we enhance the user experience for shovel. We’ve created a helm chart which allows developers to quickly get started extracting their own data into Postgres. Similar functionality exists in tools like Dune and Etherscan, but they do not support full privacy and ownership of the data.

From the shovel docs:

Shovel is an open source tool for synchronizing Ethereum data to your Postgres database. Own your blockchain data without vendor lock-in.

Challenges you ran into

Understanding how shovel’s configuration fits into the kubernetes deployment pattern.

Technology used

helm, kubernetes, postgresql

The problem TrustKey Recovery solves

Securing crypto accounts is paramount. Traditional methods often rely on centralized custodial services, which can be a single point of failure. Our project introduces a decentralized approach to account recovery, focusing on leveraging trust within a user’s social circle—friends, family, and close acquaintances—without the necessity for them to have prior a crypto wallet, nor maintaining any funds. It all starts with a pub/private key pair.

Key Features

• Trusted Contacts: Users can designate multiple trusted contacts who can assist in recovering their accounts, with a selected threshold for added security. These contacts can be anyone with a mobile phone or a laptop.
• No Wallet Required: Trusted contacts do not need to download a wallet, or backup a seedphrase. Instead, our webapp generates an ethereum compatible public/private key pair, and store it on their secure element of their device with Passkeys.

WebAuthn Integration:

• LargeBlob Extension: We leverage the new WebAuthn LargeBlob extension to securely store the private key within the Passkey authenticator. This ensures that the private key is protected and only accessible by the designated contact through their WebAuthn credentials.

Anonymity and Security:

• Local Signing: In the event of a recovery request, the trusted contact can sign a recovery message locally on their device. This message confirms their agreement to assist in the account recovery process.
• No On-Chain Transactions: Trusted contacts never have to perform any on-chain transactions. Their role is limited to locally signing the recovery message, ensuring their actions remain anonymous and private.
• Enhanced Privacy: The recovery process maintains the privacy of the trusted contacts, as their involvement is never broadcasted on the blockchain, even during recovery.

Challenges you ran into

Initially, we wanted to experiment with the new WebAuthn PRF extension. This extension allows sites to request that a WebAuthn authenticator create a Pseudo-Random Function (PRF) along with a credential, and query that PRF during assertions. Unlike the WebAuthn LargeBlob extension, where the secret is generated in the browser by a third-party cryptography library, allowing parties to store a small amount of data (key) associated with a credential.

However, we encountered limited support for the WebAuthn PRF extension and could not find any devices that support it. As a result, we decided to use the LargeBlob extension instead. Even then, LargeBlob is only supported on the latest Apple devices and newer devices with Chromium browsers. We expect support for these WebAuthn extensions to improve as more devices and operating systems adopt them.

Technology used

• Main Account: Candide’s Account Abstraction: Smart Wallet creation, Gas Sponsorship, and Social Recovery Module. Safe Accounts for the Base Account Contract.
• Recover Account: WebAuthn LargeBlob Extension

The problem GitVault solves

• Identity-less code collaboration on a censorship resistant version control
• Ability to make codebases decentralised within 5 clicks

99% of web3’s codebase lives in github - a centralised git client that uses servers that can be censored for various reasons. One of the examples include the censorship of Tornado cash from Github. After the censorship, most of the contributors were prosecuted and the project was no longer maintained due to the risk of getting doxxxed. With GitVault, you can backup your existing github repositories into a p2p storage network within just 5 clicks. You can also create and collaborate on p2p repositories that do not reveal your identity for contributions.

Challenges you ran into

• Finding a team (had to hack solo)
• Sorting out some Waku light client errors
• Making IPNS work reliably

Technology used

Waku (p2p gossipsub network), some libp2p, IPFS, IPNS, NextJS, TailwindCSS, Github Developer API

The problem How SNARKs Compress Infinite Computation solves

• The cryptography behind zkSNARKs is notoriously difficult to understand
• SNARKs are either explained in an oversimplified manner or overly complicated via papers and multi-chapter blog series
• It takes a lot of effort to gain an intuition around the core “magic” (how to flatten linear computations into a constant proof)
• Understanding the math behind SNARKs has a lot of pre-requisites that are often taken for granted

Challenges you ran into

• Creating a simplified version of SNARKs that was mathematically accurate while still being simple enough to explain in 1 video
• Deciding what details to black box vs. explain
• Learning how to use manim to animate different mathematical concepts and steps

Technology used

• manim
• iMovie
• 120h of Homo Sapien Brain™️compute time

The problem KinkLink solves

Traditional dating apps require users to constantly swipe and make decisions about potential matches, leading to decision fatigue and cognitive overload. Moreover, many people cannot express themselves freely, out of fear of prosecution or worse. Even in more liberal places, users may feel hesitant to express their true preferences and identity on dating platforms due to concerns about privacy and judgment. And lastly, existing dating platforms often rely on proprietary algorithms for matchmaking, leaving users in the dark about how matches are made.

Challenges you ran into

We could not get the Waku demo repo to work reliably and decided to leverage libp2p instead. We also ran into the issue of dependency hell in python. It took a nightmarish amount of time to get the FSM application configured properly with compatible part and a considerable amount of hacking and a bit of monkey patching was required.

Technology used

Autonolas, Tendermint, HOPR RPCh, Libp2p, Gnosis Safe, Docker, Solidity

The problem eof-etk solves

EOF (EVM Object Format) is a series of proposals for introducing a versioned format for EVM bytecode, considered for inclusion in Pectra network upgrade of Ethereum Execution Layer. See https://evmobjectformat.org/, also https://eips.ethereum.org/EIPS/eip-7692 and https://github.com/ipsilon/eof/blob/main/spec/eof.md

etk (https://github.com/quilt/etk) is a developer toolkit and assembly language for EVM, written in Rust.

Integration of EOF support into etk assembly allows to generate EOF-compliant bytecode by writing smart contract code in low-level assembly language. As of now there is no production-ready EOF bytecode compiler/assembler and established compiler projects (Solidity, Vyper) are only starting to support EOF. Generating EOF bytecode needed for testing EVM implemenations is mostly done using ad-hoc tooling. Support in etk provides access to using EOF to a wider audience of EVM enthusiasts.

What was achieved

• New syntax for defining code/data sections was proposed and supported in parser.
• EOF container bytecode is generated in case at least one section is defined.
• It is possible to define multiple code sections and a data section in a contract.
• Defining code section type using attributes like “section .code inputs=1 outputs=0 max_stack_height=2”
• Basic validation of section definitions order
• Calculating correct section size when %push() macro and labels are used
• Bonus: a bug fixed https://github.com/quilt/etk/pull/147

Next steps

• Supporting new instructions proposed by EOF
• Supporting nested container sections
• Automatic calculation of max_stack_height
• Updating documentation

Challenges you ran into

• Lack of Rust skills
• Needed to learn basics of Pest language used by etk for parser grammar definition. (https://pest.rs)
• Lack of time.

Technology used

Rust, EVM, EOF.

The problem Hackaton Center - Powered by dRPC solves

Hackaton Center: Mint dynamic NFTs that evolve as you level up

We wanted to create a cool collectible for hackaton enthusiasts that would evolve as they collect the Hackaton Poap’s (QR for simplicity of the MVP) Each hackaton will have a POAP (QR for simplicity of the MVP) that will redirect to mint the NFT, if you have already have an NFT minted it will raise your level and evolve your NFT giving you a nice collectible NFT as a prize.

Challenges you ran into

Some problems with the connection of the contract to the frontend since the contract is v2 and the utils are not updated yet we had to manually update and import some parts of the updated code.

Technology used

Rust for the contract React for frontend Mintbase-Js for connection

Cr3dential

Cr3dential addresses inefficient academic credential verification, data privacy concerns, and cumbersome academic record management for students. Using zero-knowledge proof (zk proof) technology, it ensures secure, instant verification without exposing personal data. Cr3dential provides a streamlined platform for managing and sharing academic achievements, enhancing trust and efficiency for both students and institutions.

Challenges you ran into

• Get verifiable credentials from school
• Zk Proof

Technology used

• Front: React, Web3auth
• Blockchain technology: Ethereum
• ZK: Circom/snackJS

The problem [PROJECT NAME] solves

Challenges you ran into

Zero Knowledge Proof

Technology used

React.js, Solidity, Python, ZK Proff

The problem zkStealth solves

This project combines two complementary and powerful privacy technologies:

• Stealth Addresses: We can generate virtually unlimited addresses where users can receive funds.
  • We do not need the collaboration of the user to generate a new address, we can derive as much as we want from a single stealth address published on ENS.
  • They provide a convenient way to receive funds offering privacy to the sender.
• Zero Knowledge Proofs (ZKP): We can prove to a smart contract pool that we own a specific address without revealing our identity.
  • They allow us to combine the funds received from a stealth address into a single address.
  • Hence, they provide a private way to receive funds.

Together stealth addresses and ZKP they work better:

• ZKP provide a way to stealth addresses to use the funds after they have been received.
• Stealth Addresses make ZKP more accessible to the general ethereum user, as they are simple and familiar addresses (or smart wallets) compatible with the rest of the ecosystem.

Challenges you ran into

I had no previous experience on FluidKey and zkBob libraries, so it has been a challenging and intense night (the ones i like)!

• First I learned how stealth addresses are derived, and how they are used to create Safe Multisigs. That was fine since FluidKey offered an example explaining that.
• What has been more challenging has been obtaining the private keys and a way to encode the Safe transactions to send the money away from the stealth addresses. It’s not well documented, and the FluidKey UI is not open-sourced unfortunately. I had to reverse-engineer this part, and use some workarounds (I couldn’t use the safe relayer to interact with the Safes, unfortunately).
• Integrating zkBob has been interesting too. I was in luck since their UI is open-sourced so I could check how they derive the zkAccount mnemonic from an injected wallet signature.
• The proof-of-concept has a lot of rough corners in terms of UX, but it works as intended, being able to receive funds from fluidKey and send them to zkBob!

Technology used

The technologies used in this project are:

• FluidKey, a tool to generate stealth addresses that received a prize in the EthRome Hackathon 2023. We use their @fluidkey/stealth-account-kit to generate and manage stealth addresses.
• zkBob, a tool to manage zk-SNARK proofs of deposits on privacy pools, very impressive and neeeded evolution of privacy wallets within Ethereum. We use their zkbob-client-js to generate and manage zkAccounts.

I am applying in the Smart Contracts Excellence Award Track even though I did not write any smart contracts, as my project didn’t require it. However, it needed a deep understanding of the intricacies of both protocols and the ability to create a complex workflow that ensures their interoperability. I hope the judges can appreciate the technical difficulty and the innovative approach I employed. Thank you for considering my project.

The problem MultiFactor Wallet solves

MultiFactor Walle provided a Web2-like experience to Web3 authentication while preserving user security and privacy.

Currently, the market of similar tooling is filled with players that try to monetize on the infrastructure. The existing solutions host 2 out of 3 Shamir Secrets Sharing shares in their databases. Other solutions have a closed-source secure enclave where user wallets are accessed. Even worse most of these solutions do not allow for a seamless exit and are not censorship-resistant, meaning that providers can block access to the server.

The MultiFactor Wallet uses a MFKDF algorithm to construct the wallet’s private key from the user’s own credentials such as email, passwords, or TTP applications (Google Auth etc). This allows a PK to be stored nowhere but on the user’s device, preserving full self-custody of the wallet while maintaining a Web2-like experience with familiar authentication methods.

Challenges you ran into

Currently, the only API to connect the dApp is WalletConnect which requires a lot of work and is error-prone.

Technology used

The current implementation is created as a TypeScript web application using React. It uses a JavaScript implementation of MFKDF https://github.com/multifactor/MFKDF to manage the private key encryption and recovery. WalletConnect is used for connecting the wallet with dApps.

The problem ZKMAV solves

In an age where AI-generated images continue to become more commonplace, yet less distinguishable, beginning to compete even with legitimate photos, a sensitive line between fiction and reality is easily tugged by those willing to sit by the loom and weave tales. While time has not proven kind to eccentric storytellers, as irony may have it, technological advancement has us returning once more by the fireplace, to gaze into embers and wonder what happens to things that are lost…

ZKMAV provides a platform to help authenticate true photos, guaranteeing their binding to an immutable timestamp and relevant information to boost the legitimacy of a photo without giving away personal information of the one behind the camera. Using Zupass, we are able to use ZKPs to ensure whistleblowers or sensitive individuals can share footage that truly has been taken at a particular location. Pushing it onto Ethereum ensures that such a photo cannot be reposted at a later time without having to be confronted with the original upload; the oldest recorded timestamp for the image. ZKMAV makes all of this, and more, easy.

ZKMAV, or Zero-Knowledge Media Authenticity Verification, allows a user to log in with their wallet and upload a video to the platform. On signing in with Zupass and providing proofs related to (yet not revealing) of their identity, they share a GPS location and verify the data through a backend, which also tags the video with coordinates and the PCD proof. The signed video is then stored on IPFS, which is finally pushed on-chain via a smart contract. Finally, if a user would like to verify a video, all they have to do is upload it, hit “Verify Video,” and the app will identify and list any challenges or supports to its authenticity.

Challenges you ran into

We were originally looking to use ZKLocus to add a stronger proof-of-location, but found difficulty running simple examples and found software conflicts. In the future, we want to implement a ZK proof-of-location to bind photos to both space and time.

Technology used

• Rust
• JavaScript
• Solidity
• Scaffold-ETH
• Zupass

The problem [Bet & Bed] solves

Berlin (and Germany in general) have a massive problem of racism in housing. 1/3 of experiences seems to end in racist experiences for immigrants looking for a house in the country.

That’s the reason behind Bet & Bed, a solution that allows for blind auctions curated by on-chain activity to determine a better match with the house owner / host. Bet&Bed allows for a fairer distribution leveraging anonymity and allowing users to be judged by their actual persona, not the colour of their skin. With Bet & Bed we ensure collaboration using a more neutral system that can be helpful for this pain, or many others such as curated entrances to events, job descriptions, etc.

Blind auctions are completely anonymous and the actual price of the spot is determined by the community bidding for it. The only one who is available to see the bids is the host and has to make a decision based on time, or he can close the bet as soon as he sees an offer that makes sense to him/her.

Challenges you ran into

Loading the fhevm wasm module and initializing it. Build custom provider that somehow uses the wasm module for encryption before creating the “payload” if i understand it correct ZAMA network does not show the wallet balance from metamask. -> Creating a personalized hook to display it. Building an AGS app that run by defaul in serversite, but we wanted to run it on server client . -> Create a provider [wrapping Wagmi] to isolate it ZAMA encrypts info before storing it, and generate the WASM was challenging.
Learning how to use FHE library within the contract to do confidential compute. Combining decentralized identities [for gatekeeping, transfering NFTs and confidential blinded auctions] was a challenge.

Technology used

Frontend: AGS React typescript webapp, shadcn ui components Backend: Firebase realtime database to track the auction NFT and address. One improvement would be making a graph or storing it in IPFS Smart contracts deployed in ZAMA network, FHEVM for encrypting, WAGMi, wallet connect… all in solidity Encrypted ERC20 [Ownable 2step], ERC721 [OpenZeppelin].

The problem Coinguard solves

Coinguard is an Ethereum self custody wallet with a integrated incognito mode. When enabeling the feature you are able to make transactions that cannot be traced back to your wallet. Specifically, we adress the issue of transactions leaking the senders wallet adress. So the recipient(someone who knows your identity) will be able to see your entire on-chain activity and net worth by simply copy pasting your adress into a blockchain explorer. Our current Architecture will also enable the use of dApps. With the help of incognito mode we try to eliminate a major risk to exposure of on-chain identity.

Challenges you ran into

The main challenge was to keep the public key of the users wallet as hidden as possible. One of the bigger challenges was running the Tornado Cash smart contracts on Sepolia testnet since the only testnet they were deployed on was Goerli which is discontinued. This forced us to rewrite the contracts and deploy them ourselves. Also, interacting with the contracts through the frontend proved to be quite a big challenge. Additionaly, catching and storing the Notes we got out of the contracts that allow us to retreive the tokens from the pool was quite difficult.

Technology used

With privacy at the center of our focus, we used the Tornado Cash contracts to enable us to maximize privacy with unique security features for the transaction structure and deployed them on the Sepolia Testnet. For the frontend(browser extension) we used Javascript React and for the backend Javascript Express.

The problem Shadowlings solves

We want privacy! We want recoverability! And Shadowlings gives that to us and pushes the freedom to transact to a new level.

Shadowlings generates unique and disposable deposit addresses that appear to be clean EOAs but are supercharged using EIP-3074 and ERC-4337. Additionally these deposit addresses can be connected to your existing account without doxing yourself using the power of Zero Knowledge. With that you can utilize recoverability mechanisms of an existing smart account and don’t have to worry about losing access to your shadow accounts.

With this we empower users to freely and privately transact without needing to manage multiple private keys, or being bothered by the wary eyes of other participants.

Technical Highlights

• Three Zero Knowledge Proof Circuits
• Possible to use the contracts with a CLI or a web app
• Local (and dockerized) EIP-3074 and ERC-4337 setup (including bundlers)
• Gaslessly operate shadow accounts
• Nick’s method paired with EIP-3074 for managing shadow accounts without any private keys

Challenges you ran into

• Balancing privacy and recoverability
• Getting started with Zero Knowledge Proofs (e.g. Zokrates, which hashing functions to use)
• Working with EIPs that are not on a official testnet (unofficial testnet went down, required full local setup of a testnet and 4337 stack)

Technology used

• EIP-3074 + Nick’s method
• ERC-4337
• Zero Knowledge Proofs via Zokrates

The problem Voto solves

Voto is an on-chain censorship-resistant anonymous voting solution built on decentralised identities.

Voting has always relied on two pillars: trust and identity. These two pillars have been broken by misuse and subversion of power, as represented by historically low election participation, not only in emerging countries, as well as in traditional democracies. Lack of trust - electorates have been continuously expressing a vote of no confidence in their elected governors who have been manipulating the electorate system to continuously stay in a carousel of power. Outdated ideas of identity - the idea of identity has evolved since the time when a government-issued passport was the one and only identity.

Voto allows communities to easily set-up a poll and participate in a voting process which could not be subverted or manipulated. We use a censorship-resistant, anonymous, bribery-resistant voting protocol - MACI - based on community-issued identities. We believe that the idea of identity currently is in a process of constant evolution, and we can’t pigeon-hole participants into using a fixed type of identity, so we rely on a community-based identity - Zupass.

Challenges you ran into

We ran in several issues while building our project:

The idea of identity - voting is based and shaped by the identity of the voter, so we took a lot of care in choosing the right ID solution. We iterated through several versions of identity solutions (i.e. Fractal ID, Civic Pass etc.) until we understood that no-one version of identity should be imposed by us as the creators of the project. Instead of governments being the sole purveyors of identities - we can have many identities which show our uniqueness as a human being. Communities (such as a school, church, community of builders), events (hackathons, concerts), protests and movements should also have right to issue identities - and we as a community should find appropriate ways to use each of these multiple identities as we see fit - this is the reason we ended up choosing Zupass as our solution for identity.

Technical difficulty of underlying technologies and their implementations - integrating the MACI protocol, as well as solutions which expand on it’s functionality (maci-wrapper by yashgo0018) was quite challenging, and our team spent a big part of our time on making the base solutions work, as well as troubleshooting, bug-fixing, expanding the functionality and documenting the maci-wrapper. We believe that we have significantly increased the deployability and usability of MACI through this work.

Limitations of Account Abstraction (ERC-4337): With our intention to make the registration as easy as possible we started experimenting with tools such as Biconomy or Candide. We very quickly encountered various limitations such as the requirement for additional tools such as magic.link etc. to allow social login and pairing with a newly created wallet. In this case however the user has to make a trust assumption and depend on a third-party for the access to their wallet. This was not acceptable to us. Candide had an interesting approach to utilise Passkeys to create a Key Pair used to create and interact with a Smart Wallet. This was implemented until we encountered issues utilising the smart wallet to prepare and execute complex transactions (our initial tests can be found within ./packages/nextjs/registration.

Technology used

Tech-stack:

• Zupass: For zkp-based identification
• MACI: voting infrastructure to ensure minimal anti-collusion with zk-proof to ensure correctness of result.
• Next.js + typescript: User-friendly front-end
• Hardhat + solidity: Smart contract development and deployment.
• Next.js backend:

Voter Registration: We use Zupass to verify the identity of any user. The participation at any event or association in any group can be chosen by the coordinator (who will also be the deployer of the vote contracts) as the requirement to participate in MACI polls. This is enforced by the ZupassGatekeeper.sol contract.

Voting Process: Initiating a new vote

Vote counting:

• Using the MACI cli to merge signups, messages, and tally votes.
• The final tally file can be posted in the app for the voters to see.
• The vote tally can also be published on-chain in a future implementation.

Resources:

• Live demo(video): https://www.loom.com/share/9b3436e0849248628a0bc8ded81d7b79?sid=36e7502b-304e-446d-aa24-781f7dad4e44
• Github: https://github.com/Vote-tech/voto-tech
• Pitchdeck: https://docs.google.com/presentation/d/1csfqWo_Ij8DnxH3DMhbLpyrp0gDWBUTC6VLZXVyUyy4/edit?usp=sharing
• Deployment URL: https://voto-tech.vercel.app/

Deployed instance: open-explorer (please note a cors enabler browser extension is needed for ens searching)

Open Explorer

A light, self-sovereign first, open source block explorer

Light

The tool runs entirely in the front end.

Fast

The ui leverages next generation data lakes for performant queries, such as hypersync, firehose and eth-archive that would make feature rich queries otherwise impossible purely using rpc without a dedicated backend.

Open Source

Transparent, verifiable and extensible.

Self sovereign first

We designed the explorer to give the user control of the data source. While maintaining the ease of not needing to run an entire node if that is a barrier to the user, the explorer allows you to switch between sources and provide your own rpc endpoints obfuscating requests and giving the end user control.

Testing disclaimer

• You will need to use a cors enabler browser extension to use the contract viewer and ens functionality
• Firehose & EthArchive were not implemented

The problem Open Explorer solves

Many block explorers are closed-source, with unknown, difficult-to-audit data sources. They are hard to extend, customize, and integrate with new chains. Etherscan’s high costs make it inaccessible for smaller blockchains (it is even too expensive for Big chains like Avalanche).

Our mission is to create open tools that provide fast, seamless access to Ethereum and related blockchain data. We empower users with flexible, self-sovereign solutions, improving on-chain activity understanding and eliminating gatekeeping barriers, all at an affordable cost. Etherscan is built on closed technologies and databases, contracts that are verified on etherscan aren’t shared anywhere else, whereas open tools like sourcify share their data openly.

Let’s end the monopolistic reign of Etherscan for a more open future.

Challenges you ran into

• The routing was desiged for localhost, and so sharing links with the eth.limo subdomain doesn’t always work. We need to move to hash-routing.
• A bit more time could have helped. :)
• We had cors limitations on ens name lookup, needed a browser plugin to bypass this.
• “Backwards” queries were challenging - the APIs are designed for forward queries.
• Ability to download data.

Next steps

• Auto decoding of logs if possible from source code.
• Implement more data-sources.
• Finish integration with chaindensity.xyz to get more information about address and their history.
• A screen that allows executing functions on the verified contracts.

Technology used

The frontend is written Rescript with rescript-react, and is built as a simple SPA that can be used as a file (no server) and is suitable for hosting on decentralized storage.

Under the hood we are using Sourcify, Viem, ENS, RPC and Hypersync (more data-providers to come) to create the experience. We use tailwind for styling.

The problem 🔒 Desentralized TLS verification 🔒 solves

(These headlines are from 10+ years ago)

Challenges you ran into

• Rust libraries don’t make it easy to do custom validation of TLS certificates, unless you go to relatively low level integrations
• Adding HTTP -> HTTPS support to a SOCKS proxy to avoid showing certificate warnings to users
• Users still see an invalid certificate warning
• Cross platform way to notify users so they don’t have to check the logs

Technology used

• Forked off from https://github.com/dizda/fast-socks5 and added ENS integration + some custom certificate validation.
• Redis

The problem Secret Talk solves

Video and voice calls can be monitored by anyone unless you use apps such as Telegram or Signal that uses encryption. But what if you are forced to use tools such as Google Meet due to governmental restrictions on these privacy preserving apps?

Meet “Secret talk” Ethereum powered voice encryption that allows you to join calls on Google Meet, Discrod, Teams and so on and still be in charge of who can actually hear you, and who hears a bunch of static noises :D

We achieve this via our custom virtual microphone driver where we encrypt your voice with another persons one time use ethereum key exchanged via a handshake that allows the recipient to hear decrypted sound while others, who do not have access are stuck with static sound.

Challenges you ran into

The whole voice encryption only for 1 other person with a key was a challenge to solve especially when dealing with Google Meet as they also format and compress the audio, making the decryption process much more difficult that it otherwise would be.

Technology used

Frontend is built on NEXT.js and the backend is mainly built on Rust with some open source drivers built on top of C.

The problem Proof-of-Usage solves

For current governance structures in Web3, how much voting power to grant to someone is really important! We don’t want whales buying into the governance proposals. Several factors determine how much should someone be granted voting power be it via fungible tokens or Soulbound tokens (SBTs). Some factors are:

1. Protocol contributions
   • Code
   • Social identity build up / Communication
   • Co-ordination
   • Writing (papers, blogs, etc.)
2. Network
   • Running Nodes
   • Maintenance
3. Usage

This project measures usage. At the end of the day, a protocol’s adoption is dependent on its users, and they should have a say in where the protocol should be going. The more a protocol is used by someone, they should get relatively equivalent voting power in governance proposals.

There are 2 options for this:

• On protocol layer for governance of L1/L2s itself
• On application later for governance of protocols built on top of base chains e.g. Uniswap, ENS, etc.

Challenges you ran into

The biggest one: trying to modify a big chunk of Geth over a weekend! Tried to implement protocol level mechanism, but it didn’t work. Wrote specification for that instead. What did work was implementing the second option of doing it on application layer.

Also didn’t realize limitations of publicly available JSON-RPC endpoints for fetching the data. But made it work with limited set.

Technology used

• Geth
• Foundry
• Open Zeppelin
• Nodejs
• Merkle Proofs

The problem RageAgainst.eu solves

We have become complacent. Upcoming changes in the regulatory environment are increasingly moving towards requiring KYC on centralised components, including hosted frontends. With rageagainst.eu, we give everyday DeFi users the power to host their own frontends locally, enabling everyone to use protocols the way they were meant to be used - without permission from The Union, and without the need to rely on other entities to host.

Challenges you ran into

• Nixpacks is supposed to detect how to build and run most repos, but pretty much every UI repo requires some tweaking to get working.
• Docker builds can be very slow on laptops.
• Some dapp UIs, unfortunately, require centralised components such as WalletConnect project IDs.
• It’s very difficult to build many dApp UIs. Inconsistent lockfiles, missing lockfiles, many other issues. After spending countless hours trying to configure builds for many dApps, we only got Uniswap, Tornado, and Aave interfaces working smoothly.
• Electron, bundling, and node native modules (via napi-rs) do not play well together. Originally, we had nixpacks implemented as a node native module (very cool), but it refused to be packaged. So we had to rip it out, and for now, nixpacks must be installed as a separate dependency in order to use our app.

Technology used

• Nixpacks
• Docker
• Electron

Fixing corrupt policy with more corruption 🤝

The problem InclusionBribes solves

Some Ethereum contracts are being censored. Not only by MEV re-layers but also by the block builders. This means validators that use uncensored relayers can end up proposing censored blocks, because of builders who censor. We need to make uncensored blocks more lucrative.

InclusionBribes seeks to tip the scale for non censoring block builders to build more profitable blocks. InclusionBribes allows dapp developers to add a back-running MEV opportunity to any call on their contract. Developer can specify which functions of their contract will get bribes, which token it will be payed out in and how much per tokens will be payed out per call.

Challenges you ran into

Working out our idea. We first thought we would need to create a patricia tree proof of the transaction tree in order to pay rewards. Luckily one of the mentors (Josh) helped us figure out how to do it solely on the contract layer.
Making it generalizable. We mainly made it for tornadocash but we managed to make to more generalizable by specifying the function selector and calldata instead of hardcoding a interface.
Intergrating tornadocash. We weren’t able adapt the tornadocash ui to our contract but we did make a simplified dummy contract (named “Twister monies”) and ui to demo similar functionallity.

Technology used

Foundry, Wagmi/React, Ethereum, Solidity and JS/TS.

The problem Schufher solves

Whether you want to sign a mobile phone contract, switch your energy provider, or take out a loan, your personal credit score is crucial. In Germany, this service is monopolized by Schufa. Schufa collects extensive personal data to compute credit scores, often exploiting those in need. Moreover, there have been multiple data breaches involving Schufa’s data. Additionally, an investigation by SZ revealed that Schufa collaborates with energy providers to prevent customers from regularly switching providers. Our conclusion: The current Schufa-based credit rating system is fundamentally broken. We solve this problem by providing the alternative solution schufher which computes the credit score on encrypted data using FHE.

Challenges you ran into

We are building on the Zama library concrete-ml, which took us a long time to set up due to unstable compatibility with Apple Silicon.

Technology used

concrete-ml FHE Vue.js Docker Flask Python

The problem zu-git-proofs solves

Zu-Git-Proofs enables anonymous feedback in forums by assigning credibility badges based on GitHub contributions (e.g., Core Ethereum Contributor). Zu-Pass-Proofs ensures that participants can stay anon while being recognized and trusted with proven expertise. This approach fosters high-quality and reliable community discussions and governance while first maintaining user privacy, using Zupass.

Challenges you run into

We learned this weekend that Discourse was written in Ruby. We learned Ruby too :) On web3 side, Zupass was definitely a rollercoaster with integration. During certain times it looked easy but turns out that a lot of the current codebase can’t be used for this case (previously supported was event with tickets) and requires much more effort for support. Discourse deployment wasn’t an easy one and was the only part left that had to be left locally.

Technology used

• Nodejs
• Typescript
• Bun
• Ruby
• React
• Docker
• ZuPass

The problem ZkUbiToken solves

Life Demo: https://zk-ubi.vercel.app/

We propose a new crypto currency narrative that could work as a future global financial system. ZkUBI addresses wealth inequality by redistributing a universal basic income (UBI) to ensure fair wealth distribution, leveraging zero-knowledge proofs for sybil-resistant identity verification without the need for a trust network. The UBI is paid for by taxing wealth from every account. The UBI is distributed to sentiment users, so the max supply is fixed. Users will be able to login with zkPassport, but for this demo we use Zupass.

Key Features

• Sybil-Resistant Identity Verification: We use zupass for anonymous identity verification to ensure sybil resistance. In the future, we plan to integrate zkpassport for enhanced security.
• Simplified Calculations: Unlike other UBI systems, such as Circles UBI, zkUBI simplifies the redistribution process.
• No Trust Network Needed: By leveraging zero-knowledge proofs for identity verification, we eliminate the need for a complex trust network.
• Read time calculations: Unlike other UBI systems, which require claiming the the basic income periodically, users can watch their balance grow automatically
• Robinhood Tokenomics: The rich lose hoarded money in real time while the poor get richer. This encourages the rich to spend and bolster the economy while protecting the poor from poverty

Challenges you ran into

• The initial math we attempted was too complicated and had problems being implemented in solidity.
• Zupass was complex to integrate
• A sybil resistant identity solution does not yet exists at scale
• The token we launch does not yet have a value. It rather serves as a narrative we want to create.

Technology used

• ZkPass
• Foundry
• ScaffoldEth / ZkPass repo / wagmi, viem

The problem pywdr solves

zk-VMs are among the most complex zero-knowledge circuits in deployment. powdr is a tool that greatly simplifies implementing zk-VMs by providing a powerful DSL. Our project, pywdr, achieves the same, but utilizing the Python programming language.

pywdr amplifies the benefits of powdr: There is no need to learn a new programming language for both the programmer and the auditor. Furthermore, pywdr itself is implemented in a fraction of the lines of code compared to powdr, making it easier to maintain, extend, and audit.

Challenges you ran into

The complexities of writing parsers (for the assembly program), subtle bugs in the zk-constraints (causing witness generation to fail), and incorrect suggestions by ChatGPT.

Technology used

• powdr: We use powdr to process a small subset of its low-level PIL language. This gives us witness generation and proof generation 🎉
• powdr-py: An earlier hackathon project by one team member, implementing the basic mechanisms to generate constraints and connect to the powdr stack.

The problem InsideOut solves

InsideOut is a toy model of rollup (yes, this is a rollup, not validium), demonstrating, how a rollup could be maintained on the blockchain without publishing the data anywhere outside the rollup.

We use techniques inspired by the file blockchain solutions (like Filecoin, Arweave, Ethstorage, etc), but wrap all processes into a zk rollup.

Challenges you ran into

We use techniques inspired by the file blockchain solutions (like Filecoin, Arweave, Ethstorage, etc), but wrap all processes into a zk rollup. In this way, we reach the following property:

1. The rollup can store its own blocks and additional data inside itself, like a baron Munchausen, who pulls himself out of the swamp by his own hair!

2. Potentially this technique can be used to build a multi-layered infrastructure of recursive rollups and transform Web2 into Web3.

Technology used

zkSnarks, Noir

Limitations

This is a toy model built for the ETHBerlin hackathon. It is not production-ready and has a lot of limitations, security issues, and bugs. You will not find any optimizations, high performance, security, or any other features, that are necessary for a production-ready system. It should be used for educational purposes only.

The problem the Open Contract Directory solves

When a dapp gets popular, people come to rely on it. But who controls that dapp? What are their incentives? Can they hike up fees? Can they implement geoblocking or censor addresses? Are they vulnerable to hacks or rugpulls (secure website hosting, upgradable contracts)? Can they track or sell user data?

The Open Contract Directory (OCD) is a public goods repository of free, libre, ownerless, uncensorable dapps—smart contracts and frontends you can trust. Public good means: no tokens, no upgradability, no hidden fees, no external interests!

Challenges you ran into

Defining appropriate requirements for listing an item in the OCD requires careful consideration. Instead of finalizing these properties ourselves, we’re keeping it in draft form and leaving the topic open for community discussion.

Technology used

• Ethereum
• Foundry
• Svelte
• Tailwind
• Viem
• Google Slides
• Stable Diffusion
• ChatGPT

The name?

The Team named itself “Howl’s Moving Contract”, because as the moving Castle in the Studio Ghibli film, our contract stays in motion, making it harder to be tracked.

Also, Kabuso (the Doge Dog) died. He was a good dog and we are sad that he died.

The problem Kabuso solves

With the persecution and eventual sentencing of Alexey Pertsev for his involvement with Tornado-Cash, the codebase basically became radioactive. It’s initial vision for preserving privacy and anonymity in an inherently public ecosystem still stands though, even though recent events pose a dangerous precedent. So in the spirit of EthBerlin, and especially this years topic, we snuggled up to the radioactivity and made it worse :)

1. We took the Tornado-Core repo and updated the contracts (from 0.7.0 to 0.8.26).
2. Then we put them into Foundry, because using Truffle + Ganache for testing purposes just won’t cut it in 2024.
3. After doing the initial groundwork, we were able to run an up-to-date version of Tornado Cash locally.
4. So then we modified the contracts.

The idea is that the contract is able to re-deploy every 5000 blocks (~ every two weeks), so that it becomes available under a new address. This should make it harder for authorities to block or penalize interaction with the new contract address for the userbase.

In order to achieve this, we had to make the following changes:

• implement a counter that checks if 5000 blocks have passed
• implement storage for redeploymentGasFees
• after the passing of 5000 blocks + the accumulation of enough redeploymentGasFees, the redeploy-function becomes executable.
• when a user executes this function, a new contract will be created from a factory method
• the funds from the old pools, as well as the list of previous commitments are send to the new contract ( => old deposits promises are still withdrawable in the new deployment)
• deposit and withdraw function in the old contract get disabled ( => no funds can get locked in)
• the initiating user gets rewarded with the remainder of the redeploymentGasFees as an incentive for users to trigger this function when it becomes available

The functionality of the contract is essentially moving forward continuously, offering users at least some hint of privacy before the new address can be blacklisted by protocols.

Challenges we ran into

• the zK stuff, especially:
• installing huffc compiler (every team member now hates the huff language with a passion)
• containing our exponentially growing fondness of foundry. It is amazing.
• since we build all hackathon, we didn’t have enough time to listen to the good techno music outsite.

Technology used

• Tornado-Core repository
• Solidity
• zk-Stuff (circom)
• Javascript
• Foundry

Near<>ETH Tunnel

This project is the first end-to-end functional front-end implementation of a Near wallet that can interact with any EVM dApp using Chain Signature (via Wallet Connect). Having this tunnel allows Near Wallets to seamlessly connect to and interact with any EVM dApp and sign transaction payloads from their Near Wallet (supports eth_sign, personal_sign, eth_signTypedData_v* and eth_sendTransaction). This is compatible with a Generic Near Wallet Selector (tested with Mintbase Wallet & MyNearWallet).

Challenges you ran into

There were several hurdles with near wallets (as they are browser wallets) and page state is lost after redirect to sign and send the near transaction payload. The unsigned transaction data and wallet connect session was a slight challenge to persist between page redirects (solved using local storage to re-instantiate lost state) and recover the signature for the near-signed EVM transaction.

As a back-end developer, most challenges were merely a lack of technical ability in next JS and recruiting assistance.

Technology used

• Front End: next-js (scaffolding from a Mintbase Template – initial commit)
• Backend Tech: Uses Near Chain Signatures via the near-ca library. The library handles transaction payload transformations and relay routers.

Anti-Correlation Attestation Penalties

The decentralization of the validator set is one of the most important properties of Ethereum for credible neutrality and censorship resistance. By adjusting penalties to foster decentralization, diversification and fault-tolerance, this EIP proposes to adjust penalties in a way that more diversified entities get lower penalties while entities with high correlations in their setup face more servere ones.

Challenges you ran into

Understanding Vitalik’s initial proposal and set appropriate constants.

Technology used

Go, Python (Consensus-specs, Data Analysis), Rust

The problem Governance Gladiators solves

When interacting with DAOs it is difficult to estimate the chances of success of a proposal passing. Using a comprehensive Dataset, Governance Gladiators computes the network of Delegates and big voters on how they have voted in the past. This allows us to detect similarities and clusters of voters aligning in voting strategy. Based on the input of who you know will be for or against your proposal, Governance Gladiators allows you to determine your chance of success and to pick who you should talk to to increase your chances.

Challenges you ran into

UI/UX design - making an engaging and clean UI to input your data and receive feedback Time management of data analysis vs resulting UI

Technology used

AI NextJS Tailwind Blockchain Data Analytics Postgres cockroachDB Near Wallet Connect

The problem Acropolis solves

Acropolis enables Authorized Anonymous Voting through Signatures over Public Keys. The cryptographic identity of each User is treated as a Secret Input and never revealed to the public. Only the Signature issued by the Authorities for a “KYC-ed” user, alongside with the corresponding Public Key (one Public Key per election that is owned by the authority) are published for each election. An election is defined as a cycle with a fixed set of options to choose from and government issued identities.

Challenges you ran into

Developing an audit tool for independent entities to verify ZKP traces stored on Ethereum. Maintaining authorized identities in a secure manner, utilizing one-way functions and Risc0. Optimizing Proof size and proving speed.

Technology used

Risc0 with a Groth16 wrapper and k256 guest optimization.

The problem GivETH TakETH solves

To solve the “multi-dimensional identity crisis” (ETHBerlin04 Manifesto), tech won’t save us. Instead, we need more experimentation. We have all the tools for interesting socio-economic experiments to learn how people interact in social and economic situations. Practical behavioural finance, but dead simple. GiveETH TakETH is a tiny “Hello World” example that asks what happens when we allow everyone to put ETH into a contract and also to take out ETH from that contract, without restrictions…

(Do we already know) what will happen?

Challenges you ran into

Multiple bugs / frustrating documentation issues in the tech stack I use, it’s also my first project on ETH, big learning experience.

Technology used

GiveETH TakETH consists of a (currently) mobile dApp and a smart contract. Flutter / Dart, Infura, remix, Sepolia testnet, Etherscan API, Android phone

The problem Private Peers solves

Centralised connections between people are a honey-pot of private information, that is often exploited. Nothing is private when it goes via a central entity, they are the gatekeeper.

Private Peers is our own subjective sub-graph of connections, and attributes. An infrastructure that can be built upon for private signalling, p2p lending, and inviting friends of friends… etc

Challenges you ran into

Ensuring minimum access to private state in a decentralised and permissionless way.

Technology used

• Aztec’s Local sandbox simulating privacy preserving layer 2 (smart contracts/accounts)
• React, Aztec.js
• PS. NO CENTRALIZED SERVER

Problem Toucan AI Solves

Security vulnaribilities in Smart Contract contributted to a staggering loss of over $1.1B. With approximately 100 security auditing firms in the space and over 500 active protocols on Ethereum alone with over 100k TVL auditing for security vulnerabilities becomes increasingly important in both speed and reliability. Toucan AI streamlines the initial security vulnerability scanning for new and existing contracts by leveraging AI to produce scripts that exploit the vulnerable code and creates a detailed report outlining the issues and provide mitigation strategies.

Challenges Faced

• Some contract vulnerabilities are revealed only in contract to contract calls. This is challenging to fully automate as the AI needs to write and deploy the attacker contract while also being able to write a script to initiate the exploit
• 1 shot learning is hard in security vulnerability testing thus continuous iterating until an exploit is found makes the result production slower
• Creating a perfect, majestic toucan is always hard

Technologies Utilized

• Development:
  • Hardhat
  • Typescript
• AI Model:
  • Open AI GPT-4o
• Smart Contract:
  • Solidity

Links

• Demo: https://www.youtube.com/watch?v=lyfHjudRXo4
• Github: https://github.com/TheHackingToucans/toucan-ai

Authors

Julia, Stefano, Tom, Vlad, Sandoche

License

Apache 2.0

Safe Bounty Fund

Streamline Bounty Payouts Using ZK Magic

💸 Safe Bounty Fund is a secure way of paying hackers after a hackathon. Before the event, sponsors and organizers can use our dApp to add bounties. They do this by depositing funds in the smart contract and linking it to a Zupass badge idea for this bounty track. After the hackathon, the holders of Zupass winner badges are allowed to claim the corresponding bounties.

The problem SBF solves

😎 SBF removes all the hassle from hackathon prize management for both sponsors and hackers using the magic of zero-knowledge proofs. Sponsors can effortlessly post bounties and deposit prize money, while hackers can instantly and securely claim their winnings. Say goodbye to chasing sponsors on Discord for months—our solution ensures an efficient, seamless experience for everyone involved.

Challenges you ran into

🧑‍💻 We found working with the cool tech at Zupass fun, new and exciting. Our team closely collaborated to understand the zk proofs and how to apply them. We want to give a special thank you to Richard and the Zupass team for helping us with explanation, guidance on code examples and helping us set up a test dev environment with your tech, you guys are amazing.

Technology used

⚙️ Built using Zupass, Scaffold-ETH 2, Solidity, NextJS, Foundry, Wagmi, Viem, and Typescript.

Hackathon tracks

Meta Award

🖥️ We developed this open-source solution for hackathon bounty distribution based on our experiences as seasoned hackathon participants. This tool could have saved us significant time, money, and frustration in the past, which is why we were driven to create it.

Best User Experience

💅 Removing the hassle includes making the user experience smooth. We aimed to enhance the hackathon experience in all aspects, which is why we put effort into creating a sleek and easy-to-use UX for both sponsors and hackers.

Next steps

Due to the limited time, we could not complete everything we set out to do. Additional features that we plan to add include:

• Cross-chain fund distribution
• Distrbute funds between team members (partial claims)
• Keeping the funds and the smartcontract logic secured as a gnosis safe module

Links

• Vercel deployment
• Presentation slides
• Demo video
• Github Smart contracts repo
• Github front-end repo

Verified smart contracts

• SafeBountyFund contract on Sepolia

Team

This project was build during ETHBERLIN04 by:

• 0xjsi.eth
• aliX40
• arjanjohan
• Sebastian

The problem zkAd solves

The huge value of targeted advertisement currently leads to ad providers storing and selling all personal & private data. We wanted to solve this problem without compromising on the level of personalized ad quality, and while preserving privacy using zkProofs of LLM-generated ad recommendations.

Challenges you ran into

While we were able to make the prototype work to locally generate the ad recommendation based on the browser history and personal data, we didn’t find any feasible way to compute a zkProof for the LLM inference. We are looking forward to the technology improving further, so that this will easily be possible on local devices.

Technology used

Experimentation with Circom, Llama 3 for ad recommendation, React & FastAPI for the prototype.

Note: Unfortunately our train tomorrow leaves already at 9:30, so we cannot present live. Instead, we’ve recorded the presentation beforehand, and you can find it in the Pitchdeck URL. Thanks for the opportunity 🙏 🚀

The problem Zumeet solves

Find it hard to socialize at hackathons?

Too shy to break the ice?

Just use Zumeet – the perfect conversation starter with a gamified twist to help you meet new people and collect lasting memories!

Get started now: https://zumeet.pages.dev/

Videos

The Zumeet Approach

Zumeet allows event participant to create a personalized digitalized artifact. Those artifacts can be exchanged between participants by meeting in person and sharing their Zupass public identity with each other. Collected artifacts are stored in the Zupass application under an event specific folder.

Event organizers can access the social graph to gather insights. This can be used to identify social clusters, well connected people in the social peer group, as well as deriving inforamtion about the social strucutre of the group of event attendees. This allows to direct decision on social acitvations to facility better networking.

watch ETHBerlin04 social graph evolve here: Social Graph

Given the zk proofing ability on Zupass over the stored PODs one could build digital experiences on top of that, like a website, only accessible by participants I have connected with.

Challenges you ran into

There was no prior Zupass experience in the team, so it took a bit of time to adjust our mental model to make it work well with the project.

Our inital approach intented to work soley P2P, but due to limitations with the current Zupass implementation we impelemented a feed server to facicility distributation of PCDs and claim management.

There were some hiccups integrating with Zupass, as well as blindspots on our side how to approach certain things like creating PCDs from a feed server. Thanks to the fantastic support of the Zupass team / mentors those problems were turned into learnings, instead of blockers.

Technology used

Frontend / Client

• Next / React
• Zupass api to create PODs and store them as PCD in the Zupass app
• Zupass auth flow to verify event attendance

Backend / Feed-Server

• Express server on Vercel
• Generic Key / Value store to persist data between sessions
• D3 to generate a vizualisation of the events social graph

The problem Count Xeno the 4th solves

For BLS signatures, the EVM currently only has a precompile for BN-254 integrated. However, many other curves are of interest, including for security and performance reasons. This project solves verifying an aggregate BLS signature on Ethereum, where Ethereum doesn’t natively support the curves used via a precompile, such as BLS12 381 and 377. The signature scheme is accountable, and the applications are lit: having an accountable signature scheme permits use cases such as transparent DAOs (with efficient signature aggregation) and trustless bridges (since adversaries can be slashed).

Challenges you ran into

Writing tests in Rust for Solidity contract turned out to be a challenge. Some people are struggling with this as well: https://blog.polytope.technology/testing-solidity-contracts-with-rust. We found a way to make it nicer using ethers-rs (alloy turned out to be another challenge to work with) and some post-processing of solc output and anvil.

Arkworks doesn’t support proving pairings and adding that support is tricky.

Technology used

• Rust
• Solidity
• Arkworks
• Anvil

The problem hoarder-app solves is that rugged assets are not liquid and therefore can not be sold.

We are working on a smart contract that buys any NFT or ERC20 token for a very small amount of ETH. Only a realised profit (or loss in this case) is tax-deductible in many countries. So many of us experienced rugs pulls, scam coins, fake DEX pools where we ended up with tokens that are worthless and without any chances to sell them again. The problem gets even bigger if we are talking about NFTs due to the lack of DEX listings.

We build on top of an already existing project from https://nftlossharvestooor.com/ and extended it’s features from NFTs to also ERC20 as well as improved the codebase, the privacy and some potential legal problem. The potential legal bug the NFT Loss Harvestooor had was, that it is possible to buy back the assets for the same price that you sold it and this could be interpreted from the tax office as that the asset was not actually sold but just stored or even hidden away in a smart contract. All transactions on hoarder-app are final and assets can not be bought back. As the name suggest this smart contract is a real hoarder that hoards everything that it bought over time.

Challenges you ran into

The biggest challenges we had where to figure out all the nitty gritty details. Including how the funding of the contract works. We decided in the end not to implement any funding feature as this might lead to income for the smart contract and could have tax implications for us.

Besides the legal questions we where struggling with some technical challenges that the mentors where a great help to us.

Technology used

Solidity was the main technology used in this project besides some smaller other frameworks for the frontend. The domain “hoarder-app.net” is already purchased but we are waiting for the domain provider to assign it to us.

Track

We decided to submit this project to “Freedom to transact” because it involves usually transacting with assets that nobody else is accepting. We are giving you back the freedom to sell your tokens if you want to or have to.

Excellence Award Track: Social Impact As this track is supposed to have submissions that help society as a whole. We belive that tax equality is a basic right. In countries where crypto gains are taxed also crypto losses should be appropriately be able to be deducted.

Links

Landing page: https://hoarder-website.vercel.app/ App: https://hoarder-website.vercel.app/hoard FAQ: https://hoarder-website.vercel.app/FAQ Contract: https://sepolia.etherscan.io/address/0x887b16a1b66a94432c2c63ef7ece69eef272bdeb - you will find HRD tokens already in the smart contracts. This is a token we created to test the app.

Will be migrated to: hoarder-app.net Once we got the final feedback from the judges, we will update the project accordingly, open source the repo and deploy on mainnet. Price money won will go at least partially towards funding the smart contract

The problem Gov Subgraph solves

Gov is a DAO framework that’s using OpenZeppelin Governor contract in combination with membership NFTs.

It’s compatible with Tally interface, but it also has a custom UI that includes Web3Modal email login. This Next.js app needs to poll data from the blockchain to display all the submitted proposals and the problem is that it was inefficient. It used to take too much time to display all the proposals on the home page. So we implemented and integrated a subgraph to greatly improve the UX: all proposals are now displayed in less than a second.

Live web app: https://gov-ui.netlify.app

• Subgraph repo: https://github.com/w3hc/gov-subgraph
• Integration PR: https://github.com/w3hc/gov-ui/pull/77

Challenges you ran into

• We spent some time to get rid of the remaining bugs and glitches of the UI, and tested a lot to make sure the app works in every scenarios.
• We had to create our own subgraph schema specifically for Gov, then integrate it in the Next.js app and we were not super familiar with that.

Technology used

• Next.js
• Subgraph

Despite exciting developments, the true potential of reputation systems in web3 remains untapped due to insufficient on-chain activity data and contextual information. We present an example use case with the Powerhouse decentralized operations toolkit that shows how systematically capturing DAO data can elevate reputation systems to the next level.

Problem

Reputation systems in web3 today remain largely ineffective because they are based on a very limited set of behavioral data available on-chain. POAPs, financial transactions and NFT ownership lack the necessary context and depth to serve as a reliable basis for reputation building. The true potential of pseudonymous, reputation-based systems can only be unlocked by not just capturing all relevant activity in the network, but by making it readily available for reputation building.

Solution

Powerhouse is developing a decentralized operations toolkit that can capture any social signal based on the contribution behaviors of DAO participants. These social signals are contextualized by the specific identity behaviors and the peer/social context in which they occur.

By using distributed document models, our system converts all contributor activity into events that can be published on-chain. We then attach a user’s decentralized identifier (DID) to the captured behavior, linking it to their pseudonymous reputation.

New Possibilities Arise

With this behavior & social signaling system in place we can unlock new verifiable identity opportunities, such as:

• Retroactively reward a contributor, once a project gets traction, is released or goes viral based on their contribution activity.
• Implement social validation & approval systems of peers or DAO’s to recognise & verify your contributions once they are delivered
• Bridge your contributions and experience points from DAO 1 to DAO 2 and make them count across networks.
• Allow communities to decide on which social signals are most supportive to the community’s purpose and set up customisable reputation scores.

Demo Scenario

For our hackathon project we chose to demonstrate the following scenario in collaboration with Ubiquity DAO:

1. Sign up as an anonymous contributor & set up your contributor profile.
2. Browse through the roadmaps that DAO governance have approved and find deliverables to work on.
3. Complete the work in a familiar Github environment and get paid after an automated code review, without KYC/AML for small contributions.
4. See your contributions get recognised and picked up by the system
5. See your pseudonymous skill set, identity & reputation grow within a relevant context!

Challenges we ran into

Building & implementing the scope of work document model with its reducers. Setting up API listeners for the connection between Powerhouse & Ubiquity.

Technology used in chronological order

• Figma Prototyping for design concept of profile creation.
• Powerhouse Renown Login Flow making use of Decentralised Identifiers & Verifiable credentials + Ceramic Network for verifiable Data Storage
• Powerhouse Connect & document model editor to build the scope of work document model reducers (deliverables list)
• React component testing with storybook.
• Powerhouse Synchronisation protocol to synchronise the document model with the remote server node on switchboard
• Switchboard to establish a connection with github API
• Ubiquity DevPool flow to complete Github issue & payment of the contributor
• Figma Prototyping for the design concept of profile growth.

The problem ZKTools.dev solves

This is an easy to use web debugging tool for ZK developers and learners (like us!). We wanted to provide a simple UI (inspired by the great evm.code) for everyone to get important information about the process of working with ZK files.

The frontend also adds a lot of tooltips and explanations that are great for people who are getting started with the ZK technology.

Challenges you ran into

• Most JS libs related to ZK are not easy to run in the browser, for instance, circomjs or r1csfile. We lost a fair amount of time trying to setup the build for these libs. We ended up using the very great snarkjs lib but even the file import/read could be improved. We can send PR to these repos to improve the whole JS “flow”.
• snarkjs loads the file with fetch, therefore, we can not directly use the file uploaded by the user. As a workaround, we create presets. A long term solution would be to adjust the snarkjs lib to accept not only a string (path to a file to fetch) but also a node File object or Bytes buffer.
• The whole “zk” flow is quite hard to grasp, as the user needs to work with many files, generated at different stages (such as ceremonies, etc.). It was a great learning experience for us and also make us confident that this tool can help users, learnings, developers, to get around this complex flow.

Technology used

• Next.js - for the React framework.
• Vercel - for the easy deployment.
• snarkjs - for interacting with the zk related files.
• circom - to write and compile circuits.
• Monaco Editor - to edit JSON files.

Future improvements

• We can connect the debugger to the blockchain to fetch the verification directly.
• Adjust the file reading mode so we can easily read file from users device.
• Add more explanation and interactive UI.
• Make all files updatable. At the moment, we had to prepare a few files (“preset mode”) to simplify the process, ultimately, we want users to be able to load their own files.

✨

The problem El Bitcoin solves

The times have changed. Today, centralized exchanges exhibit the worst features of neo-banking and tend to de-platform users proactively. Meanwhile, many Web3 projects would benefit from onboarding users from various payment networks, primarily the Bitcoin Lightning Network. At El Bitcoin, we aim to bridge the gap between networks and leverage the expressiveness of Ethereum smart contracts for the benefit of connecting networks, allowing users to freely transact between them. This means Web3 users could benefit from non-custodial Lightning wallets, while merchants and users already utilizing non-custodial Lightning wallets could access decentralized exchanges and lending protocols residing in Ethereum and Web3.

Challenges you ran into

We have decided to stick to the collateralized wrapping Bitcoin Lightning scheme due to two issues:

• SPV (Simplified Payment Verification) validation is impossible to implement in one day.

• UTREEXO, a brand-new technology, makes it challenging to implement UTXO verification against a UTREEXO Merkle proof.

Additionally, the idea of integrating Lightning into Metamask Snap via Greenlight technology by Blockstream proved to be an expensive task, due to the absence of JavaScript/TypeScript Rust library bindings.

Technology used

• Ethers-rs
• Ethers & Webln
• Core Lightning client (ETH plugin)
• ERC20 token
• HTLC contract (Router)

Updates

Saturday’s

• WBTC mock (collateral token) https://sepolia.etherscan.io/address/0x52f74a8f9BdD29F77A5EFD7f6cb44DCF6906A4B6
• Lightning token EL Bitcoin https://sepolia.etherscan.io/address/0x0d6202a87b4e82623b07dc81cbb6b9c8add09b8d

Sunday’s

• 10:18 MVP for minting tokens deployed on https://el.satsbridge.com
• 10:35 MVP for Router for bridging LN <> EVM https://satsbridge.com
• 11:12 Minor fixes in Router frontend deployed, EL BTC plugged into the bridge

The problem Deadcaster solves

tl;dr: A decentralized & secure Dead Human Switch for our secret’s life insurance Experience it on Warpcast

Deadcaster addresses the critical need for secure, decentralized and incentivized information reveal when individuals become inactive or incapacitated. Imagine a journalist in a hostile environment ensuring their critical findings are revealed if they are silenced.

Architecture

Challenges you ran into

• Biggest implementation pain: Metamask browser experience on mobile.
• Warpcast does not support Oasis network, therefore users need to navigate to an external website to make TXs on Sapphire (Oasis). In the future, with Farcaster’s on-frame TXs, this experience can be integrated into a single farcaster client application.
• Relying solely on Sapphire poses a risk if TEE hardware experiences disruptions. Utilizing multiple privacy-preserving compute mechanisms, such as other TEE or FHE networks, can ensure the security of revealing secret, even if one solution fails. Additionally, incorporating hardware wallets as a deadhuman switch via ZK proofs can provide users with more options depending on the circumstances.
• Using Farcaster’s hubs to store encrypted deadcasts requires a hub rental contract and insurance to ensure the casts remain on the hubs as long as the user confirms their lively status.

Technology used

• frames.js - Farcaster frames Framework
• Oasis Sapphire - TEE EVM for Smart contracts handling secret keys
• IPFS - The logic of the client to interact with our dApp.
• Vercel
• Metamask wallet

Deployed here

• Frame cast: https://warpcast.com/dudeamir.eth/0xaf088d0a (Experience it on Warpcast)
• Onboarding/Reveal secret relayer: https://deadcaster-onboard.vercel.app | IPFS: QmZzvaHCB2TNVcYwzum6TMNcCTpcnVx5TpQyL3CxywrEzk
• Message Encrypter: https://deadcaster-encrypt.vercel.app/ | IPFS: QmWo4HeLRKzJ2ckTr4sAbe25FUxfkffF3vC2Gie9ifaqPv
• Reveal Messages: https://deadcaster-reveal.vercel.app/ | IPFS: QmXXU1Sa51K5UwfV34NBMxBE13Ze51fbnk9QEkjqcMEGND
• Farcaster Frame: https://deadcaster-frame.vercel.app/ | IPFS: QmNhDMtKj6BKTvg12sms6dE8aYQM4YLRWzfUZw3kgohQA4