Match ethereum tx with github issue onchain

[rndquu]

Right now in the audit page we match ethereum transactions for permit2 payouts using github API. So basically we get a list of issues, then get a unique nonce from a claim URL and try find a matching nonce in ethereum transactions from a bot's wallet address. We should be able to do the same thing without github API, purely onchain.

What should be done:

1. On permit2 claim URL generation pass the following query params to https://pay.ubq.fi:
   • owner name
   • repo name
   • issue number
   • permit2 nonce
2. On "claim" button click a bounty hunter uses the MultiSend contract (find the deployed address in the gnosis safe docs or deploy your own) and sends 2 transactions (encoded in a single one): 1) Permit2 claim (no updates in logic here) 2) Onchain message to the bot's wallet address in the format OEPRATION_TYPE;GITHUB_OWNER_NAME;GITHUB_REPOSITORY_NAME;GITHUB_ISSUE_NUMBER;PERMIT2_NONCE. Example: permit2_claim;ubuqity;ubiquity-dollar;112;2391127361723

This way we would be able to match ethereum transactions with github issues purely onchain.

P.S. Some folks may try to utilize a single claim transaction (without an onchain message) which would save them a little gas

[Steveantor]

This will quadruple the gas cost, and saving such data onchain is highly discouraged.

[rndquu]

This will quadruple the gas cost, and saving such data onchain is highly discouraged.

The following test consumes 6096 gas:

function testMy() public {
    string memory message = 'permit2_claim;ubuqity;ubiquity-dollar;10000;18152409738626458174996949170773781281554482055024264523127764418032943016051';
    (bool sent, bytes memory data) = payable(user1).call{value: 0}(abi.encode(message));
}

So it is not too expensive for bounty hunters. I agree that saving such data onchain is kind of a bad practise but I don't see another solution if we want to use onchain analytics services (in particular for the case of matching github issues with payout transactions).

Perhaps it is even cheaper to deploy our own contract that emits a "Payout" event.

[0x4007]

Perhaps it is even cheaper to deploy our own contract that emits a "Payout" event.

I am not a Solidity developer so I can't speak from experience on the better implementation/approach.

Perhaps we can decode transactions using a custom web app that can lookup everything based on the GitHub issue ID? We would only include the GitHub ID in the transaction call data. This seems to be significantly slower for auditing but given that most users will be spending money on claim transactions, I think its a net benefit to optimize gas efficiency and in exchange, make the audit process a bit more slow/complex.

How much would 6096 gas cost in USD on Optimism now?

[0x4007]

Also I know that there are micro gas optimizations around addresses with more 0s. Perhaps we can just make all of our permit deadlines

90000000000000000000000000000000000000000000000000000000000000000000000000000

Instead of something like in your example:

18152409738626458174996949170773781281554482055024264523127764418032943016051

[rndquu]

I think it is better to put this issue on hold and wait until gnosis safe intergration is ready. Then we can play with dune analytics and figure out the best way to support both permits and gnosis safe transactions.