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

### 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

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.

HELP ME

COMPANY

RESOURCES