How does Burner wallet's 'Send to Link' work?

On inspection, user sends xDai to the contract pool with the address: 0x9971B0E163795c49cAF5DefF06C271fCd8f3Ebe9
And a link is generated with scheme as:<long characters>;<long characters>
Which will be shared with the people.
The people who visit the link will be asked to sign the upcoming txn 0 gas used and amount is claimed to their xDai account.

  1. How does this relay hub works?
  2. How to create<long characters>;<long characters> for other usecases without involving burner wallet?

@austintgriffith please clarify how it works when you have time

@elviric It’s correct to say that the link is composed of 2 parts.<FUND_ID>;<PRIVATE_KEY>

The FUND_ID is a bytes32 random hex string. This is only used as the fund identifier.
Every fund is a data structure that contains the info for the transfer. I’ll just cover 4 fields for now. The sender, signer , token and amount.

The sender creates the fund and sends the correct value to the contract.
The signer is the most important part in this functionality. It is derived from the second part of the link <PRIVATE_KEY>. This private key is used by the sender to create the fund and sign the transaction data . It’s then passed in the link to anyone that would like to claim it.
We pass the PRIVATE_KEY because the claimer/receiver address is unknown at the moment that the sender creates the fund. When the claimer/receiver gets it, she will use the PRIVATE_KEY to sign the transaction data and demonstrate that has the right to claim the fund by confirming that is the same signer.

As of the latest upgrade we can also send ERC20 tokens by link. (This is work in progress in the Burner Wallet UI so it is only enabled at contract level). Because of this you’ll see a token field in the fund. This token address is the selector that let us identify if the fund received xDai or an ERC20 token. Address 0x000… is the selector for xDai, any other address in this field is the value for the ERC20 token contract.

In order to use it in another project, you’ll need to emulate the same random FUND_IDs generation functionality and generate random PRIVATE_KEYs to use as signers. Up to now the functionality is not modular so it is part of the Burner Wallet’s DNA. You could use the smart contracts from the Send with Link feature (Link and Vault). Those 2 SCs handle the back-end functionality.
You’ll also need to create a claim functionality that gets the FUND_ID and PRIVATE_KEY from the link and signs the transaction data. It will then call the claim function in the Links contract.

This is the basic way to do an on-chain transaction. For the RelayHub case I’ll let TabooKey Team to explain it. It will be quite similar but the javascript claim function will differ and it adds some lines of code into the SC code in order to use the relays.


@riusricardo This is very insightful! thanks for enlightening and sharing the codebase! :pray:


Transferring xDAI or ERC20 tokens via Burner Wallet link consists of two logical steps: sending money “to the link” and recipient claiming money “from the link”. Let me explain the second step in greater detail.

Part 1. Sending - short summary.

Normally, you would need to know the destination Ethereum address in order to make a transaction. But in our case, the recipient likely does not even have an address in the time of sending. So, the money is sent to the “Links” custody contract’s “send” method. See this method signature:

function send(bytes32 _id, bytes memory _signature, address _token, uint256 _amount, uint256 _expirationDays)

The first query parameter you see in the link is the “_id” parameter, and it is simply a random number generated by a Burner Wallet.
The second query parameter is a one-time Private Key of the account that was used to create the “signature”. As far as I understand, having this one-time key pair prevents someone from claiming all the links as they are created by observing the deployed Links contract address. Arguably, you could just transfer the money to that account if you chose to sacrifice the expiration feature and maybe some other things.

Part 2. Claiming.

Now that the funds sit safely inside the “Links” contract, and the link itself is delivered to the recipient (i.e. on paper, via Telegram), somebody needs to make a transaction to the “claim” method of the contract to withdraw them. This is a blockchain transaction and therefore requires a gas fee. In case the recipient possess an account with enough xDAI to make a transaction, there is nothing new: he makes a call to the “claim” itself, using the received one-time Private Key to sign this claim. The contract validates the signature and transfers the funds.

But what happens if the recipient does not have any xDAI? In that case, somebody else will have to make a transaction for him. You could ask a friend to do that, but the real solution recently added to the Burner Wallet is to use the “Gas Station Network” defined in EIP-1613.
You should read about it in this great tutorial:
The basic idea is that the Relay Hub is a smart contract that keeps track of all the relays in the network. Relays in this context are HTTP servers that agree to perform transactions on the blockchain for other people and get reimbursed for the incurred gas fees by the smart contracts instead of the transactions senders.
So, the recipient will sign the claim transaction, but instead of broadcasting it to the blockchain, it selects a URL of a relay from the Relay Hub and sends an HTTP request to it. If the relay does it’s job correctly, the request returns a wrapped Ethereum transaction signed (and, therefore, paid for) by the relay itself.
The client than broadcasts this transaction on chain, and receives the funds from the claim.
Let me stress that “Gas Station Network” is not tailor-made for the Burner wallet and is a project to decentralize relay services that can be used by anybody.


@alex-forshtat-tbk I agree with the point about simplifying the functionality by sending the xDai or tokens directly to the public address related to the private key.
Removing the expiration will be equivalent to work with an EOA. So it is a valid assumption. This was part of the discussions at the beginning but the idea was to add more features that will require a smart contract.
As an example, there’s another idea on the table about sending ERC721 tokens using the same signer (private key). This will allow us to post a QR code on Twitter, group chat, etc… and allow many NFT (ER721) transfers using the same QR code. Up to now it can only be claimed once but this will enhance the functionality by letting different people to get an NFT from the same QR code.


You can do whatever your preferred with your own contract, claim once, twice, unlimited times.
Checkout an example of spawnable contract.

With Peter’s tool, you can create those links for people to claim