Fix bad links.
@@ -9,7 +9,7 @@ Rekeying is a powerful protocol feature which enables an Algorand account holder
### Account Review
-The [account overview](/features/accounts/#keys-and-addresses) page introduces _keys_, _addresses_ and _accounts_. During initial account generation, a public key and corresponding private spending key are created and used to derive the Algorand address. This public address is commonly displayed within wallet software and remains static for each account. When you receive Algos or other assets, they will be sent to your public Algorand address. When you send from your account, the transaction must be authorized using the appropriate private spending key(s).
+The [account overview](../index.md#keys-and-addresses) page introduces _keys_, _addresses_ and _accounts_. During initial account generation, a public key and corresponding private spending key are created and used to derive the Algorand address. This public address is commonly displayed within wallet software and remains static for each account. When you receive Algos or other assets, they will be sent to your public Algorand address. When you send from your account, the transaction must be authorized using the appropriate private spending key(s).
### Authorized Addresses
@@ -17,7 +17,7 @@ The _balance record_ of every account includes the "auth-addr" field which, when
Conceptually illustrated in the image below, a "standard" account uses its _private spending key_ to authorize from its _public address_. A "rekeyed" account defines the _authorized address_ which references a distinct "foreign" address and thus requires the _private spending key(s)_ thereof to authorize future transactions.
-![Accounts](/imgs/accounts.png)
+![Accounts](../../imgs/accounts.png)
#### Standard Account
@@ -139,7 +139,7 @@ The "auth-addr" may be specified within a _rekey-to transaction_ as a distinct f
The first scenario rekeys a single key account with address "A" to a distinct single key account with address "B". This requires two single key accounts at time _t0_. The result from time _t1_ is transactions for address "A" must be authorized by address "B".
-![Rekey-to Single Key Address](/imgs/rekey-single-single.png)
+![Rekey-to Single Key Address](../../imgs/rekey-single-single.png)
### Generate and Fund Accounts
@@ -235,7 +235,7 @@ This will succeed, sending the 1000 microAlgos from `$ADDR_A` to `$ADDR_B` using
The second scenario _rekeys_ a single key account with _public address_ "A" to a MultiSig address "BC_T1". This scenario reuses both Accounts "A" and "B", adds a third Account "C" and creates a MultiSig Account "BC_T1" comprised of addresses "B" and "C" with a threshold of 1. The result will be the _private spending key_ for `$ADDR_B` or `$ADDR_C` may authorize transaction from `$ADDR_A`.
-![Rekey-to MultiSig Address](/imgs/rekey-single-multisig.png)
+![Rekey-to MultiSig Address](../../imgs/rekey-single-multisig.png)
### Generate Additional Account
