# Agora Blockchain: Moving Voting Algorithms On-Chain with CCIP > Agora Blockchain ports classic voting algorithms like Borda and IRV into Solidity contracts, using Chainlink CCIP for cross-chain ballots. It is a working prototype with real testnet deployments, but its security model and maintenance status need scrutiny before adoption. **AOSSIE-Org/Agora-Blockchain** — Agora-Blockchain - Repository: https://github.com/AOSSIE-Org/Agora-Blockchain - Stars: 95 · Forks: 199 - Language: JavaScript - License: NOASSERTION - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/aossie-org-agora-blockchain ## What Agora Blockchain Actually Solves Agora Blockchain tackles a specific problem: voting algorithms that are normally implemented in centralized backends, like Moore's, Oklahoma, Borda, and IRV, have no transparent way to prove that ballots were not altered by a database administrator or a hacker. The project's README states its vision is to take these algorithms onto a decentralized platform so that ballots become immutable. The target audience is not the general public but developers and organizations that want to run elections where the tally logic itself is verifiable on-chain. The project is a library of voting algorithms, not a full election platform. It provides the smart contract infrastructure to create elections, generate ballots, and calculate results, all recorded on a blockchain. ## Architecture: ElectionFactory, Clones, and CCIP The core mechanism is an ElectionFactory contract that creates new election instances. The README explains that the factory uses a clonable election template, called electionGenerator, to reduce deployment costs. Instead of deploying a full new contract for each election, it clones a pre-deployed template, which is a standard minimal proxy pattern. The factory also coordinates two helper contracts: BallotGenerator for creating ballots and ResultCalculator for computing the winner. The interesting part is cross-chain voting. The factory implements Chainlink's Cross-Chain Interoperability Protocol (CCIP) so that voters can cast ballots from multiple blockchain networks. The README emphasizes that only whitelisted contracts can send votes across chains, which is a deliberate access control measure. This design separates concerns: election creation, ballot generation, result calculation, and cross-chain messaging are distinct components, which makes the code easier to reason about but also adds complexity in coordinating those pieces. ## Getting It Running: Docker and Manual Paths The README gives two ways to run the project. The quickest is Docker Compose. After cloning the repository, you create a .env.local file in the blockchain directory with PRIVATE_KEY, RPC_URL_SEPOLIA, RPC_URL_FUJI, and ETHERSCAN_KEY. The client directory needs a .env.local with NEXT_PUBLIC_PINATA_JWT, which suggests Pinata is used for IPFS storage, though the README does not explain how. Then run docker-compose up --build. This starts the frontend at localhost:3000 and a blockchain node at localhost:8545. The manual path is more explicit. For the backend, cd into blockchain, run npm install, then npx hardhat test. Deployment uses Hardhat Ignition: npx hardhat ignition deploy ./ignition/modules/ --network --verify. The frontend uses Next.js, so after npm install in the client directory, you run npm run dev. The environment variable names are concrete and the commands are copy-paste ready, but the README does not mention what network to use for local testing or whether a local Hardhat node is started by default. ## Deployed Instances and What They Prove The README lists three deployed artifacts: an Election Factory on Sepolia testnet, a CCIP contract on Fuji testnet, and a live frontend at agora-blockchain.vercel.app. These are real, checkable links. The Sepolia address is 0x64c720eBD5227bba57a5E8282893e71087cCcBb8 and the Fuji address is 0xf267f0603672E791779E52B153BD9A39C9928767. Having testnet deployments is a meaningful signal that the core contracts compile and deploy, but it is not evidence of production readiness. Testnets are for experimentation. The README does not state whether these contracts have been audited by a third party. The presence of a live frontend suggests the project is more than a bare library, but the frontend's functionality, such as how it interacts with MetaMask and Wagmi, is not described beyond the tech stack list. ## Limitations and Failure Modes The most obvious limitation is that the README is thin on security details. It claims that blockchain technology makes ballots immutable and hence more secure, but immutability is not the same as security. A poorly written voting algorithm can still produce wrong results, and a whitelisting mechanism can be bypassed if the factory's access control has a bug. The README mentions owner management so only the election creator can delete or modify their election, but it does not explain what happens if the owner loses their private key. There is no recovery mechanism described. Another limitation is the reliance on Chainlink CCIP. Cross-chain voting introduces a dependency on an external oracle network. If CCIP is unavailable or misconfigured, votes from other chains could be delayed or lost. The README does not address how the system handles CCIP failures. Finally, the project has no declared license, which is a legal risk for anyone wanting to use or modify the code. The GitHub page shows NOASSERTION, meaning the repository does not specify a standard open source license. ## The Wrong Tool for High-Stakes Elections Agora Blockchain is not the right choice for a national election or any vote where a dispute could end in court. On-chain voting has a fundamental transparency trade-off: if ballots are public on a blockchain, voters lose privacy. The README does not mention any encryption or zero-knowledge proof mechanism to hide individual votes. That alone rules out most real-world elections, where ballot secrecy is a legal requirement. The project seems better suited for internal organizational votes, DAO governance, or academic experiments where privacy is not a hard constraint. Even for those cases, the lack of a formal specification for the voting algorithms is concerning. The README names Moore's, Oklahoma, Borda, and IRV, but it does not describe how each algorithm is implemented in Solidity. A developer adopting this library would need to read the contract source carefully to verify that the tally logic matches the intended algorithm. ## Alternatives: Centralized Libraries vs. Other On-Chain Systems The README itself mentions that AOSSIE already implements these voting algorithms in a centralized manner using Scala. That Scala library is a direct alternative. The difference is clear: the Scala version runs on a server you control, so it is faster and cheaper to operate, but it trusts the server operator. Agora Blockchain moves the trust to the blockchain, which adds cost and latency but provides public verifiability. Another alternative is to use a general-purpose DAO voting platform like Snapshot, which uses off-chain voting with on-chain execution. Snapshot is simpler and free, but it does not support ranked-choice algorithms like IRV or Borda out of the box. Agora Blockchain's advantage is that it implements those specific algorithms in smart contracts, so you get the exact tally method on-chain. The trade-off is that you are responsible for deploying and securing the contracts yourself. ## Maintenance and Upgrade Costs The repository's last push is listed as unknown, and there are no recent releases retrieved. That is a red flag for maintenance. The README encourages contributions and points to a Discord channel, which suggests an active community, but the absence of release tags means you cannot track stable versions. Upgrading a deployed election contract is not trivial. The ElectionFactory uses a clonable template, so if you want to fix a bug in the voting logic, you would need to deploy a new template and update the factory to point to it. The README does not describe an upgrade mechanism beyond the clone pattern. The license is NOASSERTION, so you cannot assume you have the right to modify and redistribute the code. Before using this in any project, you should contact the maintainers to clarify the license and ask about their release process. The codebase is small enough to audit manually, but the lack of formal releases means you are essentially pinning your project to a moving main branch. ## Conclusion Adopt Agora Blockchain if you are a developer or researcher exploring on-chain voting mechanics and need a reference implementation of classic algorithms like Borda and IRV with cross-chain capabilities. Do not use it for production elections without a thorough security audit, because the codebase lacks a declared license, has no recent release history, and the README does not document audit results. Before relying on it, verify the smart contract code on the Sepolia and Fuji testnet links, check the repository for open security issues, and confirm the license status with the maintainers. ## FAQ ### what is agora blockchain A library of voting algorithms including Moore's, Oklahoma, Borda and IRV, ported onto a decentralized platform so that crucial votes cannot be tampered with by administrators, hackers, or anyone with database access. Several of the algorithms already exist in centralized form from AOSSIE, using Scala as the backend. ### What does the ElectionFactory contract do? It is the core of the election system, generating new election instances, handling cross-chain voting and keeping a record of active elections. It relies on the Election, BallotGenerator and ResultCalculator contracts plus Chainlink CCIP components, and only the election creator can delete or modify their election. ### How does Agora Blockchain handle voting across chains? Through Chainlink's Cross-Chain Interoperability Protocol, which allows voting from multiple blockchain networks. Only approved contracts on a whitelist may send votes across chains, which is the mechanism said to prevent unauthorized access. ### How do I run the Agora Blockchain frontend and chain locally? The documented Docker path is docker-compose up --build, which starts a blockchain service on port 8545 and a frontend on port 3000, with the frontend depending on the chain. The manual path installs dependencies in blockchain and client, runs npm run dev in the client, and opens localhost:3000. ### Which testnets is Agora Blockchain deployed on? The Election Factory is verified on the Sepolia testnet through Etherscan, and the CCIP contract is verified on the FUJI testnet through Snowtrace. The frontend is published separately, and the environment variables expect RPC URLs for both Sepolia and Fuji. ## Sources - [Official README](https://github.com/AOSSIE-Org/Agora-Blockchain#readme) - [Project repository](https://github.com/AOSSIE-Org/Agora-Blockchain) - [README](https://github.com/AOSSIE-Org/Agora-Blockchain/blob/main/README.md) - [Releases](https://github.com/AOSSIE-Org/Agora-Blockchain/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aossie-org-agora-blockchain