So we rekeyed an address to you. Now what?

As we have rekeyed vanity addresses to many of our Algorand friends, we thought to concentrate the relevant information in one place.

How does it work?

Algorand enables exchanging addresses securely through rekeying. When we hand over a vanity address to one of our friends or customers, we rekey it to an address they control on all 3 public networks (MainNet, TestNet, BetaNet).

You will have received an email with proof of rekeying: links to the rekeying transactions on all 3 networks, as well as links to the rekeyed address AlgoScan page, which recognizes rekeyed addresses and displays the controlling address ("Authorizer".)

What is Rekeying?

"Normal" accounts have a public key, which is encoded into the friendly soup of 58 characters from A to Z and 2 to 7, and a corresponding private key, which is represented by the mnemonic seed phrase of 25 words that we all love and protect at all costs. When you want to transact on Algorand, your private key signs the transaction cryptographically, and the Algorand network checks that the transaction was signed by the correct private key.

Rekeying is a special transaction that instructs the Algorand network to change the "spending authority" of an address. A rekeying transaction has a special field rekey-to which takes an Algorand address as a value.

After that transaction is accepted by the network, the original private key (seed phrase) will no longer be accepted by the network to sign any kind of transaction for that address. Instead, the rekey-to address is now responsible for signing for the rekeyed address. This address is sometimes called Authorizer (by AlgoScan) or Authorized (by official Algorand docs).

So when we rekeyed the vanity to an address you control, we permanently relinquished control of it. You can check this by adding the vanity's seed phrase to a Pera or MyAlgo wallet that doesn't also contain your authorizer address and you'll see that it can't sign for any transactions.

This change is permanent and can only be explicitly undone by another rekeying transaction that the authorizer (you) signs, or if you close out the account by emptying its balance entirely (the authorizer reverts to the original seed phrase.)

You can read this Algorand Product Brief into Rekeying, or look up the official Algorand technical documentation on Rekeying.

"Not Your Keys" is still a great rule of thumb

This is a fairly advanced feature of a very advanced blockchain. If you are certain it has been performed as described in this post, you can trust that only you control the rekeyed address. Generally you shouldn't use addresses generated by other people, as they will usually be able to control it as well. But with rekeying we can prove, and you can verify, that this is not the case.

Putting our money where our mouth is

Here's a concrete example. We have rekeyed this vanity address to dthirteen.algo:

https://algoscan.app/address/FREEELZPCZTEAF2VTCEG2STA3AL5OS7ZNCASVU6MWB6PZKGABRTQNMONEY

This account has about 99.9 ALGO in it. Here is the seed phrase for it:

tongue holiday slender chicken board above draw puzzle boss never hawk worry arch bubble wine enough motor easy soap cotton owner burden major abandon ankle

And here is the seed phrase in QR form for convenience. You can scan it with Pera in order to experiment with it yourself.

Since this account has been rekeyed, the seed phrase is only good for adding it to Pera or MyAlgo, and nothing else. You won't be able to sign for any transactions using it. We invite you to try!

Usability

Rekeyed addresses are well supported within the Algorand ecosystem, but there are a few caveats.

For wallets, a pre-requisite is to have both the rekeyed address and the authorizer address in the same wallet.

MyAlgo

MyAlgo supports dApp transactions for rekeyed addresses. When you connect a dApp you must select both the authorizer address and the rekeyed address, otherwise you will see an error like "The website is requesting to sign transactions with a wallet that you did not grant it access to."

MyAlgo doesn't support actions initiated from MyAlgo itself, like sending ALGO or opting in or out of assets.

Pera

Pera used to have first-class support for rekeyed addresses, but a recent regression has limited asset management initiated from the App. The account page of soft-rekeyed accounts (i.e. not Ledger) now displays as a "Watch" account, meaning you can't manage assets.

You can still use dApps with Pera Connect and send ALGO from the home page SEND button.

If you are affected by this you can vote up in this feature request we opened.

Trouble-shooting Rekeyed addresses

• To log in to a dApp with MyAlgo, you need to select both the authorizer address and the rekeyed address, otherwise you may get an error about the dApp asking to sign with an address you didn't authorize. It (reasonably) wants authorization for both the rekeyed and the authorizer addresses. If you are unable to select both at once, log in with each one individually (you should only need to do this once.)
• Pera has recently regressed and no longer offers first class support for soft-rekeyed addresses as outlined in the section above.
• If you can't sign transactions on Pera, check that Bluetooth and Location services are allowed and enabled. (We assume that the code path for rekeyed transactions assumes a ledger is involved, which requires these permissions.)
• This shouldn't be applicable to you, but Pera wallet can get confused if an address is rekeyed on one network (e.g. MainNet) but not another, and display "Rekeyed address" on the network where the address is actually self-sovereign. Removing and re-adding the account fixes this. If you encounter this on an address we rekeyed to you, please let us know.