Relays, Multisig, Fiat Onramping, Auth

[0x4007]

• Relays are useful for automation related to payouts
• Safe for partner key rotation
• Fiat onramping could be nice for the future for non crypto native partners
• Auth kit maybe something there

---

This has everything we discussed as well as fiat onramping @rndquu

https://twitter.com/safe/status/1630946971002507265?s=46&t=fLzoRySawhTzZHfr3g9x9A

[rndquu]

@pavlovcik @0xcodercrane

Right now if the bot's private key is compromised then all funds can be stolen so we can't keep a decent amount of DAI on the bot's address.

We can add a Gnosis Safe multisig which requires 2 signatures (bot + admin) to transfer a bounty hunter's reward.

With Gnosis Safe the flow will be the following:

1. Bounty hunter posts a /payout command
2. Bot (using gnosis safe web SDK) creates a "send tokens" transaction (the bot doesn't pay for gas, creating a transaction simply means a POST request) and signs it
3. Bot posts a URL to gnosis safe transaction. Example: https://app.safe.global/gor:0x26a464753F0b953bCFf7258A9F0Ce4F36169F57B/transactions/tx?id=multisig_0x26a464753F0b953bCFf7258A9F0Ce4F36169F57B_0xc01bba2306aa08335ef920467186fe24c9880ae848b3a77889979efdb8c1df26
4. Admin opens the gnosis safe transaction URL and signs it (offchain, admin doesn't pay for gas)
5. On some bot's repository event the bot checks whether the "send tokens" transaction is signed by 2 parties (bot + admin) and posts something like "@john you can claim your reward"
6. Bounty hunter opens https://app.safe.global/gor:0x26a464753F0b953bCFf7258A9F0Ce4F36169F57B/transactions/tx?id=multisig_0x26a464753F0b953bCFf7258A9F0Ce4F36169F57B_0xc01bba2306aa08335ef920467186fe24c9880ae848b3a77889979efdb8c1df26 and executes a transaction

Pros:

1. We can keep a decent amount of DAI in a gnosis safe
2. All interactions are executed via the gnosis safe UI, so we don't need https://pay.ubq.fi/
3. We don't pay for gas. We only call gnosis safe APIs and send offchain permits. It's on the bounty hunter's side to finally execute a claim transaction.
4. Anybody can confirm that the bounty has been paid

Cons:

1. Admin will have to spend time signing transactions in gnosis safe app

If the proposed approach is fine I can create a demo.

[0x4007]

It's too bad we will have no more use for pay.ubq.fi

I thought it was a nice tool. Perhaps it can be repurposed?

---

Lastly: I did not receive a GitHub notification for you tagging me in the discussion. I guess GitHub doesn't notify for that. I just happened to check the discussions now and noticed this.

[rndquu]

It's too bad we will have no more use for pay.ubq.fi. Perhaps it can be repurposed?

We can keep it and use for small bounties worth <100 USD.

So for small bounties we can keep using uniswap's permit2, the same way we are using it now. (no multisig)

For big bounties(>= 100 USD) we can add support for gnosis safe.

So when a bounty hunter solves a small bounty then the bot posts a permit2 url to pay.ubq.fi. When a bounty hunter solves a big bounty then the bot posts a url to gnosis safe transaction (multisig, should be signed by admin)

[0x4007]

I think that's a great solution. Even better if the cutoff amount is configurable per partner project!

I'm mobile now, would you mind turning this into a bounty for me?

[rndquu]

I want to create a demo first (to make sure that the proposed flow works as expected), then we can create a bounty. Ok?

[0x4007]

Sounds good.

[rndquu]

@pavlovcik

I've checked the gnosis safe API and it has a drawback with ordered nonces. It means that if the bot proposes a transaction from the gnosis safe and admin signs it, then all bounty hunters have to withdraw their payouts in a strict order which is quite an unpleasant UX.

We can try gnosis safe's relay kit and maintain the payouts order on the bot's side (server). So the flow will be the following:

1. Bounty hunter posts a /payout command
2. Bot (using gnosis safe web SDK) creates a "send tokens" transaction (the bot doesn't pay for gas, creating a transaction simply means a POST request) and signs it
3. Bot posts a URL to gnosis safe transaction. Example: https://app.safe.global/gor:0x26a464753F0b953bCFf7258A9F0Ce4F36169F57B/transactions/tx?id=multisig_0x26a464753F0b953bCFf7258A9F0Ce4F36169F57B_0xc01bba2306aa08335ef920467186fe24c9880ae848b3a77889979efdb8c1df26
4. Admin opens the gnosis safe transaction URL and signs it (offchain, admin doesn't pay for gas)
5. On some bot's repository event the bot:
   a) finds all not executed transactions
   b) finds all signed (by 2 parties: admin + bot) transactions from those not executed transactions
   c) relays those transactions maintaining a correct nonce (i.e. sends POST requests to gnosis safe API in a separate order)

So this way:

• bounty hunter pays for gas from his reward
• bot executes payouts

[0x4007]

I think this generally seems fine.

• Perhaps it makes more sense to run automatically when the issue is "closed as completed" instead of the hunter writing /payout (or /claim may be a better verb)
• If I am understanding this correctly, due to the nonce issue, this needs to be a choreographed process with the maintainers and bounty hunter to do it at close timing together right? Could this be resolved with one of Gelato's relayers? It seems like Safe and Gelato have some first party integration.

My somewhat unrelated concern is the private key being leaked from the repository/organization secrets. This will lead to compromise of the permits, but perhaps not on the multisig setup (which is arguably more important.) We should think of a secure, decentralized, and convenient way for our partners to be able to store their signing keys and then for the software to be able to access it.

[rndquu]

If I am understanding this correctly, due to the nonce issue, this needs to be a choreographed process with the maintainers and bounty hunter to do it at close timing together right?

The only thing that needs to be choreographed is transaction order from a single gnosis safe. Each partner will have he his own safe so it is not an issue for the bot to send transactions in a particular order (or simply execute them in a batched mode, need to research if it is possible with gnosis safe)

Could this be resolved with one of Gelato's relayers?

Yes, gnosis safe relayer SDK uses Gelato Network under the hood

My somewhat unrelated concern is the private key being leaked from the repository/organization secrets. This will lead to compromise of the permits.

Yes, if the private key is compromised then funds are at risk. I'll check what we can do.

Ok, I will update the demo for gnosis safe + relayer feature, then share it with you to check. Then we can create a task for gnosis safe intergration with the bot.

[rndquu]

@pavlovcik

My somewhat unrelated concern is the private key being leaked

If the private key is leaked (which is expected to be used for permit2 bounty rewards <100$) then the only way to be 100% sure that everything is gonna be fine is to use multisig (like gnosis safe, i.e. manually approve even small payouts)

What options we have:

1. Keep only small amounts for permit2 feature
2. We can frontrun a malicious transaction. When private key is leaked then an adversary has access to all of the funds (DAI in our case). So he doesn't need to issue a ton of permits when he can simply call transfer() to his own address. We can monitor mempool for transfers >100$ and frontrun with another transfer to our backup address. This is not a 100% reliable solution because if an attacker uses a private mempool then there is no way to frontrun a malicious transfer.
3. Private key rotation, i.e. once a day:
   a) remove approval for permit2 for the old PK
   b) transfer funds to a new address (derived from mnemonic in github secrets)
   c) approve permit2 to use funds for a new address
   But again, if PK (mnemonic) is leaked then it is probably leaked via github auth or github CI actions so an attacker still has access to the updated PK.
4. Use multisig (like gnosis safe) even for small amounts

[rndquu]

@ubiquity/development other options to prevent malicious transfer when private key is leaked are appreciated

[zgorizzo69]

can't see other options right now

[0x4007]

Screenshot from https://github.com/ubiquity/ubiquity-dollar/settings/actions

The good news is that GitHub has thought through this issue about random contributors leaking secrets with exploitative GitHub Actions. We will just need to clearly explain that if the repository settings allow automatic execution for new GitHub Actions, then their private key can be easily leaked. We can make a tutorial that has clear warnings about the risks involved with automatic payouts.

Further readings https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-select-actions-and-reusable-workflows-to-run

---

I wish that we, by default, could enable automatic payouts for 100 USD or less and automatically detect if the vulnerable GitHub repository settings are configured for the current repository and disable the automatic payouts.

@rndquu with some research do you think you can confirm whether this is feasible to do?

[rndquu]

automatically detect if the vulnerable GitHub repository settings are configured

I'll check it

[0x4007]

I'm following up on this research @rndquu

[rndquu]

@pavlovcik

Update regarding the gnosis safe

Gnosis Safe Relay Kit is in its early alpha. Right now it is just a single js file with 100 lines of code. The whole relay kit is basically a wrapper around the @gelatonetwork/relay-sdk package.

I managed to relay transactions (not to Gnosis Safe) to other contracts using a pure @gelatonetwork/relay-sdk package, but I'm still trying to relay any transaction using Gnosis Safe Relay SDK.

I've already asked the Gnosis Safe team of how to make the relay kit working here and here.

So I will switch to other tasks while I'm waiting for the response.

[0x4007]

Thanks for the update. Hopefully they respond soon! I would recommend hunting them down on Telegram/Discord as well.

[0x4007]

@rndquu any updates with this research?

[rndquu]

Auth kit: could be used in the ubiquity dollar's dapp

Onramp kit: not ready for production

Relay kit: uses Gelato Network under the hood. Ready for production. We actually have plans to use it as a part of #274

We could close this discussion because we already have plans to use the relay kit which is the only safe's kit applicable to our project right now