During Serbia's student movement, the question was never only whether students agreed. It was whether they could prove agreement in a way everyone could trust.
Faculties were coordinating in real time — blockades, joint positions, responses to institutional pressure. Decisions had to move fast, but they also had to be legitimate. A group chat vote is easy to dispute. A verbal show of hands is easy to misread. When the stakes are public and political, informal coordination stops being enough.
eVSD started from that gap: a decentralized voting platform built by students, for students, designed to formalize collective positions with blockchain-backed transparency.
The Problem During the Movement
Student protests create a coordination problem that looks simple from the outside and becomes messy on the inside.
Different faculties need to align. Positions need to be recorded. Votes need to be visible enough that no one can later claim the outcome was manipulated, hidden, or reversed. At the same time, the system cannot depend on a single admin, a single server, or a single person holding the keys.
That is the tension eVSD was built to solve. Not surveillance. Not performative tech. A shared record of what faculties decided, when they decided it, and who voted how — without asking anyone to trust an opaque backend.
The Product Idea
eVSD is a decentralized voting and coordination platform intended for faculty-related decisions, especially during the events connected to the current student movement in Serbia.
The core use case is straightforward:
- a faculty representative creates a proposal
- every faculty with voting rights casts a vote
- the result lives on-chain as a public, verifiable record
Most proposals function as a decentralized public database: a durable statement of collective position. Some proposals — like adding a new faculty to the system — have direct on-chain effects.
The product goal is trust through architecture, not through branding.
Why Blockchain, and Why Governor
We did not reach for blockchain because it sounds modern. We reached for it because the movement needed shared truth without a central authority.
The platform uses OpenZeppelin's audited Governor smart contract pattern. Voting rights are tied to an ERC20 token also built on OpenZeppelin primitives: holding delegated tokens means holding voting power.
The model is deliberately flat. Only faculties have voting rights, and every participating faculty has equal weight. That matches the movement logic: coordination across institutions, not hierarchy inside one of them.
On deployment, a fixed token supply is created. One token goes to each faculty currently in the system. The remainder goes to the Governor contract so new faculties can be added later through a majority vote — a governance loop that can grow with the movement instead of resetting every time someone new joins.
How a Vote Actually Works
The flow is intentionally simple for operators and strict for the chain.
- Deploy the Governor and token contracts to the network.
- Distribute one token per faculty and delegate voting rights.
- Propose — any address with nonzero voting power can create a proposal through the contract's
proposefunction. - Vote — faculties cast votes through
castVote. - Record — the outcome stays on-chain as the canonical result.
For local development, the stack runs on Hardhat with MetaMask connected to a local chain. For the movement context, the important part is not the dev setup. It is the property the setup proves: once votes are cast, they become part of a ledger faculties can inspect independently.
That matters when trust is fragile. When people ask "did we actually agree on this?", eVSD is meant to answer with evidence, not with screenshots.
Frontend as the Human Layer
The smart contracts define the rules. The frontend makes those rules usable during real coordination.
The eVSD frontend is a Next.js application that talks to the Governor contract through Ethers.js. Students connect a wallet, see active proposals, and vote without needing to read Solidity. The interface is the operational layer — the place where governance becomes something a faculty delegate can actually run during a stressful week of protests, negotiations, and last-minute alignment calls.
Under the hood, the repo includes Hardhat scripts for deployment and vote delegation, plus CI for blockchain integration tests and UI tests. That discipline matters because a voting product that breaks during a live decision is worse than no product at all.
What We Were Optimizing For
Three constraints shaped every design choice.
Equal faculty representation. The movement is multi-institutional. Weighting votes by size, budget, or informal influence would have undermined the point.
Public verifiability. Outcomes need to be inspectable by anyone with access to the chain — not rewritable by whoever runs the server.
Low ceremony, high legitimacy. Proposals should be easy to create and vote on, but the record should feel serious enough that faculties treat it as binding coordination infrastructure.
eVSD is not a replacement for being in the streets. It is infrastructure for the moment after the room agrees — when that agreement needs to survive pressure, delay, and dispute.
Team and Context
I led the team building eVSD as a student project during a period when faculties across Serbia were trying to coordinate faster than traditional institutions could respond. The work sits at the intersection of software engineering, governance design, and the practical politics of a live student movement.
The source lives in the eVSD repository, with the public frontend maintained under eVSD-PUB/front.
This project is part of the UNMARKOBLE creative technology portfolio by Marko Andrić, alongside InfluConnect and the Crowd Flow Control Tower.