0

Code that works on ethereum mainnet/rinkeby and up until recently worked on goerli doesn't work on goerli anymore.

The code in question is proposing a Gnosis-Safe transaction using

@gnosis.pm/safe-core-sdk: ^2.1.0,
@gnosis.pm/safe-ethers-lib: ^1.1.0,
@gnosis.pm/safe-service-client: ^1.1.2,

Up until these 3 steps including, everything looks dandy

const safeTransaction = await safeSdk.createTransaction(safeTransactionData);
await safeSdk.signTransaction(safeTransaction);
const safeTxHash = await safeSdk.getTransactionHash(safeTransaction);

and we have a valid looking Gnosis Safe transaction hash (safeTxHash)

I would have expected, as per the code, that the next step will fail on any issues.

await serviceSdk.proposeTransaction(transactionConfig);

Comments in code SafeServiceClient

    /**
     * Creates a new multi-signature transaction with its confirmations and stores it in the Safe Transaction Service.
     *
     * @param proposeTransactionConfig - The configuration of the proposed transaction
     * @returns The hash of the Safe transaction proposed
     * @throws "Invalid Safe address"
     * @throws "Invalid safeTxHash"
     * @throws "Invalid data"
     * @throws "Invalid ethereum address/User is not an owner/Invalid signature/Nonce already executed/Sender is not an owner"
     */
    proposeTransaction({ safeAddress, senderAddress, safeTransaction, safeTxHash, origin }: ProposeTransactionProps): Promise<void>;

But it executes without fail. However, The transaction cannot be found in the website's queue, nor can it be retrieved via safeClient.getTransaction. it was never created as far as I can see.

Is that a gnosis/goerli regression? obsolete libraries? other? Up until a couple of days ago(12/10/22) same code functioned as expected.

(edit) The misbehavior is reproducible by wonderland's gnosis-safe-proposer

3
  • 1
    could you please share the safe address and the transaction hash?
    – mikheevm
    Oct 17, 2022 at 8:37
  • @mikheevm safe is0x37918D4DAD5dE0af86753eDFCd83CBDD04c49712 I created a second one just to make sure it's not the safe 0x7C114e9013124DE655f4922C0213bFfc96AEf42c but got the same behavior . The last transaction hash for the first safe is 0x3a5d652bf0fe1a30a433afeca0de8c901f93aa3a0d88ecc689c28a37df2612b8 The last transaction hash for the 2nd safe is 0xaaf7c54e08294d1dfd5b62182ecf6c2259801d4400a7acf74e2ab2f72cfee0fd Oct 17, 2022 at 8:52
  • The problem is very likely due to requests to https://safe-transaction.goerli.gnosis.io while the most updated goerli(?) runs on https://safe-transaction-goerli.safe.global/ Oct 17, 2022 at 13:00

2 Answers 2

2

The API URL https://safe-transaction.goerli.gnosis.io is not fully functional the correct URL to use is https://safe-transaction-goerli.safe.global

I found it using the safe-client-gateway API

$ curl https://safe-client.gnosis.io/v1/chains/5/about
{ 
 "transactionServiceBaseUri":"https://safe-transaction-goerli.safe.global/",
 "name":"safe-client-gateway",
 "version":"3.36.0",
 "buildNumber":"2953"
}

Once I realized the correct API URL I found the full OpenAPI specifications.

It will be helpful if someone can drop a comment with the official location where such information is formally distributed.

2

We landed on the same solution (as OP)! The official information is here: https://forum.gnosis-safe.io/t/transaction-service-migration-october-2022/1550 which we found via the gnosis UI at https://gnosis-safe.io/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.