WoCo - Swarm-hosted side-event ticketing and attendee contact cards for Devcon 8

Devcon Improvement Proposals (DIPs)
1

Title: WoCo - Swarm-hosted side-event ticketing and attendee contact cards for Devcon 8

Authors: Nabil Abbas (WoCo) · X: @yea_80y, @woco_org

Resources Required: No space or power. From the Devcon team: pointing side-event organisers to the WoCo app, a few introductions, a conversation about contact cards in the Devcon app, and one Devcon ticket so I can support organisers on-site.

:brain: What do you suggest?

We have an open DIP on Swarm-hosted profiles and forums for the Devcon app. This one is separate and much smaller. Side-event organisers can use WoCo without anything from the Devcon team; the second idea below, attendee contact cards, would be most useful inside the Devcon app. Since that thread’s last update in April, the platform has kept shipping: card payments, onchain tickets, event pages served from ENS names, and organiser websites on their own domains. Some specifics in the earlier posts have moved on, and I got one of them wrong - there is a correction below.

Two ideas:

  1. Side events on WoCo. Swarm-hosted event pages and sites, tickets with onchain ownership, and offline door check-in.

  2. Attendee contact cards. A profile, follows and private notes on each attendee’s own Swarm feed, in WoCo or inside the Devcon app.

:bullseye: Motivation & Rationale

  • How does this improve the attendee experience?

Organisers sell from their own event page or website, and buyers there need only an email address. A WoCo account is optional: buyers can already use one on WoCo itself, and we plan to add it as a checkout option on organisers’ sites too, which we can prioritise for Devcon 8 side events.

A ticket is also more than a way in: on WoCo it unlocks the holder’s profile and a sub-ENS name.

We floated this in January as “POD contact cards”; here is its real shape. Collecting contacts at events is a mess - Telegram handles you cannot place by the next morning. The proposal: an attendee profile (a bio plus whatever contact details they choose to publish) on the attendee’s own Swarm feed. Meet someone, follow them, attach a private note only you can read: where you met, what you said you would send.

  • What Ethereum use case does it showcase?

The practical difference from a hosted platform is that ticket ownership is recorded onchain and the pages run on decentralised infrastructure*. The door scanner downloads those ownership records before doors open, so check-in works offline.

Tickets are signed object data with onchain ownership, which also makes them usable for gating access, for example to another event.

No chain and nothing to pay: a follow is a signed statement written to your own feed (nobody writes to anybody else’s), and follower views are compiled from those feeds by an indexer that publishes its evidence, so anyone can recompute or replace it. The graph is keyed to the attendee’s own crypto account rather than a WoCo login, which is what makes it portable - including away from us. Today those statements sit on our postage batch, so they live while we pay for stamps; we intend to move them onto batches owned by the attendee’s own address, so the data stops depending on us existing.

The original post argued the Devcon app itself could eventually live on Swarm. We still think that is where this leads, but we would rather show it working than keep making the case, and side events are the natural place to start: real organisers and real attendees, without the main event depending on it.

:hammer_and_wrench: Implementation

  • Have you done this before at another event?

Not yet. We expect to host the first events in the coming weeks, so there should be a few behind it by November.

  • How will you make it happen?

Side events

Side events run almost entirely on Luma. WoCo does the same job, and an organiser can also build their own full website on it, with no separate website builder needed. Event pages and websites are published to Swarm, then served from a name we issue (yourevent.woco.eth) for event pages, or the organiser’s own domain for websites, with ENS support on the way.

Most side events are free RSVPs. Free events are not switched on in the WoCo app yet; we would switch them on for Devcon 8 side events on a yes from the Devcon team. Paid events take cards through Stripe. A crypto rail is built but unfinished, and stays behind a flag until it has been audited. We have been awarded an Ethereum security audit subsidy.

A correction on PODs

Earlier updates in the original DIP thread described WoCo tickets as PODs. They are not, and that mistake is mine.

The prototypes behind those posts did use 0xPARC’s POD library (@pcd/pod): in August 2025 to display the Devcon 7 PODs I had exported from Zupass, and in December 2025 and January 2026 to sign test collectibles in a sandbox. When I started WoCo in February, I left the library out in favour of simpler signing, and kept the name. I was treating “POD” as a general term for signed data, when it is a specific format (EdDSA-Poseidon signatures on the Baby Jubjub curve), and that format is exactly what lets Zupass hold a POD and GPC proofs work over it. Sign the same data another way and it is no longer a POD.

So the March update was wrong to say tickets were “issued as PODs … consistent with how previous Devcon credentials have been managed”, and the April prototype’s “POD tickets” were not PODs either. I should have checked both against the POD documentation before posting them. A WoCo ticket will not load into Zupass and cannot be used in a GPC proof. The word is now out of the product and the code: what WoCo issues is signed object data in our own open format, and in the dashboard badges and collectibles are simply called objects.

What a ticket actually is: when a ticket is bought, we generate a one-time key for it. That key’s address is recorded against the seat onchain, the key signs the ticket, and then it is thrown away, so the only valid ticket for a seat is the one issued at purchase. Each ticket type is also committed by a single organiser signature over a Merkle root, and that commitment is recorded onchain.

Contact cards

Profiles and follows are live today; the contact card and the private note are the layer left to build.

What it should not do is invent an attendee credential of its own. Devcon 7 tickets came with a real POD in Zupass; if Devcon 8’s do too, the contact card should read that POD to check someone is an attendee, while profiles, follows and notes stay on Swarm feeds, where they can change. That means adding POD verification on our side, which is a bounded piece of work, and it uses a credential Devcon already issues.

It can run two ways. On its own in WoCo, with nothing added to the Devcon app: attendees just open WoCo. Or inside the Devcon app, where everyone already is, as the npm modules our original post described. Everyone in the app already has a crypto account, so the modules derive a feed signer from the account you already issue rather than adding an identity layer. Inside the app is where it is most useful, and that integration is the work we would do on a yes. Side-event attendees on WoCo get it either way.

:gear: Operational Requirements & Ownership

  • What’s needed to make this work at Devcon/nect?

Two suggestions for the Devcon team:

  1. Point side-event organisers at it as a decentralised alternative.

  2. If a few side-event organisers want to try it, introduce us, so it is tested at Devcon 8 itself rather than just proposed.

Beyond that, nothing on site: organisers run their own events.

*One dependency is worth naming before someone else does: reads and writes go through a gateway today. The Swarm Foundation and the wider community are building Swarm browser nodes/light clients, and we intend to move reads and writes onto them as they become available.

  • Who will be responsible for running it on site?

Each organiser runs their own event and door check-in; WoCo runs the platform and supports organisers directly. I can be in Mumbai for Devcon week to help organisers in person.

And to anyone organising a side event or community hub: if you would like to run yours on WoCo, reply here or message us on Discord. We can help you set up while we finish making the app live, be on hand if anything comes up, and would welcome any feedback.

  • What other projects could this integrate with?

  • Zupass: the contact card reads the POD Devcon issues through Zupass, if Devcon 8 tickets come with one.

  • The Devcon app: contact cards as npm modules inside the app.

  • ENS: event pages served from sub-ENS names, with ENS for organiser websites on the way.

:link: Links & Additional Information

Organisers can also issue signed badges and collectibles from the dashboard: attendee keepsakes, rewards for a game or a trail around the venue. Badges won’t need a chain: as signed credentials they will work on their own, with gating access as one more use, and issuing one will be a few clicks.