Example: https://safe-transaction.gnosis.io//api/v1/safes/0x71B94163b085cc2ea7432D8cC96A94989Da4FD6e/incoming-transactions/?limit=2&execution_date__lte=2020-02-20%2019:35:06

It is planned to allow Safe apps to submit transactions to the interface. As an owner of a Safe I would like to know from which service the transaction provided. For this we should add a "origin" field when sending the transaction meta to the service.

Notes:

• origin field is not part of the safe tx hash and therefore is not 100% trustworthy (maybe this should be mentioned in swagger) -> malicious owner could abuse this, but the advantages outweight this small risk
• origin field should be a string

Currently we only show incoming value transfers (e.g. ERC20 and ETH). Therefore the user currently doesn't see if a module performs a transaction via a Safe (call to execTransactionFromModule or execTransactionFromModuleReturnData).

We should expose this somehow (TBD how)

Proposed sources of mainnet verified tokens:

• https://tokens.kleros.io/tokens
• https://eidoo.io/erc20-tokens-list
• https://etherscan.io/tokens

More info: 5afe/safe#251

Currently txs are stored on the tx service without txHash, just the safeTxHash. When tx is mined and the safeTxHash is detected the tx will have the txHash stored.

This feature would allow txs to have a txHash even though they are not mined. Currently we are treating the txs with txHash as mined, so logic would need to be changed

As tracing is difficult to test, some parts of the code have not automatic testing. That should be fixed using mocking

For Safes with version >= 1.1.1 the event for failed txs has been updated to:

event ExecutionFailure(
        bytes32 txHash, uint256 payment
    );

Service must update it and process again all txs

We need that the backend supports Access-Control-Expose-Headers for etags in order to read that value within the frontend

More information about this can be read here

The following safe owns 20 safes, but only the first 10 appear here

https://safe-transaction.gnosis.io/api/v1/owners/0x583788f490a278DB2a8d6D7226264b4985f75678/

In order to display incoming ERC-721 transfers we need to adapt the transactions endpoint or have a seperate endpoint for incoming NFT transfers.

Currently we return created, transactionHash and creator, but sometimes the safe creation is done via an internal transaction (e.g. when using the secure Safe factory which triggers the normal proxy factory). For this is would be nice to also decode the details of the transaction creation:

factory address, mastercopy, setup data. In most cases this should correspond to the function parameters when calling the Proxy factory.

Factory dependent params: saltNonce

See is an extension of #65

What

It would be nice to be able to define webhooks that should be triggered when new confirmation, transactions, etc are added.

Why

Our transactions service handles quite some useful information and it would be nice if it is possible to build services around this. Webhooks would allow other services to better interact with the transactions service.

How

Add a webhooks model, so that we can add webhooks via the admin interface.
The webhooks should be triggered each time any of the following actions occur:

• When a new pending outgoing transaction is added to the database
• When a new confirmation is added to the database
• When a new executed outgoing transaction is added to the database
• When a new incoming transaction is added to the database
• TBD

Now POST of confirmations accept signature as an hexadecimal. If signature is provided, transactionHash are not required.

Then GET will return confirmations and they will have a field signature

What is needed?

Return safe tx hash like in relay service with get request

Why is it needed?
On the frontend we need something unique to distinguish transactions

When is it needed?
The faster the better 🙈

Paul reported via Telegram that their Safe (https://gnosis-safe.io/safes/0x71B94163b085cc2ea7432D8cC96A94989Da4FD6e/transactions) shows the tx with nonce 18 as pending even though Etherscan shows it as successful.

https://safe-transaction.gnosis.io/api/v1/safes/0x71B94163b085cc2ea7432D8cC96A94989Da4FD6e%2F/transactions/ returns it twice:

• Once with 1 confirmation and pending
• Once with 2 confirmation and successful.

Why is that? Why isn't the backend able to connect both txs?
That might confuse the frontend.

Currently there is not good indicator if a Safe transaction was successful or failed. The backend should return this with the list of transactions.

Currently it is possible to retrieve pending transactions for any Safe. It should only be possible for owners to retrieve these information.

Open questions:

• Do users care?
• How to we perform authentication?
• Can non-owners be authenticated?

Proposal

• Sorting
  • The endpoint should only show outgoing transactions where the nonce < currentSafe nonce
  • The endpoint should only show incoming transactions that have been mined
  • The transactions should be sorted by execution date. If an outgoing transaction doesn't have an execution date the execution date of the transaction with the same nonce that has been executed should be taken.
• Transaction types
  • Ethereum transaction - These are transactions that have not been triggered by the requested Safe
  • Safe transaction - These are internal transactions that have been triggered by the requested Safe
  • Module transaction - These are internal transactions that have been triggered via the requested Safe by a Safe module
• Transfers triggered by Safe transactions
  • Transfers should be nested into the transaction type (see above) that triggered them. If it is unknown how this transfer was triggered it should fallback to an Ethereum transaction

Currently just on chain contract signatures are supported.

• Service should parse EIP1271 signatures in Gnosis Safe format.✔️
• Service should allow EIP1271 without Gnosis Safe format (contractAddress, messageHash and signature), even if service returns it using Gnosis Safe format❌
• When returning all the signatures, signature must be crafted depending on the other signatures so the pointer to the dynamic part matches.❌

5afe/safe-relay-service#122

Control this issue somehow https://github.com/openethereum/openethereum/issues/10325

Create endpoint to retrieve information of a safe transaction

Allow an owner to appoint delegate addresses that can propose transactions to the service without confirmations (perform a POST with transaction meta).

This would allow us to improve interaction with dapps by providing sdks or an chrome extension or mobile apps to propose transactions.

Notes:

• ANY owner should be able to add an delegate (backend should probably remember which owner did this) that is annotated with a label
• ANY owner should be able to remove ANY delegate
• ANY owner should be able to retrieve a list of all delegates and their label

See Epic for details: 5afe/safe#16

Reference: 5afe/safe-react#354

Add field count_unique_nonce to the /transactions/ endpoint

Currently you have to specify a Safe for which you want to receive a webhook call. It should be possible to specify that you want to receive for all Safes a webhook call.

Code to change

https://github.com/gnosis/safe-transaction-service/blob/master/safe_transaction_service/history/tasks.py#L201

We want to display additional information about the Safe creation transaction:

• Creation date/time
• Tx hash of Safe creation transaction
• Initiator of Safe creation

We need an endpoint that provides this information for a given Safe address

Related to 5afe/safe-react#554

Not sure if this is the right place, but here's a bug/issue:

• https://etherscan.io/address/0xFB1d445c27A860bb6330453Bf08254198F3E0E31 has a cDAI balance of >0

• https://safe-transaction.mainnet.staging.gnosisdev.com/api/v1/safes/0xFB1d445c27A860bb6330453Bf08254198F3E0E31/balances/?limit=300 doesn't return cDAI

• Incoming txs endpoint should have the option to display outgoing transfers too

See 5afe/safe-react#517 for details.

Create a new filter for transactions/ endpoint to filter transactions modified after/before a timestamp:

• modified__lt
• modified__gt
• modified__gte
• modified__lte

It will allow ISO 8601 datetimes like:

• 2020-02-27T10:46:15Z
• 2020-02-27T10:46:15+00:00
• 2020-02-27 10:46:15Z

Backend needs to be adjusted to update modified on transactions when a new confirmation is added to the database.

• We are planning on improving the recovery flow (safe#180).
• As part this, we would like to remove the step where a user has to enter the Safe address.
• Therefore we need an endpoint where the apps can retrieve Safe addresses for a given owner address.

Service is returning balance for every ERC20 token detected for a Safe address, even for the scammy tokens.

• Add flags spam and trusted flag to tokens endpoint to filter with a boolean by these values.
• Add spam field to token model to mark a token a spam token.
• Add access for product managers to have the possibilty to mark tokens as spam tokens.

Depends on #37

Return some basic information of the token in /balance/ endpoints:

• Name
• Symbol
• Decimals
• Picture if available

Currently the confirmations are matched with the multisig txs just using the SafeTxHash. It could happen that a confirmation from one "fake" Safe matches to another Safe transaction. It's not probable but it should be be addressed.

First would be blocking all non trusted master copies of the Safe contract

What is needed?

If you execute transaction for .removeOwner method with the owner account it is going to remove, the service will return 422 status code when trying to POST execution tx. (I guess replaceOwner is affected too)

Since we don't do optimistic updates on the frontend, we send a POST request to the service only when TX is confirmed, because there are too much possible failures: tx failed, user rejected tx, etc, we need some workaround for this.

Why is it needed?

So the frontend can know if the TX is executed.

When is it needed?

We need this for v0.1.0 to function properly. I'd say we need this as soon as possible, but let's decide it collectively.

Screenshot with the request:

Endpoint to return balance of tokens (and eth)

URL

GET /api/v1/safes/<str:address>/balances/

Response

It will return the following for tokens with value > 0:

[{"tokenAddress": "<address>", 
  "balance": "<int>"
 },
 {"tokenAddress": "<address>", 
  "balance": "<int>"
 }
]

Ether balance is always returned with tokenAddress: null, even if balance == 0

If I try to send a get request to fetch the transactions list, I got an CORS error because Access-Control-Allow-Headers is missing in preflight response.

I think it should be fixed just adding on the response headers
Access-Control-Allow-Headers

Balance endpoint is showing all available tokens for an address, even the scammy ones. A trusted list is desired

It would be nice to display some information about a transaction once it has been executed:

• Confirmation required on time of execution.
• Confirmation used on-chain to execute the transaction.
• Fees paid to execute the transaction and receiver of the fees (if applicable)
• ...

Currently we deploy whenever required (same for reindexing etc). This might interrupt the users and prevent the usage of the web interface.

We should make a plan when we deploy and chose a reasonable timeframe for the deployment (or other maintenance work).
This timeframe depends on:

• How long does the change take
• How does it influence the user
• How critical is the change

Another option is to provide mirror services that can be used during the update.
Also it would be good to announce bigger chances / maintenance work via telegram (and/or twitter)

Long term it would be interesting if we want to have something like https://status.github.com for our services.

It would be good to provide a guide to developer how to use the transaction service

• Add transction for a Safe
• Retrieve transactions for a Safe

Endpoint to return incoming txs with eth and tokens

URL

GET /api/v1/safes/<str:address>/incoming-transactions/

Response

Paginated json with:

[
{
      "transactionHash": "0x412c19413503174f1497d23a4e2412238610cf52cc0ccc414eae681ad6d2e7e6",
      "to": "0xAB080c90D99095FfAc2AdAc5405e93C4517A0b6D",
      "value": 1000000000000000000,
      "tokenAddress": "0x62f25065BA60CA3A2044344955A3B2530e355111",
      "from": "0x5aC255889882aCd3da2aA939679E3f3d4cea221e"
    },
    {
      "transactionHash": "0xd0ba226d438e37b64f11d088302cbdac78fa6d515d4d3847ed8c16c7cb3632d8",
      "to": "0xAB080c90D99095FfAc2AdAc5405e93C4517A0b6D",
      "value": 1240000000000000,
      "tokenAddress": null,
      "from": "0xAB080c90D99095FfAc2AdAc5405e93C4517A0b6D"
    },
    {
      "transactionHash": "0xdf06ff513ee187e9228f658a272c7054b4e0cc6bfe7e3aab9d2ca19d786155eb",
      "to": "0xAB080c90D99095FfAc2AdAc5405e93C4517A0b6D",
      "value": 5000000000000000,
      "tokenAddress": null,
      "from": "0xAB080c90D99095FfAc2AdAc5405e93C4517A0b6D"
    },
    {
      "transactionHash": "0x80e80c65a5b62029b332a549c11f25a36a11a9a61fddda7eef654723cbf298a6",
      "to": "0xAB080c90D99095FfAc2AdAc5405e93C4517A0b6D",
      "value": 10000000000000000,
      "tokenAddress": null,
      "from": "0x5aC255889882aCd3da2aA939679E3f3d4cea221e"
    }
]

Ether transfers have tokenAddress: null

Allow query parameters to filter tx:

• above or under nonce
• executed

Documentation to easily set up a custom relay is needed. Readthedocs and github README would be good places to have it updated

Maybe some refactor to the code would also be needed to allow an easy set up

• contracts are required on xDai chain
  • ProxyFactory and MasterCopy should be on the same address as on other networks
• xDai tracing node
• xDai transaction service