Algorand is a proof-of-stake blockchain protocol. You can build smart contracts with Algorand given its virtual machine. I chose to use Algorand because of the low cost and high speed compared to Ethereum.
For the Walker Jones Real Estate Exchange (WJE) I needed a tool that would allow me to issue fractional shares of real estate. When a new building is added to the exchange we create 100,000 shares of that building with the Algorand Standard Asset.
Algorand Standard Asset
Algorand has a primitive called the Algorand standard asset (ASA). You can read more about the ASA here. ASAs are smart contacts built on top of the Algorand network. Once you create your assets you can do interesting things like transfer them to other addresses, freeze, revoke or destroy them. These primitives allow developers to build complex apps on the Algorand network.
Check out the app’s github repo for installation and how-to: Installation and how it works.
Here are a few issues I had with the development. Knowing these gotchas will hopefully save you some development time.
1. Transferring funds into a newly created account
After you create an account (address), the address won’t be “known” by the network until you transfer algos to the address. Addresses must also have a minimum balance (100,000 micoAlgos) to participate in a transaction.
For accounts on testnet, you can use an algorand dispenser to dispense algo into a newly minted account. Most of the dispensers are behind a captcha so you can’t do this programmatically. In production, you can send algos from an admin address to a newly minted address to “activate” it.
2. Difference between Indexer and algoclient
This should be obvious for those who read api documentation closely. I didn’t and this tripped me up.
You can think of the indexer as “read” access to the network. You can pull down info from the Algorand network about addresses, assets, transactions, etc.
The algoclient (known as Algodv2 in Purestake) does all the rest — sign transactions, send them to the network, etc.
Indexer for read, algoclient for write — that’s how I kept track of the difference.
3. Opting into an assets before receiving
The error messages aren’t the best yet. Algorand was created in 2017. This stuff is new.
I tried to send an asset to a newly minted account. First it failed because I didn’t fund the account. Then I was stuck…why is this still failing? You need to opt-in to receive assets.
You do this by “transferring” zero assets (using the asset id) from the recipient to the recipient. I wrote a little helper function,
assetTransferOptIn(account, assetId) to do this prior to initiating the transfer.
4. Custodial vs non-custodial accounts
This isn’t specific to Algorand but something I had to think a lot about. Here is some background about custodial vs non-custodial accounts.
You need access to either the account secret key or mnemonic to initiate a transaction. With custodial accounts the app stores these credentials and initiates the transaction for the user. The user will therefore need to be authenticated via traditional login functionality. Once logged in they can trigger a transaction that will use the user’s secret key or mnemonic to sign the transaction.
The example web app uses a custodial approach. The mnemonics are stored in the
db.json file on the server. This file is stored in the git history on Github and is therefore public. This is fine for the example app but you would NEVER do this in production. Access to the mnemonics gives anyone access to the accounts and therefore all the assets.
You’d be much more careful with a custodial approach in production. The mnemonics would likely be stored in an encrypted db and would never be sent over the wire (ie to the frontend).
I’m new to working with Algorand and the Purestake api. Please let me know if any of this is incorrect or could have a better implementation. Happy to accept contributions/edits/issues on the Github repo.