Zharta

SporkDAOOfficial

Fuel Labs is building Fuel, the worlds fastest modular execution layer.

Fuel Labs

IPFS

Swarm is a decentralised storage and communication system for a self-sovereign digital society.

Ethersphere

A Rome-based community to gather local web3 builders and foster bottom-up innovation.

urbe.eth

ETHWarsaw

FOAM

DIAdata.org

Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.

Foundry

CPI, INC

### **Optimize 🏆**

The "Optimize" challenge is specifically tailored for projects that can find creative ways to optimize gas fees for transactions on the blockchain. 

This challenge seeks to address the pressing need for novel approaches, algorithms, or tools that can effectively reduce gas fees while maintaining transaction efficiency and security. Participants are encouraged to explore creative ways to optimize gas consumption, minimize unnecessary computation, and enhance the overall cost-effectiveness of blockchain operations.

*Acceptance Criteria*

To be eligible for the "Optimize" prize, your project should demonstrate a deep understanding of gas fees and propose practical methods to mitigate their impact. Participants are encouraged to explore various strategies and supports.

Successful projects in this category should consider factors such as scalability, compatibility with existing blockchain platforms, and user experience. It is essential to ensure that the proposed optimization techniques do not compromise the security or correctness of transactions and smart contracts.


Submissions earning other Nefture bounties are not eligible for the prize pool.

<h3 dir="auto">Optimize 🏆</h3>
The "Optimize" challenge is specifically tailored for projects that can find creative ways to optimize gas fees for transactions on the blockchain.
This challenge seeks to address the pressing need for novel approaches, algorithms, or tools that can effectively reduce gas fees while maintaining transaction efficiency and security. Participants are encouraged to explore creative ways to optimize gas consumption, minimize unnecessary computation, and enhance the overall cost-effectiveness of blockchain operations.
Acceptance Criteria
To be eligible for the "Optimize" prize, your project should demonstrate a deep understanding of gas fees and propose practical methods to mitigate their impact. Participants are encouraged to explore various strategies and supports.
Successful projects in this category should consider factors such as scalability, compatibility with existing blockchain platforms, and user experience. It is essential to ensure that the proposed optimization techniques do not compromise the security or correctness of transactions and smart contracts.
Submissions earning other Nefture bounties are not eligible for the prize pool.

Nefture Optimize Challenge

### **Analysis 🏆**

The "Analysis” prize is designed for innovative projects who are able to build a new product, service or tool capable of automatically analyzing smart contracts and detect vulnerabilities.

This challenge aims to address the critical need for advanced techniques and solutions to identify and mitigate potential vulnerabilities in smart contracts. 


*Acceptance Criteria*

To be eligible for the "Analysis" prize, your project should demonstrate a deep understanding of smart contract vulnerabilities and propose an innovative method for identifying and analyzing them. The automated analysis should cover a broad range of potential vulnerabilities.

Successful projects in this category should also consider factors like accuracy, efficiency, scalability, and user-friendliness in their solutions. The ability to handle various programming languages commonly used for smart contracts, such as Solidity, Vyper, or Michelson, will be advantageous. 

Bonus if you are integrating machine learning, static analysis, or other advanced techniques to enhance the analysis capabilities.

Nefture reserves the right to determine eligibility.

Submissions earning other Nefture bounties are not eligible for the prize pool.


<h3 dir="auto">Analysis 🏆</h3>
The "Analysis” prize is designed for innovative projects who are able to build a new product, service or tool capable of automatically analyzing smart contracts and detect vulnerabilities.
This challenge aims to address the critical need for advanced techniques and solutions to identify and mitigate potential vulnerabilities in smart contracts.
Acceptance Criteria
To be eligible for the "Analysis" prize, your project should demonstrate a deep understanding of smart contract vulnerabilities and propose an innovative method for identifying and analyzing them. The automated analysis should cover a broad range of potential vulnerabilities.
Successful projects in this category should also consider factors like accuracy, efficiency, scalability, and user-friendliness in their solutions. The ability to handle various programming languages commonly used for smart contracts, such as Solidity, Vyper, or Michelson, will be advantageous.
Bonus if you are integrating machine learning, static analysis, or other advanced techniques to enhance the analysis capabilities.
Nefture reserves the right to determine eligibility.
Submissions earning other Nefture bounties are not eligible for the prize pool.

Nefture Analysis Challenge

This prize is offered for any dapp, wallet, client, or mobile app that uses INTU’s SDK to create accounts for their end-users. This can include:

- DAO interfaces
- Web3 Games
- Metaverse Interfaces
- Wallets, including Smart Contract, browser, mobile, and in-app key management solutions
- NFT-focused Interfaces
- DeFi-focused dashboards, aggregators, or tooling

These interfaces can make use of INTU’s dynamic private keyshares for a variety of purposes, including flexible ownership, account recovery, proactive security, account transfer, or custom onboarding/offboarding.  

**Acceptance Criteria**
A successful integration to qualify for the prize will be defined as allowing users to create INTU accounts within an application, using a custom, or purpose-specific interface. INTU reserves the right to determine eligibility.

Submissions earning other INTU bounties are not eligible for other prizes.


This prize is offered for any dapp, wallet, client, or mobile app that uses INTU’s SDK to create accounts for their end-users. This can include:
<ul dir="auto">
<li>DAO interfaces</li>
<li>Web3 Games</li>
<li>Metaverse Interfaces</li>
<li>Wallets, including Smart Contract, browser, mobile, and in-app key management solutions</li>
<li>NFT-focused Interfaces</li>
<li>DeFi-focused dashboards, aggregators, or tooling</li>
</ul>
These interfaces can make use of INTU’s dynamic private keyshares for a variety of purposes, including flexible ownership, account recovery, proactive security, account transfer, or custom onboarding/offboarding.
Acceptance Criteria 
A successful integration to qualify for the prize will be defined as allowing users to create INTU accounts within an application, using a custom, or purpose-specific interface. INTU reserves the right to determine eligibility.
Submissions earning other INTU bounties are not eligible for other prizes.

INTU Interface Challenge

This prize is intended for projects that are applying INTU’s SDK for other (non end-user) infrastructure providers in the Web3 space. Examples include:

- Proof of Stake Validator Networks, or Distributed Solo-staker Clients
- Liquid Staking Providers
- Relayers
- Cross-chain Infrastructure providers, such as guardians
- Enterprise or Organization Shared Treasuries
- DAO Frameworks

Essentially, any environment where infrastructure would benefit from sharing keyshares from a single account rather than coordinate several individual EOAs with a consensus mechanism.

**Acceptance Criteria**
A successful integration to qualify for the prize pool will be defined as creating and/or using INTU accounts for infrastructure applications. INTU reserves the right to determine eligibility.
Submissions earning other INTU bounties are not eligible for the prize pool.


This prize is intended for projects that are applying INTU’s SDK for other (non end-user) infrastructure providers in the Web3 space. Examples include:
<ul dir="auto">
<li>Proof of Stake Validator Networks, or Distributed Solo-staker Clients</li>
<li>Liquid Staking Providers</li>
<li>Relayers</li>
<li>Cross-chain Infrastructure providers, such as guardians</li>
<li>Enterprise or Organization Shared Treasuries</li>
<li>DAO Frameworks</li>
</ul>
Essentially, any environment where infrastructure would benefit from sharing keyshares from a single account rather than coordinate several individual EOAs with a consensus mechanism.
Acceptance Criteria 
A successful integration to qualify for the prize pool will be defined as creating and/or using INTU accounts for infrastructure applications. INTU reserves the right to determine eligibility. 
Submissions earning other INTU bounties are not eligible for the prize pool.

INTU Infrastructure Challenge

INTU introduces dynamic private keyshares for all developers, regardless of background or experience. The “Innovators” prize is for projects who use this new framework to build a new product, service, protocol, or infrastructure. The sky is limit with what’s possible, now that Web3 accounts have changeable “passwords”! 

These projects are intended to be used by other builders to improve their own end-user experience.

Examples include:

- PAYMASTER or Proxy Payment Systems, including micro transactions 
- One-click On-boarding Infrastructure, Social Log-in, WebAuthN, PassKeys, etc
- Conditions-based Access Control
- INTU Keyshare Assignment to non-EOA factors
- INTU on non-blockchain channels of communication
- INTU + Digital ID, including on-chain credentials, off-chain credentials, and ZKP-based Conditional verification


Current projects building on INTU we would consider innovative applications: 
[Manda](https://medium.com/@intuofficial/revolutionizing-otc-desks-with-mandadao-and-intus-sdk-pioneering-a-fair-and-secure-future-for-f929ec443fb7)
[Kagami](https://medium.com/@intuofficial/a-new-era-of-self-custody-how-kagami-and-intu-are-revolutionizing-digital-asset-management-d0cad7c248d0)
 
**Acceptance Criteria**

 Projects are eligible for submission if they can demonstrate that their innovation is useful, technically feasible, and integrates with common frameworks. They are not required to have a front-end, or be usable by an end-user. Bonus points if the project is able to demonstrate the innovative protocol, service, or infrastructure live, either in a simple front-end or in terminal.

INTU reserves the right to determine eligibility.
Submissions earning other INTU bounties are not eligible for the prize pool.

INTU introduces dynamic private keyshares for all developers, regardless of background or experience. The “Innovators” prize is for projects who use this new framework to build a new product, service, protocol, or infrastructure. The sky is limit with what’s possible, now that Web3 accounts have changeable “passwords”!
These projects are intended to be used by other builders to improve their own end-user experience.
Examples include:
<ul dir="auto">
<li>PAYMASTER or Proxy Payment Systems, including micro transactions</li>
<li>One-click On-boarding Infrastructure, Social Log-in, WebAuthN, PassKeys, etc</li>
<li>Conditions-based Access Control</li>
<li>INTU Keyshare Assignment to non-EOA factors</li>
<li>INTU on non-blockchain channels of communication</li>
<li>INTU + Digital ID, including on-chain credentials, off-chain credentials, and ZKP-based Conditional verification</li>
</ul>
Current projects building on INTU we would consider innovative applications: 
<a href="https://medium.com/@intuofficial/revolutionizing-otc-desks-with-mandadao-and-intus-sdk-pioneering-a-fair-and-secure-future-for-f929ec443fb7" rel="nofollow">Manda</a> 
<a href="https://medium.com/@intuofficial/a-new-era-of-self-custody-how-kagami-and-intu-are-revolutionizing-digital-asset-management-d0cad7c248d0" rel="nofollow">Kagami</a>
Acceptance Criteria
Projects are eligible for submission if they can demonstrate that their innovation is useful, technically feasible, and integrates with common frameworks. They are not required to have a front-end, or be usable by an end-user. Bonus points if the project is able to demonstrate the innovative protocol, service, or infrastructure live, either in a simple front-end or in terminal.
INTU reserves the right to determine eligibility. 
Submissions earning other INTU bounties are not eligible for the prize pool.

INTU Innovator Challenge

In the Web3 ecosystem, public goods refer to digital resources or services that are collectively created and maintained by the community for the benefit of all participants. These can include decentralized protocols, open-source software, and shared data sets that promote transparency and enable interoperability between different applications.

**Inspiration:**

Build a dApp focused on privacy, data, messaging, that leverages existing tools:

- Use existing decentralized Data storages like IPFS/ Filecoin
- build infrastructure for tokenized carbon (Toucan Protocol) - e.g., automate offsetting
- analyze data with [The Graph](https://thegraph.com/hosted-service/subgraph/toucanprotocol/alfajores) and build boards on [Dune](https://dune.com/browse/dashboards)


## Prizes

🥇 $700 in cUSD 

🥈 $300 in cUSD

In the Web3 ecosystem, public goods refer to digital resources or services that are collectively created and maintained by the community for the benefit of all participants. These can include decentralized protocols, open-source software, and shared data sets that promote transparency and enable interoperability between different applications.
Inspiration:
Build a dApp focused on privacy, data, messaging, that leverages existing tools:
<ul dir="auto">
<li>Use existing decentralized Data storages like IPFS/ Filecoin</li>
<li>build infrastructure for tokenized carbon (Toucan Protocol) - e.g., automate offsetting</li>
<li>analyze data with <a href="https://thegraph.com/hosted-service/subgraph/toucanprotocol/alfajores" rel="nofollow">The Graph</a> and build boards on <a href="https://dune.com/browse/dashboards" rel="nofollow">Dune</a></li>
</ul>
<h2 dir="auto">Prizes</h2>
🥇 $700 in cUSD
🥈 $300 in cUSD

Create Staking-Promise project

Create BabyBlocks.md

Create Contagged.md

Create Libreria_Libre.md

Create Stake For Good

Discover the Future of Web3: Learn, Build, and Innovate at the 24-Hour Hackathon at the Leipzig Spinnerei on the 28/29th of June 2023

Celo - Public goods - $1.000

ReFi, short for **Regenerative Finance**, is a concept and approach to finance that seeks to align economic activities with social and environmental regeneration. It goes beyond traditional finance by considering the broader impacts of investments and financial decisions on communities and ecosystems. ReFi aims to support projects and initiatives that prioritize sustainability, social equity, and resilience, promoting a more inclusive and environmentally conscious economy. This approach often involves investing in regenerative agriculture, renewable energy, community development, and other areas that contribute to long-term ecological and social well-being.

**Inspiration:**

Build a dApp that focuses on prioritizing sustainability, social equity, and resilience, promoting a more inclusive and environmentally conscious economy

- Build a dApp that helps to fight social inequality (gender, race, socio-economic background)
- Build a dApp that helps to fight climate change

## Prizes

🥇 $700 in cUSD

🥈 $300 in cUSD

ReFi, short for Regenerative Finance, is a concept and approach to finance that seeks to align economic activities with social and environmental regeneration. It goes beyond traditional finance by considering the broader impacts of investments and financial decisions on communities and ecosystems. ReFi aims to support projects and initiatives that prioritize sustainability, social equity, and resilience, promoting a more inclusive and environmentally conscious economy. This approach often involves investing in regenerative agriculture, renewable energy, community development, and other areas that contribute to long-term ecological and social well-being.
Inspiration:
Build a dApp that focuses on prioritizing sustainability, social equity, and resilience, promoting a more inclusive and environmentally conscious economy
<ul dir="auto">
<li>Build a dApp that helps to fight social inequality (gender, race, socio-economic background)</li>
<li>Build a dApp that helps to fight climate change</li>
</ul>
<h2 dir="auto">Prizes</h2>
🥇 $700 in cUSD
🥈 $300 in cUSD

Celo - ReFi - $1.000

The top three winners will present their projects on the Pitch Stage of the MACHN-Web3 Hackahton.

## Acceptance Criteria 🏁


- You and your team must be physically present at the MACHN-Web3 Hackathon to work on a project for submission

- You and your entire team must be physically present at the closing ceremonies to win a prize

- You must form a team of 2-4 members

- Your project must integrate blockchain technology (other chains besides Ethereum are fine)

- You must have a deployed contract on any Ethereum network / testnet

- You must submit a presentation or video to present your idea

- You must provide a link to your deployed version or provide a video with a walkthrough

- You cannot work on your project before the event begins on June 28th, 10am CEST

- You cannot steal another team's source code or use previous code from another hackathon

- Pre-existing projects are not allowed. You may, however, build a new feature for an existing project that is unique and standalone. If you are going to #BUIDL on a pre-existing project, we strongly suggest speaking with the one of the organizers and get permission

- Please comply with all instructions from ETHDenver organizers

- Be cool - disruptive behavior will not be tolerated and may result in disqualification

- Decisions are final for determining prizes and awards by the judges



## Reward Pool 💸

USDC 250



The top three winners will present their projects on the Pitch Stage of the MACHN-Web3 Hackahton.
<h2 dir="auto">Acceptance Criteria 🏁</h2>
<ul dir="auto">
<li>
You and your team must be physically present at the MACHN-Web3 Hackathon to work on a project for submission
</li>
<li>
You and your entire team must be physically present at the closing ceremonies to win a prize
</li>
<li>
You must form a team of 2-4 members
</li>
<li>
Your project must integrate blockchain technology (other chains besides Ethereum are fine)
</li>
<li>
You must have a deployed contract on any Ethereum network / testnet
</li>
<li>
You must submit a presentation or video to present your idea
</li>
<li>
You must provide a link to your deployed version or provide a video with a walkthrough
</li>
<li>
You cannot work on your project before the event begins on June 28th, 10am CEST
</li>
<li>
You cannot steal another team's source code or use previous code from another hackathon
</li>
<li>
Pre-existing projects are not allowed. You may, however, build a new feature for an existing project that is unique and standalone. If you are going to #BUIDL on a pre-existing project, we strongly suggest speaking with the one of the organizers and get permission
</li>
<li>
Please comply with all instructions from ETHDenver organizers
</li>
<li>
Be cool - disruptive behavior will not be tolerated and may result in disqualification
</li>
<li>
Decisions are final for determining prizes and awards by the judges
</li>
</ul>
<h2 dir="auto">Reward Pool 💸</h2>
USDC 250

Main Track - all projects apply

### Component

Forge, Cast

### Describe the feature you would like

I'm currently migrating from `dapp.tools` and it had this nice UX to handle keystore files:

1. Declare the following env vars:
 - `ETH_KEYSTORE`: the path to the keystore **directory**
 - `ETH_FROM`: the account from which send the tx from (I believe this was used to find the right keystore **file** inside the keystore directory).
 - `ETH_PASSWORD`: the **path** to a plain-text password file with the password for the keystore file in the local file system.
2. Anything requiring wallet signing pickups the above variables automatically:
 ```bash
 dapp create src/MyContract.sol:MyContract
 seth send $ADDRESS "myFunc(address)" $ARG
 ```

I'm finding it a bit difficult to work with Foundry for that purpose. Specifically regarding contract deployment. Main differences are:

1. `ETH_KEYSTORE` works, but it expects a keystore **file**, not a directory.
2. `ETH_FROM` is redundant, since the sender wallet is derived from `ETH_KEYSTORE`
3. `ETH_PASSWORD` doesn't work.

Also if I use `CAST_PASSWORD` env var, `forge create` does not pick it up, so I need to be explicit when passing it:

```bash
forge create --password=${CAST_PASSWORD} src/MyContract.sol:MyContract.sol
```

Also ideally such configs could be in `foundry.toml` as well:

```toml
[default]
password-file = '~/.eth-password'

# either
keystore-directory = '~/.ethereum/keystore'
from = '0xdeAD00000000000000000000000000000000dEAd'

# or
keystore-file = '~/.ethereum/keystore/UTC--2022-01-01T00-00-00.000000000Z--dead00000000000000000000000000000000dead'

```

Furthermore, users should have the liberty to overwrite any configs with environment variables. For example, it's very useful to be able to define a keystore directory containing multiple accounts and define the `from` address with env vars.

```
FOUNDRY_ETH_FROM=0x0783...122 FOUNDRY_PASSWORD_FILE=~/.eth-password-0783...122 forge deploy ...
```

### Additional context

As a workaround, I have written a small helper script to allow me to use `forge` the same way I could use `dapp.tools`. Perhaps this can help guiding the implementation.

```bash
#!/bin/bash

# scripts/deploy.sh

set -eo pipefail

function log() {
 echo -e "$@" >&2
}

function die() {
 log "$@"
 log ""
 exit 1
}

function err_msg_keystore_file() {
cat <<MSG
ERROR: could not determine the location of the keystore file.

You should either define:

\t1. The FOUNDRY_ETH_KEYSTORE_FILE env var or;
\t2. Both FOUNDRY_ETH_KEYSTORE_DIR and FOUNDRY_ETH_FROM env vars.
MSG
}

function err_msg_etherscan_api_key() {
cat <<MSG
ERROR: cannot verify contracts without ETHERSCAN_API_KEY being set.

You should either:

\t1. Not use the --verify flag or;
\t2. Define the ETHERSCAN_API_KEY env var.
MSG
}

function usage() {
cat <<MSG
deploy.sh contract_path [--constructor-args ...args]

Examples:

\t# Constructor does not take any arguments
\tdeploy.sh src/MyContract.sol:MyContract

\t# Constructor takes (uint, address) arguments
\tdeploy.sh src/MyContract.sol:MyContract --constructor-args 1 0x0000000000000000000000000000000000000000
MSG
}

function deploy() {
 local ENV_FILE="${BASH_SOURCE%/*}/../.env"
 [ -f "$ENV_FILE" ] && source "$ENV_FILE"

 FOUNDRY_ETH_FROM="${FOUNDRY_ETH_FROM:-$ETH_FROM}"
 FOUNDRY_ETHERSCAN_API_KEY="${FOUNDRY_ETHERSCAN_API_KEY:-$ETHERSCAN_API_KEY}"
 FOUNDRY_ETH_KEYSTORE_DIRECTORY="${FOUNDRY_ETH_KEYSTORE_DIRECTORY:-$ETH_KEYSTORE}"

 if [ -z "$FOUNDRY_ETH_KEYSTORE_FILE" ]; then
 [ -z "$FOUNDRY_ETH_KEYSTORE_DIRECTORY" ] && die "$(err_msg_keystore_file)"
 # Foundy expects the Ethereum Keystore file, not the directory.
 # This step assumes the Keystore file for the deployed wallet includes $ETH_FROM in its name.
 FOUNDRY_ETH_KEYSTORE_FILE="${FOUNDRY_ETH_KEYSTORE_DIRECTORY%/}/$(ls -1 $FOUNDRY_ETH_KEYSTORE_DIRECTORY | \
 # -i: case insensitive
 # #0x: strip the 0x prefix from the the address
 grep -i ${FOUNDRY_ETH_FROM#0x})"
 fi
 [ -z "$FOUNDRY_ETH_KEYSTORE_FILE" ] && die "$(err_msg_keystore_file)"

 # Handle reading from the password file
 local PASSWORD_OPT=''
 if [ -f "$FOUNDRY_ETH_PASSWORD_FILE" ]; then
 PASSWORD_OPT="--password=$(cat "$FOUNDRY_ETH_PASSWORD_FILE")"
 fi

 # Require the Etherscan API Key if --verify option is enabled
 set +e
 if grep -- '--verify' <<< "$@" > /dev/null; then
 [ -z "$FOUNDRY_ETHERSCAN_API_KEY" ] && die "$(err_msg_etherscan_api_key)"
 fi
 set -e

 # Log the command being issued, making sure not to expose the password
 log "forge create --keystore="$FOUNDRY_ETH_KEYSTORE_FILE" $(sed 's/=.*$/=[REDACTED]/' <<<${PASSWORD_OPT}) $@"
 forge create --keystore="$FOUNDRY_ETH_KEYSTORE_FILE" ${PASSWORD_OPT} $@
}

# Executes the function if it's been called as a script.
# This will evaluate to false if this script is sourced by other script.
if [ "$0" = "$BASH_SOURCE" ]; then
 if [ $# -eq 0 ]; then
 die "$(usage)"
 fi

 [ "$1" = '-h' ] || [ "$1" = '--help' ] && {
 log "$(usage)"
 exit 0
 }

 deploy $@
fi
```

```bash
# .env

export FOUNDRY_ETHERSCAN_API_KEY=API_KEY
export FOUNDRY_ETH_FROM=WALLET_ADDRESS
export FOUNDRY_ETH_KEYSTORE_DIRECTORY=PATH_OF_ETHEREUM_KEYSTORE_DIR # i.e.: ${HOME}/.ethereum/keystore/
export FOUNDRY_ETH_PASSWORD=PATH_OF_ETHEREUM_PASSWORD_FILE

T-feature

C-cast

Rust

Solidity

Shell

Dockerfile

feat: wallet import

improvement: cast wallet import / --account option

Improve wallet management UX using Keystore

Describe what your bounty is about.

FOAM is creating a proof of location protocol for Web3 and other applications. The FOAM Trust Zone Program is currently beta-testing radios for localization. This testing will generate data and lessons learned to improve the FOAM technical stack, ahead of future open releases of the FOAM network. FAQ: https://mirror.xyz/foamspace.eth/9QRjUNdAuw80x9CLvMs76hEp-LVpV92CXVyGmC0H4fU

We are looking for additional locations that can be used to host FOAM radios for testing for participant teams in Austin, Texas.

If you have access to a quality location that could host a FOAM radio for a period of 6 months or more, we would like to briefly meet with you to discuss and evaluate your location.

Describe what your bounty is about.
FOAM is creating a proof of location protocol for Web3 and other applications. The FOAM Trust Zone Program is currently beta-testing radios for localization. This testing will generate data and lessons learned to improve the FOAM technical stack, ahead of future open releases of the FOAM network. FAQ: <a href="https://mirror.xyz/foamspace.eth/9QRjUNdAuw80x9CLvMs76hEp-LVpV92CXVyGmC0H4fU" rel="nofollow">https://mirror.xyz/foamspace.eth/9QRjUNdAuw80x9CLvMs76hEp-LVpV92CXVyGmC0H4fU</a>
We are looking for additional locations that can be used to host FOAM radios for testing for participant teams in Austin, Texas.
If you have access to a quality location that could host a FOAM radio for a period of 6 months or more, we would like to briefly meet with you to discuss and evaluate your location.

HTML

FOAM Location Scouting (Austin)

We are looking for an experienced Go developer who is interested in writing a service which monitors DIA oracles performance metrics.

The service should take these parameters as _input_:
1. Oracle address
2. Chain ID
3. RPC node
 
Given these input parameters, it should connect to the respective blockchain via RPC node and scan for oracle update events.
More precisely, the the following _output_ quantities should be written into a database:
1. Oracle creation date
2. Oracle funding wallet address
3. Transaction hash
4. Block number
5. Timestamp of block inclusion
6. Asset which got updated
7. Asset value
8. Timestamp of data inside (part of the update)
9. Gas usage
10. Gas cost
11. Total transaction cost
12. Remaining gas funds in oracle funding wallet
13. TX sender

As there is no straightforward way to get the Oracle creation date/block/hash please proceed as follows:
Check for the latest transaction in the DB. If there is no entry, iterate backwards in history and fetch all transactions until you hit the contract creation. If there is an entry, continue from this block until now.

Furthermore, please:
- Write the service in Go
- Use timescaleDB as database
- Allow to input more than one contract address per blockchain and run the service on multiple blockchains in parallel
- Develop comprehensive unit tests to ensure functionality and robustness of the oracle monitoring service
- Deliver a docker container with entire functionality
- Provide documentation for setting up the service and running tests 

Resources:
[Documentation for DIA oracles architecture](https://docs.diadata.org/documentation/oracle-documentation)
[Demo oracles](https://docs.diadata.org/documentation/oracle-documentation/deployed-contracts)

If you have questions don't hesitate to ask. Ideally we can connect on our Discord server in order to discuss if necessary.

We are looking for an experienced Go developer who is interested in writing a service which monitors DIA oracles performance metrics.
The service should take these parameters as input:
<ol dir="auto">
<li>Oracle address</li>
<li>Chain ID</li>
<li>RPC node</li>
</ol>
Given these input parameters, it should connect to the respective blockchain via RPC node and scan for oracle update events. 
More precisely, the the following output quantities should be written into a database:
<ol dir="auto">
<li>Oracle creation date</li>
<li>Oracle funding wallet address</li>
<li>Transaction hash</li>
<li>Block number</li>
<li>Timestamp of block inclusion</li>
<li>Asset which got updated</li>
<li>Asset value</li>
<li>Timestamp of data inside (part of the update)</li>
<li>Gas usage</li>
<li>Gas cost</li>
<li>Total transaction cost</li>
<li>Remaining gas funds in oracle funding wallet</li>
<li>TX sender</li>
</ol>
As there is no straightforward way to get the Oracle creation date/block/hash please proceed as follows: 
Check for the latest transaction in the DB. If there is no entry, iterate backwards in history and fetch all transactions until you hit the contract creation. If there is an entry, continue from this block until now.
Furthermore, please:
<ul dir="auto">
<li>Write the service in Go</li>
<li>Use timescaleDB as database</li>
<li>Allow to input more than one contract address per blockchain and run the service on multiple blockchains in parallel</li>
<li>Develop comprehensive unit tests to ensure functionality and robustness of the oracle monitoring service</li>
<li>Deliver a docker container with entire functionality</li>
<li>Provide documentation for setting up the service and running tests</li>
</ul>
Resources: 
<a href="https://docs.diadata.org/documentation/oracle-documentation" rel="nofollow">Documentation for DIA oracles architecture</a> 
<a href="https://docs.diadata.org/documentation/oracle-documentation/deployed-contracts" rel="nofollow">Demo oracles</a>
If you have questions don't hesitate to ask. Ideally we can connect on our Discord server in order to discuss if necessary.

init

Track oracle performances

Build Oracle Monitoring Tool

# Description 📃
This bounty can be split into sub-bounties by each individual RPC request type (e.g. view access key, view access keys list, transaction in the block, view state, etc). Each sub-bounty can be implemented by a different team. In order to benefit from having Near light client integrated into near-api-js, we need the RPC interface of Near node to return proofs for most of the RPC replies (e.g. have an option to do it when “proof” parameter is passed). For example, the proof of a transaction being included into the block would consist of: merkle path towards transaction in a shard, merkle path towards shard hash. For access keys and viewing state you would need to provide the path in merkle patricia trie. We have already implemented proof for Transaction Status, which you can use as an example: https://docs.near.org/api/rpc/transactions#transaction-status.

## Acceptance Criteria 🏁
Please complete your bounties in the form of pull-requests to https://github.com/near/nearcore 

## Reward Pool 💸
USDC **16000**

<h1 dir="auto">Description 📃</h1>
This bounty can be split into sub-bounties by each individual RPC request type (e.g. view access key, view access keys list, transaction in the block, view state, etc). Each sub-bounty can be implemented by a different team. In order to benefit from having Near light client integrated into near-api-js, we need the RPC interface of Near node to return proofs for most of the RPC replies (e.g. have an option to do it when “proof” parameter is passed). For example, the proof of a transaction being included into the block would consist of: merkle path towards transaction in a shard, merkle path towards shard hash. For access keys and viewing state you would need to provide the path in merkle patricia trie. We have already implemented proof for Transaction Status, which you can use as an example: https://docs.near.org/api/rpc/transactions#transaction-status.
<h2 dir="auto">Acceptance Criteria 🏁</h2>
Please complete your bounties in the form of pull-requests to https://github.com/near/nearcore 
<h2 dir="auto">Reward Pool 💸</h2>
USDC 16000

Create NEAR_Verifiable_RPC_ETHEN_POCIASK

Create NEAR_Verifiable_RPC_ANUP_SWAMY_VEENA

Create NEAR_VERIFIABLE_RPC_Anto.md

Create NEAR_Verifiable_RPC_ANTO_JOSEPH

NEAR: Verifiable RPC replies

# Description 📃
L1, L2, side chains, zk rollups, POA networks, dev tools, wallets, on-chain privacy, etc.

## Acceptance Criteria 🏁
<ul><li>You and your team must be physically present at ETHDenver to work on a project for submission</li><li>You and your entire team must be physically present at the closing ceremonies to win a prize</li><li>You must form a team of 2-4 members</li><li>Your project must integrate blockchain technology (other chains besides Ethereum are fine)</li><li>You cannot work on your project before the event begins on February 24, 2023, 10 AM MST</li><li>You cannot steal another team's source code or use previous code from another hackathon</li><li>Pre-existing projects are not allowed. You may, however, build a new feature for an existing project that is unique and standalone. If you are going to #BUIDL on a pre-existing project, we strongly suggest speaking with the BUIDLx Stewards and get permission from the #BUIDL Steward.</li><li>Please comply with all instructions from ETHDenver organizers</li><li>Be cool - disruptive behavior will not be tolerated and may result in disqualification</li><li>Please refer to the waiver you signed when applying for the event for additional details regarding appropriate behavior.</li><li>Decisions are final for determining prizes and awards by the #BUIDL Steward and/or #BUIDLx TeamThe #BUIDL Steward is like the commissioner of any sports league. The #BUIDL Steward will hav final say in your team and projects eligibility in #BUIDLathon, prizes, and awards for all track prizes and sponsor bounties.&nbsp;</li></ul>

## Reward Pool 💸
USDC **15000**

<h1 dir="auto">Description 📃</h1>
L1, L2, side chains, zk rollups, POA networks, dev tools, wallets, on-chain privacy, etc.
<h2 dir="auto">Acceptance Criteria 🏁</h2>
<ul dir="auto"><li>You and your team must be physically present at ETHDenver to work on a project for submission</li><li>You and your entire team must be physically present at the closing ceremonies to win a prize</li><li>You must form a team of 2-4 members</li><li>Your project must integrate blockchain technology (other chains besides Ethereum are fine)</li><li>You cannot work on your project before the event begins on February 24, 2023, 10 AM MST</li><li>You cannot steal another team's source code or use previous code from another hackathon</li><li>Pre-existing projects are not allowed. You may, however, build a new feature for an existing project that is unique and standalone. If you are going to #BUIDL on a pre-existing project, we strongly suggest speaking with the BUIDLx Stewards and get permission from the #BUIDL Steward.</li><li>Please comply with all instructions from ETHDenver organizers</li><li>Be cool - disruptive behavior will not be tolerated and may result in disqualification</li><li>Please refer to the waiver you signed when applying for the event for additional details regarding appropriate behavior.</li><li>Decisions are final for determining prizes and awards by the #BUIDL Steward and/or #BUIDLx TeamThe #BUIDL Steward is like the commissioner of any sports league. The #BUIDL Steward will hav final say in your team and projects eligibility in #BUIDLathon, prizes, and awards for all track prizes and sponsor bounties. </li></ul>
<h2 dir="auto">Reward Pool 💸</h2>
USDC 15000

kopy-kat

Create olivert1.md

Create INHERITABLE.md

Create SLANG_NODESLANGER5000

Create olivert1.md 

Create SWAPPY

philogy

Create REENTRANCY_PROXY_ARIEL_TM.md

Create INHERITABLE_PAULLOH.md

Create SLANG.md

Create SWAPPY_PILOT.md

ETHDenver: #BUIDLathon 2023 Infrastructure + Scalability

# Description 📃
This task is designed to incentivize using decentralized architecture in your projects. Pocket Network provides the only reliable and decentralized RPC network in the world governed by a DAO with the most contributor-friendly ecosystem. Pocket offers free connections to dozens of chains, from Ethereum and Polygon to Fantom and FUSE.

## Acceptance Criteria 🏁
● Decentralize your RPC for any project using a Pocket endpoint ● Endpoints must be private and minted by application developers (no public RPC usage) We reserve the right to withhold prizing in cases where low-quality submissions do not meet our bounty requirements.

## Reward Pool 💸
USDC **3750**

<h1 dir="auto">Description 📃</h1>
This task is designed to incentivize using decentralized architecture in your projects. Pocket Network provides the only reliable and decentralized RPC network in the world governed by a DAO with the most contributor-friendly ecosystem. Pocket offers free connections to dozens of chains, from Ethereum and Polygon to Fantom and FUSE.
<h2 dir="auto">Acceptance Criteria 🏁</h2>
● Decentralize your RPC for any project using a Pocket endpoint ● Endpoints must be private and minted by application developers (no public RPC usage) We reserve the right to withhold prizing in cases where low-quality submissions do not meet our bounty requirements.
<h2 dir="auto">Reward Pool 💸</h2>
USDC 3750

Create scoronelhamilton.md

ferrodri.md

DeFi Detective - Darryl

Blockhead - Darryl

Create Bandit_Club_Albert_Su.md

Create Gelkin_Joshia_Seam

Create Gelkin_Jim_Jim_Valkema

Create Gelkin_YongKang_Chia

Create SQUIRRLY_MATT_LEE.md

zmitzie

Create Squirrly_Adam_Reis.md

Create defi_detective_plotchy.md

Create SQUIRRLY_BEAU_TROXCLAIR

Create DAyOri_Yuzu

Create BEAD_DAO_JAYDEN_WINDLE.md

Create DAyOri_Aru_Sasaki

Create DIATOMIX_PEDRO_GALVEIAS.md

PETERISPRIEDITIS

Create laurens-van-kessenich

Create PEANUT_PROTOCOL.md

Create MEV_NFT DATA SHIELD.md

Create MEV_NFT_JEFF.md

Pokt Network: Build on Pocket Network

# Description 📃
Integrate Web3Auth or Torus Wallet into your project and make the onboarding user experience as seamless as possible for your users.

## Acceptance Criteria 🏁
Incorporate either Web3Auth Plug and Play, Core Kit, or Torus Wallet into your application and build a user-centric onboarding flow. Judging will lean towards projects that are full MVPs that focus on the UX, although a clean and creative implementation of the feature serving as an excellent example of feature usage is also acceptable. Please show a steady commit trail and thought process e.g. sketches, discussion, issues on how you arrived at the decision to incorporate this feature.

## Reward Pool 💸
USDC **1000**

<h1 dir="auto">Description 📃</h1>
Integrate Web3Auth or Torus Wallet into your project and make the onboarding user experience as seamless as possible for your users.
<h2 dir="auto">Acceptance Criteria 🏁</h2>
Incorporate either Web3Auth Plug and Play, Core Kit, or Torus Wallet into your application and build a user-centric onboarding flow. Judging will lean towards projects that are full MVPs that focus on the UX, although a clean and creative implementation of the feature serving as an excellent example of feature usage is also acceptable. Please show a steady commit trail and thought process e.g. sketches, discussion, issues on how you arrived at the decision to incorporate this feature.
<h2 dir="auto">Reward Pool 💸</h2>
USDC 1000

HELP ME

COMPANY

RESOURCES