These ideas show the range of what may fit Major League Security. Use them as inspirations, and be creative to develop your own exciting ideas.
Hermes
NETWORKING & SCION
In disaster scenarios where cellular and WiFi infrastructure has failed, LoRa mesh networks provide a last-resort communication fabric: infrastructure-free, long-range, and low-power. Such networks are already deployed by relief organizations worldwide. Yet when a message from a field team needs to reach the outside world, it exits through a gateway onto the internet with no control over which ASes it traverses: the upstream provider may itself be congested or partially failed, and although a backup connection via satellite may exist, there is currently no mechanism for a field operator to enforce usage of the backup link. SCION would provide this explicit control, but sending full SCION packets via LoRa would be wasteful or even infeasible given the bandwidth and packet size constraints of LoRa.
Hermes solves this through a tag-based indirection protocol. Instead of carrying the entire SCION header via LoRa, the sending LoRa device instead registers a path policy - expressed in a compact format encoding preferences such as latency bounds, AS exclusion lists, or a fully pre-specified path - with a gateway device that bridges the LoRa mesh to a SCION-connected internet uplink. The gateway returns a short tag and a shared symmetric key. Subsequently, all outgoing LoRa packets carry only the tag rather than any SCION state, keeping per-packet overhead small, and independent of SCION path length. At the gateway, the tag is resolved to a policy or cached path, a full SCION header is constructed, and the packet is forwarded into the SCION network. Each packet is authenticated with a short truncated MAC to provide authentication the shared radio medium. Path expiry is handled transparently by the gateway: policy-based tags trigger silent re-resolution against the current SCION topology, while operator-specified paths trigger a lightweight notification requiring re-registration.
GeoProof
IDENTITY & E-ID
Applications on the internet use repeating behavior, such as a user accessing the application from a consistent location or IP address, to gauge the likelihood of the user request being fraudulent. Even just logging in via an unknown IP can be enough to require the user to re-authenticate. This step-up authentication typically falls back to SMS or email codes that reveal persistent identifiers and are vulnerable to SIM-swap attacks. GeoProof explores an alternative: cryptographic proximity proofs using trusted physical beacons. Small devices installed at known locations (a home, an office, a university building) act as authentication anchors. When a user logs in, their device forwards a challenge to a nearby beacon via Bluetooth or Wi-Fi, and the beacon produces a signed response proving physical presence. The core research challenge is privacy: the relying party should learn that the user was near some trusted beacon, but not which one or where it is. Possible directions include group signatures, blind tokens, anonymous credentials, and distance-bounding protocols to prevent relay attacks.
BGPsec DoS
NETWORKING & SCION
BGPsec adds cryptographic signatures to BGP route announcements so that each AS on a path signs the UPDATE message. This creates an asymmetry: an attacker can pre-generating a stream of fake UPDATEs with a long AS-paths, which are expensive to verify by a BGPsec router. A flood of crafted long-path UPDATEs can exhaust a router's CPU before it can discard them, while the attacker's cost stays constant. This project builds a testbed with a BGPsec-capable software router and a BGP UPDATE generator. The project measures CPU utilisation and processing latency as path length increases from 1 to 255, and the rate of UPDATEs increasing. A detailed evaluation on how path length and UPDATE rate can impact BGPsec router performance will identify processing bottlenecks introduced by BGPsec.
ReleaseFlow
FINTECH SECURITY
Creator payments (Twitch/Youtube donations, Patreon, Ko-fi, etc.) today are simple: fans subscribe, tip, or pledge money, and the platform transfers funds immediately or on a fixed schedule. But many real-world arrangements are more nuanced. A supporter may want to pay only if a creator uploads two videos this month, streams for at least five hours, or stays active over a certain period. More unusual conditions are also imaginable, such as unlocking a bonus if a livestream reaches a given size or refunding support if the creator disappears for several weeks. Existing platforms offer only limited support for these arrangements and usually rely on centralised platform logic to settle disputes.
ReleaseFlow explores a system for programmable creator payments based on a custom policy language. Instead of hard-coding a few payment types, the system allows users to describe release conditions declaratively using creator metadata such as upload frequency, stream duration, subscriber count, other trusted platform events, or even real-time data from ongoing streams like points collected in a game. At the heart of this project is a compact and safe description language, which the system uses to verify release conditions securely. The key challenge is to have the system decide which data sources are trusted, how often conditions are checked, how ambiguity is avoided, and how manipulation is prevented. The system has to be hardened against attacks such as forged metadata, platform API inconsistencies, maliciously crafted conditions, and disputes about whether a release rule was actually satisfied.
What the jury looks for