EBSI meets DAVINCI: how UPC used European blockchain infrastructure for private student voting

What happens when a university wants to run a vote where only its own students can participate, no one else can see who voted for what, and every ballot can be independently verified, all using nothing more than the credentials students already have?

A proof of concept at the Universitat Politècnica de Catalunya (UPC) set out to answer exactly that. Developed as part of the postgraduate thesis of Xavier López Mañes, within the DAVINCI project, the work demonstrates how institutional identity systems can integrate with blockchain‑based voting to deliver private, secure, and verifiable elections.

Key facts

• Organisation: Universitat Politècnica de Catalunya (UPC)
• Project: DAVINCI protocol
• Approach: Two distinct integration paths tested (EBSI decentralised identity + institutional fallback)
• Authentication: Standard university credentials
• Voting layer: DAVINCI protocol with Vocdoni SDK
• Result: Functional student voting with end‑to‑end verifiability
  

The challenge: identity meets privacy

Any institution that runs elections faces a tension. You need to know that every voter is who they say they are, and that they belong to the eligible group. But you also need to keep their ballot secret. Those two requirements pull in opposite directions. The more you verify identity, the harder it becomes to protect privacy.

The UPC team built a system that resolves this tension by keeping the identity layer and the voting layer separate. The university handles who you are. The voting protocol handles what you vote. Neither side needs to trust the other blindly, because a cryptographic proof connects them without revealing personal information.

Two paths to the same goal

The proof of concept tested two integration approaches. Both share the same fundamental architecture: students identify themselves with the credentials they use on campus every day, and the voting system receives only a cryptographic proof of eligibility, not the credentials themselves.

But they differ in how the identity layer is deployed.

---

Phase one: integration with EBSI

The first phase aimed for full integration with the European Blockchain Services Infrastructure (EBSI), the European Commission's permissioned blockchain framework for trusted digital services. EBSI lets institutions like UPC issue verifiable credentials that students can link to a personal wallet, and then validate that those credentials belong to a specific member of the authorised group.

The student experience looked like this:

1. Authenticate: The student logs in with their standard university credentials through the UPC Issuer on the EBSI network.
2. Claim credentials: The Issuer generates a QR code that lets the student sign their credentials into their own wallet.
3. Prove eligibility: When voting opens, the student uses their wallet to authenticate with the UPC Verifier. The Verifier checks that the wallet belongs to an authorised student and produces a census proof.
4. Cast ballot: The student submits their vote through the DAVINCI SDK, with the census proof attached.

The architecture guarantees two things simultaneously: students authenticate with credentials they use every day, and those credentials never leave the institutional domain. The system proves eligibility without ever seeing the user's actual identity data.

Why this matters: EBSI is designed for cross‑border interoperability. A credential issued by UPC could, in principle, be used to vote in elections run by other institutions across Europe. That is the long‑term vision.

What stopped it: The technical side worked. All components were implemented and validated. But the administrative approval timelines of the governing bodies behind EBSI made it impossible to finalise the integration within the project's timeframe. The technology was ready. The governance was not.

---

Phase two: the institutional fallback

When the EBSI timeline did not close in time, the team adapted the scope. And this is where the flexibility of the DAVINCI protocol becomes the real story.

The EBSI Issuer was replaced by a service managed directly by the UPC. The university remains fully responsible for managing student identities and preserving privacy. The protocol itself did not need architectural changes, only a different identity source.

The adapted flow:

1. The student generates an ephemeral wallet through a web application.
2. Logging in with their university credentials associates this wallet with their institutional identity.
3. When voting opens, the wallet authenticates with the UPC Verifier, which generates the census proof.
4. The student casts the vote through the DAVINCI SDK.

The difference: From the student's perspective, the experience is almost identical. From an institutional perspective, the deployment complexity is lower — no dependency on external blockchain governance. The university controls the entire identity layer directly.

What stays the same: The voting remains private, the ballots remain verifiable, and only eligible students can participate.

Why this matters for institutions that hold elections

The proof of concept demonstrates a practical spectrum. At one end, fully decentralised identity through frameworks like EBSI, with cross‑border interoperability as the prize. At the other, a simpler institutional model where the organisation manages its own identity layer. The same protocol handles both.

This matters for any institution that runs elections and manages its own census: universities, professional bodies, trade unions, public administrations. It means you can offer voters a path to participation using credentials they already have, on whichever blockchain network makes sense for your context (public L1, L2, or permissioned), without sacrificing privacy or institutional control.

The DAVINCI protocol and the DAVINCI SDK are designed to sit between identity and the ballot box, keeping them separate by design.

---

Interested in running secure, verifiable elections for your organisation? Start a free election at app.vocdoni.io or contact us to discuss your use case.