Using attached transfer file, first, second and last tokens were not part of uniswap default token list so decimals column had to be included.

receiver,token_address,amount,decimals
0x7f01D9b227593E033bf8d6FC86e634d27aa85568,0x543ff227f64aa17ea132bf9886cab5db55dcaddf,3000,18
0x7f01D9b227593E033bf8d6FC86e634d27aa85568,0x8f8221afbb33998d8584a2b05749ba73c37a938a,5000,18
0x7f01D9b227593E033bf8d6FC86e634d27aa85568,0x1f573d6fb3f13d689ff844b4ce37794d79a7ff1c,100,18
0x7f01D9b227593E033bf8d6FC86e634d27aa85568,0xdd974d5c2e2928dea5f71b9825b8b646686bd200,100,18
0x7f01D9b227593E033bf8d6FC86e634d27aa85568,0x6810e776880c02933d47db1b9fc05908e5386b96,0.631565947557546711,18
0x7f01D9b227593E033bf8d6FC86e634d27aa85568,0x255aa6df07540cb5d3d297f0d0d4d84cb52bc8e6,100,18

Unfortunately, something went wrong with the transfer as seen in the linked transaction:

https://etherscan.io/tx/0x9788d5d9c660f073c6a34a5b83a759f8c42d3d29432f593fcb308a2cae780255

My guess is that 5000 * 10^18 was too big and the BigNumber got screwed.

Not sure how to best achieve this because we can't link to github readme from within the app.

Is there some way to embed a markdown file with instructions in the app page with a local reference?

Given that NFTs have now hit the scene, it shouldn't be too difficult to support NFT airdrops.

Currently the sample only works for mainnet, which causes confusion for first time users.

We should provide a dedicated sample file for each supported network.

Somehow during validation (?) the editor gets stuck and misses some inputs.
If its not easily fixable we should validate everything on blur or make the debounce time longer?

Based on Feedback here

The summary for native tokens on Xdai, Polygon & BSC shows them as ETH and I think it would be nice to provide feedback per native token

We do already have a network map with native token symbols in the code. I believe this was working in the past, but we must have accidentally removed this...

Currently the tokenList is being fetched on every(?) render which is definitely not what we want.

I would want to refactor the whole tokenList structure a bit so that everything is memoized / cached correctly.

The main page of the app should contain some link to the instructions. Perhaps converting the Markdown to HTML and storing it in the page as a local link (but this will be hard to include images). Also might not hurt to get the instructions onto docs.gnosis.io where the link wont be refused (Note that the github link was refused by the safe app for some reason).

token_address,receiver,amount,decimals
0x6b175474e89094c44da98b954eedeac495271d0f,0xDD00AB99Bff97E93AC1D0390F8e2ce41221050FE,21440,18
0x6b175474e89094c44da98b954eedeac495271d0f,0x77F6C1385eBd43ebe2B2de51C3E5d52cD4651278,19400,18

I realize the decimals column is unnecessary.

Here are the errors from the javascript console:

Missing Infura key!

Error: invalid BigNumber string (argument="value", value="2.144e+22", code=INVALID_ARGUMENT, version=bignumber/5.0.12)

GET wss://mainnet.infura.io/ws/v3/undefined

The app worked 1 month ago (albeit with ETH, not DAI)

Using firefox, metamask

is there a technical reason why it shouldnt run on any deployment of gnosis safe on any network?
why does it have to support only "official" ones?

We should configure github actions to check tests (cf #26) and linting at the very least.

Currently if we have a Token with i.e. 2 decimals and we provide 4 decimals: 0.1234 we will cut off after the second decimal and ignore the other ones.

This can lead to unexpected behaviour. Currently the UI displays all decimals (in the table for instance) and does not show the cut-off decimals.
I think this should generate a warning in the code editor and display only the decimals which are going to be submitted in the table.

Gnosis safe now supports Polygon and Binance Smart Chain: https://blog.gnosis.pm/gnosis-safe-is-live-on-layer-2-24adf83f0032

With possible minor tweaks towards the fetching of the token list, etc. it should be possible to support those networks.

The button to clear form might look like this

      <Button
            size="lg"
            color="secondary"
            onClick={() => {
              setTransferContent([]);;
            }}
          >
            Clear Form
      </Button>

But we may also need a more sophisticated file upload that allows us to re-up the same file twice.

Instead of just allowing CSV upload, this application should also allow to upload JSON files with the following example format:

[
    {
        "amount": "0.001",
        "tokenAddress": "0x4dbcdf9b62e891a7cec5a2568c3f4faf9e8abe2b",
        "receiver": "0x100000000000000000000000000000000000000"
    },
    {
        "amount": "0.002",
        "tokenAddress": "0x4dbcdf9b62e891a7cec5a2568c3f4faf9e8abe2b",
        "receiver": "0x2000000000000000000000000000000000000000"
    },
    {
        "amount": "0.003",
        "tokenAddress": "0x4dbcdf9b62e891a7cec5a2568c3f4faf9e8abe2b",
        "receiver": "0x3000000000000000000000000000000000000000"
    },
    {
        "amount": "0.004",
        "tokenAddress": "0x4dbcdf9b62e891a7cec5a2568c3f4faf9e8abe2b",
        "receiver": "0x4000000000000000000000000000000000000000"
    }
]

Hi,
Thanks for the app. I'm trying to find out how many airdrops per transaction can I send?. I have to do batch airdrops like thousands of them and you know the gas fees are high these days. Other solutions normally can do up to 150 airdrops per transaction, how much is this going to do? After I create a safe, can I batch transfer 1000s of airdrops in a single safe transaction?

I want to process transaction events but I don't have your ABI files, how can I get that?

tx example:
https://blockscout.com/xdai/mainnet/tx/0x0c452a7c116adb6162390f342cee84175f34e3c1bc0015e6f82773a54ace3061/

We could use ethers.js to find out if the string is a valid address and use the ENS as a fallback.
Should be quite easy to implement and add some usability.

Related, and possibly a better solution to, #163

on the right hand side of the app we should include a little text box with two very important FAQ facts:

1. To send ETHER leave the token_address field blank. See sample CSV file for example.
2. Please remember to leave the column headers (token_address, receiver and amount) as the first row of your CSV.

Have been getting a lot of questions/confusion about these two points from several places.

The app should be able to access the connected Safe's address book and display the names tied to each of the receiver accounts.

See https://twitter.com/SchorLukas/status/1470700682562965504?t=GmelI3U-mTjqIDyk0aJKcA&s=19

We should support this address format in all address fields and validate that the network matches the current safe network

This repository is currently missing a license file.

Upon upload of the transfer file, the table displaying transfers could/should show the token by name and icon (as in the safe's asset list).

Users have been reaching out to Gnosis Employees with a few common questions:

• What is the maximum number of addresses that tokens can be sent to in a single transaction using the CSV Airdrop app?
• In the token_address field, what address do I put if I am transferring ETH?

Perhaps it would be good to include a simple FAQ in the README. Will attempt this soon/later.

Right now we use the basic native react file upload button. It has been suggested to use something more sophisticated like https://www.npmjs.com/package/react-file-drop so that we might gain some functionality, like "clear form" for example.

Make the textbox look like this (with monospacing)
http://jedwatson.github.io/react-codemirror/

NPM package here:
https://www.npmjs.com/package/react-codemirror

Recently a user had a use case for the app where they wanted to send 130k transfers. Naturally this would never fit into a single transaction so it would make sense to break the transfer file up into smaller chunks and separate initialize transactions for each batch (i.e. transactions with incrementing nonce). Of course it would be nice to do all this directly from the interface, but it might also be nice if these kinds of airdrop could also be done from the shell (like in the good old days before this app was born).

The initial project introducing the logic for this app is here with a simple JS script that would parse csv transfer file and submit a multisend transaction to the safe interface for signing and executing.

https://github.com/gnosis/dex-liquidity-provision/blob/master/scripts/airdrop.js

As a start, it would be nice to port this old script to here. When attempting to use it we noticed that the dependencies are way outdated and so certain networks (like polygon) didn't even exist back then. That is, this script porting is expected to take a bit more effort than ripping the code out and putting it here. That and, of course, it should be written in TS instead of JS. This means we would also leave the truffle tooling behind in favour of hardhat.

According to https://eips.ethereum.org/EIPS/eip-1155#metadata the following should be true for ERC1155 contracts:

If the optional ERC1155Metadata_URI extension is included:

The ERC-165 supportsInterface function MUST return the constant value true if 0x0e89341c is passed through the interfaceID argument.

So currently we check each ERC1155 contract for this interface value and if it returns false we don't try to fetch metadata such as the token name / image of the token ID.

BUT as the real world shows. Most ERC 1155 contracts do not correctly implement ERC-165 and don't return true on the supportsInterface call. That's why we should not check for that interface anymore.

Although this may not be necessary if https://eips.ethereum.org/EIPS/eip-3074 somehow makes it possible without any code changes.

Every app needs a dark theme 💡 🌑

Currently the gnosis safe shows the React-icon as the app's icon.

We display our own icon here.

Currently the CSV file is expected to contain token decimals (to avoid making any read queries to the EVM). This is subject to user error and would be much safer if the token's decimals were recovered directly from the token data itself.

When I use the "Upload File Button" I get my finder window opening again after selecting a file, and again (the second time it actually renders the file) and again. If I cancel on the third time everything is fine, but if I select the file the third time I get this error:

Currently we use only the uniswap default token list, but we could also take the union over any number of token lists so to provide support for as many tokens as possible:

See here where they incorporate multiple token lists.

Just wanted to keep these here to make sure we include tests that ensure the app works properly with these. Decimals 0, 1, 2, 3 and 24.

{"chainId":1,"address":"0x2cad4991f62fc6fcd8ec219f37e7de52b688b75a","name":"Schain Wallet","symbol":"SCHA","decimals":0,"logoURI":"https://assets.coingecko.com/coins/images/12135/thumb/schain.png?1597462731"},

{"chainId":1,"address":"0x193408ca0576b73156ed42a2ea7d6fd3f6507162","name":"Infinity Esaham","symbol":"INFS","decimals":1,"logoURI":"https://assets.coingecko.com/coins/images/10716/thumb/WBUD9cx.png?1582524776"},

{"chainId":1,"address":"0xd2be3722b17b616c51ed9b8944a227d1ce579c24","name":"Dtube Coin","symbol":"DTUBE","decimals":2,"logoURI":"https://assets.coingecko.com/coins/images/13126/thumb/dtube_logo.png?1605500467"},

{"chainId":1,"address":"0x9235bda06b8807161b8fbb1e102cb654555b212f","name":"Feellike","symbol":"FLL","decimals":3,"logoURI":"https://assets.coingecko.com/coins/images/12075/thumb/FLL_logo_200.png?1596751266"}

{"chainId":1,"address":"0xaba8cac6866b83ae4eec97dd07ed254282f6ad8a","name":"YAM v2","symbol":"YAMV2","decimals":24,"logoURI":"https://assets.coingecko.com/coins/images/12179/thumb/YAM-v2.png?1597892396"}

This project is using node v14.x, might want to consider migrating to v17.x

https://github.com/gnosis/safe-react-apps/tree/development/apps/drain-safe

Currently we can invoke web3 to encode transfer data, but if (for example) we wanted to fetch token decimals, this would require passing an infura key to query the EVM.

This should be as easy as depending on dotenv, but doesn't appear to work as expected.

Recently we have had a user (Chrome on Windows) who cannot upload the sample file:

When dragging the file in the drop box is highlighted in red indicating that the app already knows the file will not be supported.

I can only assume that the file was somehow changed by the OS after download. We have tried manually altering the file extension to be explicitly csv. but this may have resulted in bein renamed to sample.csv.whatever_ms_added_cuz_it_sucks. It is unclear if the actual file extension was modified by the operating system (since it doesn't display file extensions in the file navigator).

Currently its hard to mock a web3provider, because we would have to mock the whole interface.
But we only need them to provide us with a contract and to give us the eth balance.
Therefore we should build interfaces, which encapsulate the huge web3provider.

hey all! when I try to use the CSV Airdrop app (which I used without issue up until the beginning of August) I get this error:

"invalid ENS name (argument="name", value=undefined, code=INVALID_ARGUMENT, version=providers/5.4.3)"
to be clear: I'm not using any ENS names just straight hexadecimal addresses

not being able to use this app anymore is a major issue actually as our DAO has many recurring payments that get made out of gnosis. any insight here?

Based on the v2 release review (safe-global/safe-apps-list#92 (comment)) we got this feature request.

I think it would be neat to either allow chain prefixes on the CSV file or ignore them when performing a drain.
As when doing so with an address with chain prefix it automatically populates the CSV with it, making it invalid:

Follow link for images.

Gnosis Safe CSV Airdrop app doesn't work on xdai 😢

network does not support ENS (operation="ENS", network="xdai", code=UNSUPPORTED_OPERATION, version=providers/5.4.0)

Even without ENS I would expect that I can send to addresses without ENS.

This project currently suffers from sever lack of unit tests. Given that the project is currently still very small, it would be a great idea to get started on this.

Some Example PRs with tests for other safe apps can be found here:

safe-global/safe-react-apps#120
safe-global/safe-react-apps#122

The test would perform something like the following steps:

1. Deploy Safe
2. Mint Tokens and fund the Safe
3. Execute a multisend of token transfers
4. Verify that recipients balances are indeed updated

Before we launch this, we should probably make sure that this app functions properly on a transfer file of size 200. Technically it should be able to handle about 240 without exceeding 50% of the block gas limit.

This transfer file should have unique recipients (for an actual real live airdrop), but doesn't need to have so many distinct tokens (say 10).

We could check that we aren't double querying the token data. Any lag that is experienced is assumed to be for the ens name resolution (which we can't really avoid). I wonder if it makes sense to include a toggle which enables or disables the ens features for larger transfer files.

Fetch the safe token balance for transfer tokens and warn if they are trying to transfer more than they have.

Currently we are only using a simple type export from this dependency TokenInfo which is not a good enough reason to pull this entire package in.

Currently, I'm not able to transfer more than amount = 999 tokens in a single transfer. This is with 18 decimals.

Attempting to transfer 1000 tokens results in an error where the transaction is not generated within the Safe.

App.tsx:127 Error: invalid BigNumber string (argument="value", value="1e+21", code=INVALID_ARGUMENT, version=bignumber/5.0.12)
    at e.value (index.ts:205)
    at e.value (index.ts:217)
    at e.value (index.ts:221)
    at Function.value (bignumber.ts:230)
    at r.value (number.js:13)
    at array.js:41
    at Array.forEach (<anonymous>)
    at H (array.js:27)
    at r.value (tuple.js:19)
    at e.value (abi-coder.js:82)

The workaround is to transfer to the same address twice in a batch -- e.g. 2 transfers of 500 for a total transfer of 1000. But that doesn't scale well to higher amounts like 10,000.

Something that came up in the recent PR to support all networks (#325) is to include some sort of banner

#325 (comment)