ARC-01 — Building a Token Standard Proposal on Algorand

This is part one of a series of articles related to building hybrid tokens on the Algorand blockchain.

With the successful launch of Algorand’s main net and inaugural auction this week, those of us here at AssetBlock are already seeing some fantastic indicators of the staying power of the platform.

Leading up to the launch, I’ve been lucky enough to meet many of the Algorand team members as well as some of the platform’s early adopters at Boston Blockchain Week and other Algorand-focused meetups. The Algoers I met (that’s a term I just made up for Algorand developers, mind you) pointed out something lacking that almost everyone brought up a need for: tokenization.

The Call For a Token Standard

Whether you are offering real estate investment opportunities, managing a supply chain, controlling intellectual property, or even breeding cute cartoon cats, the need for tokenization becomes readily apparent as soon as you have an asset you need to track, manage or trade. Wallet providers, analysts, and data aggregators alike all benefit from having a standard to build their products around; generally improving the developer and user experience of the blockchain as a whole.

After reading Evan Richard’s excellent article about building L2 applications on Algorand, we wanted to try our hand at creating a token standard driven and owned by the community. If we lean into utilizing the unique strengths and features of Algorand’s transaction model, could we create a versatile standard that could work for the simplest utility token transactions while also expanding to accommodate more advanced use cases like security tokens?

Of course, after sharing our ideas with the talented and passionate members from the Algorand community, what started off as a simple proposal turned into a multi-layered schema-driven approach to multiple token types, compliance profiles, and validation (oh my!).

Today we’re introducing the ARC-01 proposal to the world so we can gather even more feedback from the community at large. But first, let’s talk a bit about why we made the choices we did, and why we’re excited about the future of Algorand.

The Case for Centralized Token Management

Algorand is raising the bar with their decentralized permission-less pure proof-of-stake protocol, with top notch performance and scalability. If you believe in the protocol (and why wouldn’t you? Seriously, read Silvio’s summary of their core technology and be amazed) you’ll agree that there’s nothing quite like it out there today.

While Algorand is truly decentralized and permission-less, there are many regulatory bodies that struggle with the implications of decentralization as it pertains to investor identity and compliance. For the U.S. in particular, the current state of security laws make it very challenging (if not impossible) to have a truly decentralized asset class without some additional legislation built to support it. As the world slowly adapts to new blockchain paradigms, this creates a difficult balancing act for investors and investment providers alike — how do we weigh the rights of individual investors to control their personal data against the needs of regulatory bodies to have some guarantee that investors are who they say they are?

Security Tokens and an Economy of Choice

In addition to a basic token standard proposal, ARC-01 outlines a security token workflow that requires issuers of security tokens to identify at least one compliance provider who will control token distributions and investor accreditation. We’ll provide more details on security tokens and compliance in a future article in this series, but for now the broad outline works like this:

• The issuer sends a genesis transaction naming the token details, at least one compliance manager (if an issuer wants to manage her own compliance, this could be an address in her control), and a transaction id on the chain containing a human-readable specification about the compliance profile her token will adhere to.
• Token transfers will be handled via a request/approve/deny model, with the compliance manager responsible for approving or denying any redistribution requests, ensuring that the parties involved adhere to the compliance rules set forth by the token’s compliance profile.

This allows an interesting dynamic moving forward — compliance providers could work directly with identity services or users themselves, posting encrypted compliance certifications directly on the chain for any investment house or regulatory body to see, without exposing any sensitive investor information on-chain. We believe this approach is critical to empowering investors with a choice — who to trust with their financial profile and personal data, without the need to share it with multiple investment firms with traditionally lacking security protocols.

In an ideal scenario, this could even allow users to choose the compliance provider with the security policies and offerings they trust the most, sharing their data only once and updating their compliance in one place instead of several. This concept is built on one core idea — providing an economy of choice in compliance and identity solutions for individual investors is the best way to start approaching decentralization for securities in a borderless economy.

While this is aspirational, there are some pretty compelling checkmarks in the pro column for everyone involved in the investment process:

• Investors would only need to share their data with one trusted party of their choosing, and handle accreditation renewals in one place. Gone are the days where you’d need to separately go through AML/KYC/Accredited Investor, etc. checks on multiple investment platforms with variable security policies and risk profiles.
• Token issuers would not necessarily be on the hook for building secure infrastructure to store and track sensitive investor data, reducing their attack surface and operational overhead.
• Compliance managers would benefit from specifications that are easy to update and version, with the ability to focus solely on security, privacy, and serving both parties by implementing far more efficient and secure processes than are used today.

What About Smart Contracts?

For starters, smart contracts have some well-documented limitations and security flaws in other ecosystems. Algorand has already mentioned that they are working on an answer for a processing layer similar to smart contracts on their platform, but I for one am glad that they’re taking the time to innovate and avoid past mistakes in their design methodology, just as they have for scalability and security in the core design of their protocol.

Furthermore, any kind of smart contract would simply reduce some overhead on the compliance provider’s part here, removing some of the more manual tasks that might be required in the early days of a proposal like this. Still, smart contract functionality would not negate the need for users to share and update their financial information on a regular basis with a trusted third-party to adhere to the strict regulatory needs of many institutions today.

Next steps for the ARC-01 Proposal

It’s been amazing for me to have the honor of firing the starting gun for this particular relay race, but the proposal will never succeed without ongoing feedback and support from the community passing the baton around. We know that there are experts out there already trying to solve many of the regulatory and operational challenges that come with creating layer 2 applications on the blockchain, and we’re welcoming as many as possible to help us improve the proposal we have today.

We’re looking forward to your feedback, so please check out the github repository for usage guidelines, schemas, and documentation, or download the arc-01 npm module and try it out in your own projects today.

Coming up next in this series, we’ll share more technical details about transaction payloads, the notes field, and issuing and transferring basic tokens.