A lot of the gateway structs are have optional keys, i.e. when no value is present, the key is not returned. Throughout the types, they have been generated as returning the value, or null. They should instead return the value or undefined.

A good example of this is the AddressEx (struct can be found here). If there is no name or logoUri, the keys are not returned. This has caused a lot of issues when using the types, requiring some fallbacks that aren't necessary. useKnownAddress is a good example.

This is likely an SDK-wide issue. I'm not sure what we used for type generation, if we did, but it may be worthwhile looking into ts-rs.

Make a test that imports the SDK types just to test that they are exported correctly.

Returns chain configs.

• https://safe-client.staging.gnosisdev.com/v1/chains – all chains
• https://safe-client.staging.gnosisdev.com/v1/chains/4 – individual chain details

Overview

Currently the web app is using the config service directly to fetch the Safe Apps list. This is the only dependency that we still have with the config service directly. Currently the client gateway already exposes the Safe Apps list endpoint so we can just rely also in the gateway to handle this

https://gnosis.github.io/safe-client-gateway/docs/routes/safe_apps/routes/index.html

Goals

• Add the safe apps list route to the gateway-sdk
• Use this version of the gateway-sdk to fetch the safe apps list
• Remove the dependency with config service in web app

Change the types of base_gas and safe_tx_gas in the MultisigExecutionDetails to String

See the backend ticket: 5afe/safe-client-gateway#543

The CGW adds SetGuard and DeleteGuard variants to SettingsInfo. We should extend the SettingsInfo object accordingly.

Gateway is now proxying/caching the tx-service endpoint that gets the safes you own.
We need to add this endpoint to the SDK and replace the call in safe-react.

It was previously on tx-service, now moved to the gateway.

https://gnosis.github.io/safe-client-gateway/docs/routes/utils/fn.post_safe_gas_estimation.html

SDK reference URLs in readme don't work.

• Use https://github.com/reviewdog/action-eslint for ESLint.
• Try https://github.com/mattallty/jest-github-action for the unit tests.

The tests were originally written in plain JS for the sake of speed. It would be probably good to add some type safety there.

Need to publish the package in the new organization on NPM.

Since the service was migrated to Node.js, the documentation that was available under https://safe.global/safe-client-gateway ceased to exist.

The documentation that was available there was generated by Rust's doc tool. Since this no longer applies to the new project an alternative needs to be considered.

As for what is available right now: Swagger already provides the types being used on each endpoint as well as the respective structure. The OpenAPI specification in JSON format can be found under: https://safe-client.safe.global/-json

For avoiding issues like safe-global/safe-apps-sdk#292 we would like to review the build system and use something more simpler with no webpack configuration as for example let typescript compiler create the files.

Same approach as in the https://github.com/gnosis/safe-apps-sdk

The new "unified" API puts the chainId into the path (it used to be a network name in the host).
We need to migrate to this new format.

E.g. instead of this URL

https://safe-client.{network}.gnosis.io/v1 + /safes/{address}/

the new URL will look like this:

https://safe-client.gnosis.io/v1 + /{chainId}/safes/{address}/

Requirements

Each path should start with a {chainId} parameter.

There's a library expect-type which allows making assertions against TS types.

So we could do stuff like this:

expectTypeOf(await getSafeInfo()).toMatchTypeOf<SafeInfoResponse>

What is the feature about

Implementation of EIP-1271 endpoints.

The list of requirements

• Add GET/POST endpoints
• Migrate types from frontend

Links

• Problem statement/data structure