XBallot: Advancing DAO Management on Algorand

XBallot: Advancing DAO Management on Algorand

Building on Algorand, we’ve developed XBallot, a cutting-edge platform that’s breaking barriers in Decentralized Autonomous Organizations (DAO) management. We’ve harnessed Algorand’s fast, secure, and reliable technology to deliver a DAO-management platform that’s unparalleled in its ability to maximize on-chain data storage.

In this protocol overview, we will delve into the technical challenges we encountered while building XBallot and how we overcame them. Our primary objective was to develop a comprehensive DAO-management platform with maximum on-chain data storage. However, due to the limited capacity for storing and accessing data efficiently on Algorand, especially for larger amounts of data, we made use of IPFS (InterPlanetary File System) via Infura to store lengthy data while storing its hash on the Algorand blockchain.

Objective: Building a Full-Featured DAO-Management Platform

Our objective was clear: to create a DAO-management platform that leverages the benefits of on-chain data storage. By ensuring that everything, or mostly everything, is stored on-chain, participants, particularly those holding a unique ED25519 secret key identical to Algorand’s, gain complete control over their data. This approach provides an exceptional level of security, as tech stacks relying on backends can be vulnerable to spoofing or hacking, and backends often collect vast amounts of privacy-compromising information about their users.

Moreover, storing as much information as possible on-chain presents an excellent opportunity to showcase the speed and reliability of Algorand’s technology. Among the numerous blockchains available, Algorand stands out for its exceptional performance. XBallot serves as a platform to demonstrate the remarkable capabilities of Algorand.

Building a platform with extensive customization and extensibility options posed additional challenges. We had to re-evaluate the fundamental aspects of data writing, indexing, and access to meet the unique requirements of XBallot. In the following sections, we will explore the various XBallot Indexer endpoints and explain their significance in realizing the vision of XBallot.

Before we proceed, it is crucial to note that the core protocol, excluding the registration step and some additional rules, can be implemented client-side. The entire voting and post history can be reconstructed directly from the blockchain. The role of the indexer is to monitor the blockchain, extract relevant data, and store it to enhance loading times for clients who choose to utilize this feature. It’s important to highlight that the indexer endpoints exclusively respond to GET requests and do not handle POST requests. The indexer acts as an observer, organizing data and delivering filtered results to requesters.

XBallot Indexer: Enhancing Access to On-Chain Data

The XBallot Indexer played a crucial role in transforming our vision for XBallot into a reality. This sophisticated tool operates in real time, continuously monitoring the blockchain and storing important data. By leveraging the XBallot Indexer, clients benefit from significantly improved load times when accessing relevant information. The indexer operates on a ‘get request’ basis, seamlessly organizing and delivering filtered data results upon request.

The XBallot Indexer serves as an integral component of our mission to enhance the accessibility and efficiency of on-chain data for XBallot users. Through innovative approaches to data writing, indexing, and access, we have successfully overcome the complexities typically associated with these processes.

To explore the functionalities and capabilities of the XBallot Indexer, we encourage you to visit the XBallot Indexer Swagger Docs.

Domains: The Foundation of XBallot Entities

At the core of our solution lies the concept of ‘Domains.’ These unique identifiers represent individuals or organizations and are approved and published by the XBallot domain registrar. A domain encompasses two essential components:

  1. On-chain Application: Users create on-chain applications that store crucial information about the domain and its associated voting sessions in the global state.

  2. Non-fungible ASA: The registrar mints and transfers a non-fungible Algorand Standard Asset (ASA) to the purchaser. This ASA ensures visibility on the frontend and provides support for the indexer.

Domains serve as the foundation for XBallot entities, offering a robust user identification system that significantly enhances the functionality of our platform. To learn more about Domains, please visit the Domains endpoint.

Domain Classification: Spaces and Profiles

Upon receiving their ASA, users have the option to designate their domain as a ‘Space’ or a ‘Profile.’ Each classification has specific criteria for becoming ‘active,’ enabling users to differentiate between individual and collective entities on the platform.

Through the Domain Classification feature, we have streamlined the user experience and facilitated the management of different types of entities within XBallot.

Primes: Empowering User Interaction

Recognizing the significance of user interaction, we introduced the concept of ‘Prime.’ This represents the primary AppId and the associated ASA that reflects a user’s settings, avatar, delegations, and more. The Prime domain holds a special position as the first domain in the user index at the registrar endpoint. Users have the flexibility to change their Prime domains as often as they desire, allowing for seamless transitions between different identities.

Prime plays a vital role in enhancing user interaction with the XBallot platform, providing users with a personalized and customizable experience. To explore the Primes endpoint, please visit Primes.

Profiles: Efficient Domain Organization

To facilitate efficient organization and accessibility of a user’s domain information, we introduced the ‘Profile’ endpoint. This endpoint serves as an index of all domains associated with a user, organized by their base Algorand app address. It plays a crucial role in user profile pages, particularly the domains endpoint.

Through the Profile endpoint, we have achieved a streamlined approach to managing multiple domains, enhancing the overall usability of the XBallot platform. To learn more about Profiles and their functionalities, please visit the Profiles endpoint. Profiles

Portals: The Core of Space Interaction

The Portal endpoint is crucial to XBallot’s operations. It houses the forum data for each Space, acting as the primary source for community discussions. Space Forums are not activated by default. To activate them, a space manager must set a Forum Token and Token Amount, which define the token-gating threshold for posting in a specific space’s community forum. The user interactions like posts, likes, shares, and reBlasts are displayed only if the user holds the minimum token balance at the time the interaction is displayed. If the user’s token balance falls below the Token Amount minimum, their interactions will no longer be visible on the Space Forum feed.

Portal interactions are essentially zero transactions with a formatted note submitted to the Algorand application address for each Space.

Beyond serving as a feed aggregator for Space Forums, Portals also handle Proposal Validations and Reports. XBallot users can report any proposal, post, space, etc. These reports are submitted to a Space’s application address and are delivered to the space manager. Proposal Validations are similarly submitted to the same address and filtered by type. To explore the Portals endpoint, please visit Portals.

Proposals: The Heart of Decision-Making

The Proposals endpoint was among the most challenging to construct. It handles all active and historical Space Proposals across all spaces, covering keys like choices, content, title, scores, validation, and more. Each Proposal exists in four places:

  1. On-chain Smart Contract Proposal Index: Every Space application has built-in rules for managing proposals. An active proposal is described in the global state of the application tied to that specific space. The ‘index’ value represents the number of the current proposal.

  2. On-chain Smart Contract pDescription hash: The application Global State for a respective Space also holds a field for pDescription corresponding to the Proposal index. The pDescription is a base64 encoded IPFS hash, which can technically house any text the user desires, although it’s designed to link to an IPFS document.

  3. Off-chain IPFS proposal object: The pDescription hash points to an IPFS document pinned on Infura, holding all the relevant information about the specific proposal including the voting system, voting token, proposal content, title, choices, etc.

  4. On-chain Local State Delta: When a user votes on a proposal, they submit an app call transaction with Local State keys as an optional argument. This argument contains vital information about the user’s vote.

The XBallot Indexer indexes all the user votes and calculates voting power based on the voting system, voting token, proposal max round, etc.

Balance Indexer: The Voting Power Calculation Engine

One of the significant challenges we encountered while developing XBallot was establishing an accurate voting power calculation mechanism. Voting power is a fundamental concept in the XBallot voting protocol and represents a snapshot of an Algorand address’s ASA balance at a specific round. However, the Algorand Indexer presents limitations in determining an address’s ASA balance at a given round, especially if that round is more than 1000 rounds in the past.

Obtaining a simple snapshot of address balances at the maximum round also proves impractical, particularly when dealing with large-scale operations. Realizing the need for a robust solution, we made the decision to develop a specialized account indexer dedicated to recording ASA balances for Algorand addresses. Let’s explore how this account indexer works:

  1. Collection of Current Balances: We collect the current balances of all Algorand addresses that have cast a vote. This initial collection serves as a starting point for our historical view of balances.

  2. Monitoring New Blocks: The account indexer actively monitors every new block for transactions involving the monitored addresses. It watches for any transactions from or to an Algorand address within the collected array.

  3. Recording Balance Entries: When a transaction involving a monitored address occurs, we add a new balance entry for that address. This ensures that we maintain an up-to-date and comprehensive record of balances for precise calculations.

By implementing this solution, we can provide a historical view of any Algorand balance up to the current block. This allows us to achieve ultra-precise voting power calculations in real time, ensuring the accuracy and reliability of the XBallot voting system.


This overview provides a glimpse into some of the remarkable features offered by XBallot. To explore the protocol in-depth, we encourage you to delve into the indexer or visit the interface. Stay tuned as we roll out the complete protocol documentation in the coming days/weeks, offering comprehensive insights into the inner workings of XBallot.

Tech Stack:

Interface: React.js
Chain connector: Pipeline SDK
Smart contract: TEAL
Worker: Express.js
Account Worker: Express.js
Indexer API: Express.js
Database: MongoDB


Hi, I like your XBallot design. Reminds me of snapshot.

I also like how you monetize your product from the algorand economy with your domains.

What I do not like is that there is no way to do delegated voting. In the open vote coin standard people can do categorized delegation. This brings to DAO much more efficiency because if you want all DAO members to vote in all DAO questions, people will get too much occupied. Imagine that you do voting on each pull request to the code base or any spending of the money.

Next thing i do not like is that during the voting session all people’s vote casts are public. There is huge risk of vote manipulation either if you vote soon, or if whale votes last. The vote coin standard has optional encryption in place for voting ballots, i recommend to take look at it.

I see that you were financed quite well. May I ask from where do you have money to create the DAO management platform? Also I wonder if you considered to use the Vote Coin standard or if you can provide feedback on the vote coin standard or any of the vote coin open source apps. Thank you

1 Like

Just quickly:

  1. We do support delegate voting. You can find more info in our swagger docs - Swagger UI

  2. We have not raised or received any funding at all. The platform has been entirely built without funding.

  3. We will support private voting in the future. Our protocol is primarily based on open, public voting so it’s not a high priority right now.

  4. Yes, we based the interface on Snapshot and Tally. Primarily Snapshot as they have laid a strong foundation for voting system best-practices.

  5. Not familiar with Vote coin. Happy to provide feedback. Where would you like feedback directed?

1 Like

Great, it seems that we have the same vision. I am sorry that you did not notice the vote coin project before you started implementation, but still I think there is chance for cooperation.

Have you checked the vote coin standards? It is the set of json schemas which are stored in the blockchain in the note field. How to ask question, how to delegate voting power in specific category, how to cast open or encrypted vote, or how to manage the trusted list of accounts, and at the end the voting session results.

There are open source vote coin indexers, apps and more, so in the case you do not want to cooperate and you want us to be competing projects, feel free to improve your product by our ideas so that we drive algorand ecosystem stronger…

You can address the feedback to me at this forum, or the email info@vote-coin.com or the vote coin discord.


Thanks for the info!