DIF Hackathon 2024 (the “Hackathon”) Official Rules

NO PURCHASE OR PAYMENT NECESSARY TO ENTER OR WIN. A PURCHASE OR PAYMENT WILL NOT INCREASE YOUR CHANCES OF WINNING. 

SUBMISSION OF ANY ENTRY CONSTITUTES AGREEMENT TO THESE OFFICIAL RULES AS A CONTRACT BETWEEN ENTRANT (AND EACH INDIVIDUAL MEMBER OF ENTRANT), THE HACKATHON SPONSOR, AND DEVPOST.

1. Dates and Timing

Submission Period: October 1, 2024 (6:00 am Pacific Time) – November 4, 2024 (3:00 pm Pacific Time) (“Submission Period”).

Judging Period: November 7, 2024 (6:00 am Pacific Time) – November 17, 2024 (11:45 pm Eastern Time) (“Judging Period”).

Winners Announced: On or around November 20, 2024 (9:00 am Pacific Time).

2. Sponsor and Administrator

Sponsor & Administrator: Decentralized Identity Foundation, 548 Market Street, PMB 57274 San Francisco, CA 94104 United States

3. Eligibility

• The Hackathon IS open to: 

• Individuals who are at least the age of majority where they reside as of the time of entry (“Eligible Individuals”);

• Teams of Eligible Individuals (“Teams”); and

• Organizations (including corporations, not-for-profit corporations and other nonprofit organizations, limited liability companies, partnerships, and other legal entities) that exist and have been organized or incorporated at the time of entry.

(the above are collectively, “Entrants”)

An Eligible Individual may join more than one Team or Organization and an Eligible Individual who is part of a Team or Organization may also enter the Hackathon on an individual basis. If a Team or Organization is entering the Hackathon, they must appoint and authorize one individual (the “Representative”) to represent, act, and enter a Submission, on their behalf. By entering a Submission on behalf of a Team or Organization you represent and warrant that you are the Representative authorized to act on behalf of your Team or Organization.

• The Hackathon IS NOT open to: 

• Individuals who are residents of, or Organizations domiciled in, a country, state, province or territory where the laws of the United States or local law prohibits participating or receiving a prize in the Hackathon (including, but not limited to, Brazil, Quebec, Russia, Crimea, Cuba, Iran, North Korea, Syria and any other country designated by the United States Treasury's Office of Foreign Assets Control) 

• Organizations involved with the design, production, paid promotion, execution, or distribution of the Hackathon, including the Sponsor and Administrator (“Promotion Entities”).

• Employees, representatives and agents** of such Promotion Entities, and all members of their immediate family or household*

• Any other individual involved with the design, production, promotion, execution, or distribution of the Hackathon, and each member of their immediate family or household*

• Any Judge (defined below), or company or individual that employs a Judge

• Any parent company, subsidiary, or other affiliate*** of any organization described above

• Any other individual or organization whose participation in the Hackathon would create, in the sole discretion of the Sponsor and/or Administrator, a real or apparent conflict of interest 

*The members of an individual’s immediate family include the individual’s spouse, children and stepchildren, parents and stepparents, and siblings and stepsiblings. The members of an individual’s household include any other person that shares the same residence as the individual for at least three (3) months out of the year. 

**Agents include individuals or organizations that in creating a Submission to the Hackathon, are acting on behalf of, and at the direction of, a Promotion Entity through a contractual or similar relationship.

***An affiliate is: (a) an organization that is under common control, sharing a common majority or controlling owner, or common management; or (b) an organization that has a substantial ownership in, or is substantially owned by the other organization.

4. How To Enter 

Entrants may enter by visiting difhackathon2024.devpost.com (“Hackathon Website”) and following the below steps:

• Register for the Hackathon on the Hackathon Website by clicking the “Join Hackathon” button. To complete registration, sign up to create a free Devpost account, or log in with an existing Devpost account. This will enable you to receive important updates and to create your Submission.

• Entrants will obtain access to the required developer tools/platform and complete a Project described below in Project Requirements. Use of the developer tools will be subject to the license agreement related thereto. Entry in the Hackathon constitutes consent for the Sponsor and Devpost to collect and maintain an Entrant’s personal information for the purpose of operating and publicizing the Hackathon.

• Complete and enter all of the required fields on the “Enter a Submission” page of the Hackathon Website (each a “Submission”) during the Submission Period and follow the requirements below.

Project Requirements

• What to Create: Entrants must create a working application that complies with the submission requirements of their chosen sponsor track and/or challenge within that track. All submissions must include tooling that utilizes the building blocks of the Decentralized Identity Foundation which are Decentralized Identifiers, (DIDs) and Verifiable Credentials (VCs) as per open standards at the W3C. (each a “Project”)

• Track and/or Challenge: 

• Education Track

• ZKP Track

• Reusable Identity Track

• Travel

• Verifiable File Storage

• Proof of Personhood Credentials

• Identity Based Access Controls for Private Files

• Truvity Challenge

• ArcBlock Challenge

• VIDOS Challenge

• TBD “Block” Challenge

• Ontology Challenge

• Crossmint: DIF Hackathon Challenge

•  

• Anonyome Labs Challenge 

• Personhood Credentials

• cheqd Challenge

• Extrimian Challenge: Secure Hotel Check-in System Using Verifiable Credentials (VC)

• PSE - Privacy Scaling Exploration Challenge

Due to the uniqueness of these two challenges, Decentralized Identifiers, (DIDs) and Verifiable Credentials (VCs) as per open standards at the W3C are not required. 

• Pinata

• NetSys| 

1. H&T SIG Challenge

Track and/or Challenge Information:

Sponsored by Job for the Future Foundation and Digital Credentials Consortium

This challenge set is part of the Education Track, and invites you to explore a future where access to education is available to any learner and where education opens the door to economic advancement. Challenges include:

• [C 1] Verifiable Learner/Worker IDs and Records Challenge

• In this challenge, we provide examples of Verifiable Credentials representing Student IDs, Employee IDs, and Employment History. The reward will go to the most compelling demonstration of transformation possible when people can control their own data, including learning and experiences. Example ideas include: using proof of employment history to apply to a new job, access to platforms, demonstration of essential skills, and applications of selective disclosure.

• [C 2] Powerful New VC Tools

• [C 2a] Multiple language support: promote mobility by allowing education credentials to be meaningfully used to access cross-border opportunities. This challenge must make use of the renderMethod attribute and enable VCs to provide multiple language support. Build a tool that lets people construct VCs in any language, especially those using non-Latin script.

• [C 2b] Browser Integration: improve convenience and usability for displaying and verifying VCs by building a browser plugin. This challenge must make use of the VC renderMethod attribute. 

• [C 3] Feature Enhancement

• [C 3a] Add support for the Learner Credential Wallet to use the VC renderMethod attribute to support rich displays of credentials in the application.

• [C 3b] Allow VerifierPlus to use the renderMethod attribute to support rich displays, including PDF

• [Bonus Design Challenge] Establishing Credibility in Digital Credentials: 

• Context: Verifying a digital credential like Verifiable Credentials involves a series of checks performed by software libraries. Some of these are common across all Verifiable Credentials, such as checking that the credential hasn’t been tampered with, hasn’t been revoked, etc. Other checks are specific to the use case, such as checking if the issuer is an authorized issuer of the credential type. 

• Challenge: The question is this – in a world where verifiers, or consumers of VCs, may be consuming a broad array of credentials, often with a human in the loop, how does the human know that the verification check is valid? What is the equivalent of the “browser padlock” for Verifiable Credentials? This challenge invites you to explore how organizations can integrate use of VCs into their processes in ways that humans can have confidence in the results.

• This challenge can be stacked on top of one of the above challenges, but not standalone.

Your demonstration must be open source, using the MIT license. 

It must meet technical interoperability standards used by JFF Plugfest. That includes:

• Credential Format: Open Badges 3.0

• This uses the Verifiable Credential format

• If your project issues credentials (use one of): 

• VC API, with CHAPI - Credential Handler API if needed, or

• OpenID for Verifiable Credential Issuance

• If your project exchange (“presents”) credentials (use one of):

• CHAPI - Credential Handler API + Verifiable Presentation Request, or

• OpenID for Verifiable Presentations, or

• WACI-DIDComm Interop Profile

• You may reuse and build on top of the tools provided by the Plugfest, including:

• VC Playground

• CHAPI - Credential Handler API 

• Digital Credentials Consortium Wallet

Additional resources are available here at the JFF Plugfest 3 site

In addition to W3C-compliant verifiable credentials you submission must include. 

• 3-minute video describing what the app does and provide a URL to a public code repository.

• Text description of the project’s features and functionality.

• Explanation of how DIDs, VCs, and other requirements were used.

—---

ZKP Track

This track aims to foster innovation and collaboration among developers, researchers, and industry experts to advance the use of programable cryptography in digital identity solutions.

1. Innovate with ZKPs, MPC, FHE: Develop creative applications using programable cryptography to enhance privacy, security, and interoperability in SSI systems.

2. Collaborate and Learn: Engage with zkp experts to learn about best practices, existing tools, and solutions.

1. Solidity verifier for BBS+.

2. Build a GPC builder + visualizer.

3. MPC for recovery (privacy-preserving social recovery system).

4. MPC for credentials that need to be issued by multiple parties.

5. Decentralized PKI infra.

Link to a list of identity projects in PSE that could be valuable additions to your hackathon projects. These projects primarily offer SDKs for developers to integrate privacy-preserving user authentication or port verifiable data into their apps. [https://pse-team.notion.site/PSE-x-DIF-Hackathon-1356b2848b1c4ba89f5aaf73d9ce0d53]

Submission Requirements

• W3C-compliant verifiable credentials.

• 3-minute video describing what the app does and provide a URL to a public code repository.

• Text description of the project’s features and functionality.

• Explanation of how DIDs, VCs, and other requirements were used.

—---

Reusable Identity Track

Pinata Challenges: File-Based Identity Solutions

Challenges include:

● Verifiable File Storage. Associate files to users via verifiable credentials. Both files and

verifiable credential metadata can be stored publicly or privately using Pinata’s

immutable Files API. In this challenge, you will demonstrate your creativity in using

immutability and verifiable content hashes to solve a real-world problem.

● Proof of Personhood Credentials. In this open-to-interpretation challenge, we want

to see creative solutions to personhood credentials that leverage immutable file storage.

Participants can use private file storage through Pinata’s Files API or public file storage

through Pinata’s IPFS pinning service.

● Identity-Based Access Controls For Private Files. Access controls are one of

software’s ongoing challenges. In this challenge, participants should build an

identity-based access control system for retrieving files stored privately on Pinata’s Files

API. Note, this challenge should not use IPFS as IPFS is a public network. This should

make use of private file storage through the Files API.

Submission requirements

● Must use Pinata to store and serve files: Each submission must use Pinata for file

storage and retrieval. Depending on the challenge, participants may be able to use IPFS

and private files or just private files..

● Must focus on solving real-world problems: Submissions should focus on practical

use cases and leverage creative solutions that include Pinata’s file APIs.

• 3-minute video describing what the app does and provide a URL to a public code repository.

• Text description of the project’s features and functionality.

Tooling: 

Docs: https://docs.pinata.cloud

Website: https://pinata.cloud

App/Signup: https://app.pinata.cloud 

—-

ArcBlock Challenge

Overview:

This track encourages participants to explore how DID/VC can be applied to real-world

scenarios to address practical problems using ArcBlock's technology stack.

Challenge

Dive into the world of decentralized identity (DID) and verifiable credentials (VC) with ArcBlock's

technology stack. This track challenges participants to develop innovative applications that

solve real-world problems, leveraging the power of DID/VC to enhance privacy, security, and

user experience in practical scenarios.

The application can be anything; the only requirement is that it must utilize DID/VC and the

ArcBlock technology stack

Additional:

All participants will receive:

• A DID/VC based digital badge of “Proof of Participation”

All winning projects will receive:

• A DID/VC based digital certificate of winning

• Showcase in ArcBlock’s official blog, twitter and other social media accounts.

• Projects that can actually be useful will be accepted into ArcBlock’s official

Blocklet Store

Submission requirements

● Must use W3C-compliant verifiable credentials

● 3 minute video describing what the app does and URL to public code repository

● Include a text description that should explain the features and functionality of your

Project.

● Provide a text description of how the DIDs, VCs, and other requirements were used

● Use ArcBlock’s technology stack to build the application (include: DID:Connect,

DID:Spaces, DID:Wallet, Blocklet, AIGNE etc.)

Tooling:  https://www.arcblock.io/docs/hackathon/en/dif-hackathon-2024 

Our dedicated community board for Q&A, tech support : https://community.arcblock.io/discussions/boards/hackathon-support 

—-

Overview: This track invites participants to explore how decentralized identity and verifiable credentials can streamline complex eKYC processes and digital identity management using self-sovereign identity solutions. The challenges focus on building innovative applications that simplify the journey of individuals like Miko, an expat moving to Amsterdam, by leveraging digital wallets, to-do lists, and interlinked verifiable credentials.

To build the applications you need to leverage the Truvity SDK (available in TypeScript and Java).

Challenge Description

Miko, a talented backend developer from outside of Europe, is relocating to Amsterdam to join a small yet ambitious startup to develop a cutting-edge Self-Sovereign Identity solution. Amsterdam, the new Verifiable Credentials capital, has a relatively new requirement: all documents in legally-binding processes should be exchanged in the form of Verifiable Credentials between Digital Identity Wallets (both for businesses and retail users). Her Digital Identity Wallet with an embedded to-do list is the key to navigating the complex process of settling as an expat. The wallet's to-do list guides Miko through each step, ensuring that she gathers and submits all required verifiable credentials (VCs) from the right issuers.

The to-do list is pre-configured to:

• Know all necessary issuers and where to send collected credentials for verification and further actions.

• Ensure that some issuers, particularly for more complex processes, only accept interlinked VCs, meaning Miko can’t submit non-linked credentials, ensuring that the integrity of her data is maintained across all processes.

Note: The Municipality of Amsterdam fully controls the document issuance in Amsterdam, therefore all businesses and municipal workers must use the municipality's platform and issue VCs on its behalf.

Miko's To-Do List:

1. Obtain an Employment Contract

• VC: Employment Offer Letter

• The to-do list prompts Miko to receive and store this VC from her new employer.

1. Apply for and Receive a Visa

• VCs:  

• Proof of Identity  

• Employment Contract  

• Proof of Financial Stability  

• Drafts: Allow Miko to begin the process while gathering necessary documents. The visa application can’t be submitted until all relevant VCs are linked.

1. Register with the Municipality

• VCs:

• Employment Contract  

• Proof of Identity

• Birth Certificate  

• The to-do list automatically guides Miko through the residency registration process.

1. Open a Bank Account

• VCs:  

• Proof of Registration issued by the municipality

• Employment Contract  

• Proof of Identity  

• Bank institutions that are integrated with the wallet’s interlinked VCs require a full set of linked documents to open her account.

1. Secure Housing and Sign a Rental Agreement

• VCs:

• Employment Contract  

• Proof of Identity  

• Bank Account Details  

• The final task, completing her journey with signing a rental agreement, depends on all the previous linked VCs in her wallet.

What we are looking for:

• eKYC with Reusable Identity is a complex process involving many actors, processes, and documents. You can model the process from the perspective of an Issuer or a Relying Party (Verifier), but the most interesting part would be building the Expat Wallet that orchestrates the entire flow using a pre-built To-Do List.

• We've created many features to simplify this journey. Review them all and use as many as possible in your solution.

• You don’t need to focus on the real content of the documents; feel free to model them with few fields found online.

Challenge Description

Building on the journey in Challenge 1, this second challenge focuses on the role of a Compliance Officer in the process of verifying and approving the credentials Miko submits. You may model just a part of the whole process (as well as Miko's wallet, it shouldn't even have the UI).

In Step 4, Miko submits her documents to open a bank account. These documents include:

• Proof of Registration from the Municipality  

• Employment Contract

• Proof of Identity

• Proof of Address

The task is to build a simple Compliance Officer Panel (webpage) where:

• Miko's submitted VCs are received by the bank's compliance officer.

• The compliance officer reviews the documents, approves or rejects them, and logs the decision.

• On approval, the officer issues a new VC (e.g., “Bank Account Information") and sends it back to Miko’s Digital Wallet.

Key Features:

• The panel allows the compliance officer to view and review interlinked VCs.

• The panel allows the compliance officer to search through received VCs and their content.

• The panel provides clear options for approval or rejection of each document.

• The VCs are interconnected, and documents can’t be reviewed or approved unless all linked VCs are present.

• Must use W3C-compliant verifiable credentials

• 3 minute video describing what the app does and URL to public code repository

• Include a text description that should explain the features and functionality of your Project.

• Provide a text description of how the DIDs, VCs, and other requirements were used

Tooling: https://www.truvity.com/blog/dif-hackathon-2024

—--

Overview: This track invites participants to explore how decentralized identity, specifically leveraging DIDs (Decentralized Identifiers) and VCs (Verifiable Credentials), can be applied to innovative use cases in recruitment and reusable ID. Participants will utilize the Vidos tech stack and other tools from our partner network to build solutions that enhance security, efficiency, and user control in these domains.

Develop a proof-of-concept ‘employer portal’ that enables recruiters to identify, verify, and onboard candidates through a seamless, decentralized identity system. The portal should integrate DID-based identity management and support the issuance and verification of VCs to streamline the hiring process. 

Key features include:

• Candidate Identification: Use credentials such as education and skills-based certifications to match candidates to suitable roles.

• Qualification Verification: Implement secure methods to verify candidate qualifications and identity using VCs.

• Onboarding Automation: Create a user-friendly onboarding interface that leverages VCs for streamlined processes.

• Innovative Training Paths: Design training programs tailored to the skills of new hires, incorporating credential issuance.

Example use cases:

• Matching candidates to job openings based on verified skills and qualifications.

• Automating the verification of educational and professional credentials.

• Creating a marketplace for qualification issuers and recruitment agencies.

Develop a proof-of-concept solution that demonstrates the flexibility and interoperability of Verifiable Credentials (VCs) across multiple scenarios. Your solution should showcase how a single VC can be reused in different contexts, such as using a passport for both travel access and age-gated entry. Additionally, the solution should be capable of verifying similar credentials VCs from different issuers, e.g. passport credentials issued by different national authorities - highlighting the versatility of VCs in various real-world applications.

Key features:

• Interaction with Issuer: Integrate with a VC issuer (e.g., TBD) and leverage the Vidos tech stack to retrieve and verify the VC, ensuring seamless interaction between the issuer and the verifier.

• Multiple Issuers: Implement functionality to work with multiple VC issuers, creating and verifying credentials from different sources using the Vidos tech stack. This should demonstrate the interoperability of VCs across various issuers.

• VC Verification: Ensure that the solution accurately verifies the correct VC for the given scenario, maintaining high security and reliability standards.

• User Design: Design an intuitive interface that allows users to easily select which VC they wish to use in a given situation, enhancing the user experience and demonstrating the practical application of reusable VCs.

• Must use W3C-compliant verifiable credentials.

• 3-minute video describing what the app does and provide a URL to a public code repository.

• Text description of the project’s features and functionality.

• Explanation of how DIDs, VCs, and other requirements were used.

• Integration with the Vidos tech stack.

Tooling: https://vidos.id/digital-identity-hack-pack

—

TBD (Block) Challenge

tbDEX is an open messaging protocol that enables liquidity seekers to connect with liquidity providers. This means that as a liquidity provider, your business can be the backend supplier in several payment applications. 

Performing KYC on repeat customers every time they attempt to transact with you from a different payment app would be a pain. To avoid this, you will use the Web5 SDK to issue a Known Customer Credential (KCC) to a customer, Alice, who you have already completed KYC on. You will store the JWT representing the KCC in Alice’s Decentralized Web Node so that she can present it to your business from any payment app. 

Challenge 

1. Create a Decentralized Identifier (DID) and DWN to use as the Issuer. 

1. Bonus: Use the DIF community DWN instance hosted by Google Cloud.

2. Issue Alice a KCC that includes evidence. Note that for this challenge, you do not need to implement an actual identity verification flow. 

3. Install the VC Protocol onto your DWN so that you can communicate with Alice’s DWN. 

4. Obtain permission to write to Alice’s DWN by sending a GET request to https://vc-to-dwn.tbddev.org/authorize?issuerDid=${issuerDidUri} 

5. Store the VC JWT of the KCC as a record in Alice’s DWN. 

Submit 

DWN Record ID of the KCC 

Resources 

1. Alice’s DID: did:dht:rr1w5z9hdjtt76e6zmqmyyxc5cfnwjype6prz45m6z1qsbm8yjao 2. web5/credentials SDK 

3. web5/api SDK 

4. How to create a DID and DWN with Web5.connect() 

5. Obtain Bearer DID - required to sign VCs 

6. Known Customer Credential Schema 

7. How to issue a VC with Web5 

8. Example of issuing a KCC with Web5 

9. Example of issued KCC 

10. How to install a DWN Protocol 

11. How to store a VC in a DWN 

Contact Us 

If you have any questions or need any help, please reach out to us in our #kcc-hackthon channel on Discord

—-

Ontology Challenge

ONT Login is a decentralized universal authentication login component that helps developers shield the details of authentication implementation, and can quickly bring a Web 3.0 secure login experience to enterprises and services. It gives a great presentation of how reuseable identity can be applied in any Web2 / Web3 applications with the protection of users data and privacy. Currently, users need to log into the service via ONT ID. It is fully open source and supports multi-SDKs.

To optimize the developers’ building experience, as well as demonstrate its easy integration with any single app. We are inviting the developers to

• Make repo for the relevant technical documentation or its SDKs.

• Or provide a demo case for integrating ONT Login to their existing applications, say setting ONT Login as one of their user login methods.

You can find more information via:

• Official website: https://login.ont.id/,

• Documentation: https://docs.ont.io/decentralized-identity-and-data/ontid/ont-login

• Back-end SDK: https://github.com/ont-id/ontlogin-sdk-go 

• Front-end SDK： https://github.com/ont-id/ontlogin-sdk-js

Submission Requirements

• Must use W3C-compliant verifiable credentials.

• 3-minute video describing what the app does and provide a URL to a public code repository.

• Text description of the project’s features and functionality.

• Explanation of how DIDs, VCs, and other requirements were used.

—-

Crossmint: DIF Hackathon Challenge

Track: Reusable Identity

Overview

This track explores the concept of reusable digital identities that can streamline various

processes such as KYC (Know Your Customer), KYB (Know Your Business), reusable claims for

compliance, and age verification. The goal is to create robust and secure identity solutions that

can be reused across different platforms and services.

Challenge

Leverage Crossmint’s Verifiable Credentials API to develop a reusable identity solution that

addresses the challenges of identity verification and compliance in various sectors. The solution

should emphasize security, privacy, and ease of use for both individuals and organizations.

Examples

• KYC/KYB Processes: Build a platform that allows individuals and businesses to create

a reusable digital identity for KYC/KYB purposes, making it easy to verify identity across

different financial institutions or platforms without repeatedly submitting documents.

• Age Verification: Create a digital identity solution that provides age verification

capabilities for online platforms, such as gaming or content services, ensuring

compliance with age-related regulations without revealing unnecessary personal

information.

• Anti-Money Laundering (AML) Compliance: Design a system that uses reusable

credentials to streamline AML checks for financial transactions, reducing friction and

ensuring compliance without compromising user privacy.

Tooling: https://docs.crossmint.com/verifiable-credentials/introduction

Submission requirements

● Must use W3C-compliant verifiable credentials

● 3 minute video describing what the app does and URL to public code repository

● Include a text description that explains the features and functionality of your Project.

● Provide a text description of how the DIDs, VCs, and other requirements were used

—

NetSys| H&T SIG Challenge

Overview: Explore how Decentralised Identity technology combined with traditional travel tech

can help make travel more enjoyable and rewarding for everyone.

Challenge: Friction-free travel using traveler personal data and preferences

Using the power of Decentralized Identity technology, demonstrate one or more steps in a future,

frictionless and connected travel journey (looking->booking->arriving->enjoying->departing-

reminiscing->returning). Teams should demonstrate the reusability and portability of traveler

information along the travel journey and the benefits accruing to the traveler, travel providers

(Transport. Accommodation, tourism etc.) or destination (the location in which the travel takes

place).

Submission requirements: 

• ● Must use W3C-compliant verifiable credentials

• ● 3-minute video describing what the app does and URL to public code repository

• ● Include a text description that should explain the features and functionality of your

• Project.

• ● Provide a text description of how the DIDs, VCs, and other requirements were used

Sponsor-defined additional submission requirements:

• A profile is to be used to specify traveler personal data and preferences which may be

self-attested by the traveler.

• Teams can use a traveler profile of their own design or may use preferences and

DIDComm services provided by Autoura.me. Details follow:

Autoura provides three DID enabled services:

1. Consumer hospitality & travel preferences (food, drinks, accessibility, transport,

general travel requirements)

2. Traveler current location

3. Two-way DIDComm messaging

Use these preferences to personalize your perfect frictionless connected trip!

These services should work when called from all publicly resolvable DIDs. Example code

using the TBD platform is available via GitHub to help you get up and running quickly.

Autoura’s Alex Bainbridge will be available via DIF discord or email Autoura DevHelp at

(devhelp@autoura.com) to help answer your questions.

Autoura Developer documentation https://www.autoura.com/docs/api/profiles

TBD Example code https://github.com/Autoura/TBDdemo

• Sponsor Prizes: All projects will be submitted for Sponsor Prizes, and must follow the specific requirements listed in section 8. Prizes.

• Functionality: The Project must be capable of being successfully installed and running consistently on the platform for which it is intended and must function as depicted in the video and/or expressed in the text description.

• Platforms: A submitted Project must run on the platform for which it is intended and which is specified in the Submission Requirements. 

• New & Existing: Projects must be either newly created by the Entrant or, if the Entrant’s Project existed prior to the Hackathon Submission Period, must have been significantly updated after the start of the Hackathon Submission Period. Entrants should explain how their Project was significantly updated during the Submission Period.

• Third Party Integrations: If a Project integrates any third-party SDK, APIs and/or data, Entrant must be authorized to use them in accordance with any terms and conditions or licensing requirements of the tool.

—-

Overview

This challenge encourages participants to create innovative solutions using Personhood Credentials (PHCs) based on the W3C Verifiable Credentials standard. The challenge focus is to build solutions that demonstrate privacy, security, and usability of PHCs in decentralized identity ecosystems.

Background Reading: “Personhood credentials: Artificial intelligence and the value of privacy-preserving tools to distinguish who is real online”  https://arxiv.org/pdf/2408.07892 

Design and implement a privacy-preserving approach to PHCs.  Submissions should demonstrate the following PHC capabilities:

1. Credential Issuance: demonstrate PHC issuance using the following guarantees

1. Credential Limits: One PHC is issued per person (e.g., ensure not duplicates are created for a single individual) 

2. (Optional) Unlinkable Pseudonymity (privacy): enable a user to interact with services anonymously through a service-specific pseudonym 

2. Credential Verification: Zero Knowledge Proofs: demonstrate a holder proving possession of a PHC containing one or more elements contained in the credential schema without disclosing the element itself.  Capabilities may also include selective disclosure, unlinkable disclosure, or non-correlatable identification of holder or subject.

3. PHC Usage:  demonstrate PHC usage through one of the DIF foundational standards (e.g., DIDComm)

4. (Optional) Aries Cloud Agent – Python integration:  demonstrate integrating PHC functionality within ACA-Py 

5. (Optional) AnonCreds Implementation:  demonstrate PHC implementation using the AnonCreds Specification.

• Must use W3C-compliant verifiable credentials (conforming to the W3C Verifiable Credentials Data Model ver 2.0 is preferred, although ver 1.1 is acceptable)

• 3-minute video describing what the app does 

• URL to public code repository with source code licensed using the Apache License, ver 2.0.  One intent of this challenge is to contribute the created source code to the identity community.  

• Include a text description that should explain the features and functionality of your Project.

• Provide a text description of how the VCs and other requirements were used

• Participants are encouraged to explore the integration of foundational standards such as Decentralized Identifiers (DIDs) and DIDComm.

• Participants are encouraged to use the provided PHC Schema in their solutions.

• Code submissions are encouraged to use:  Rust, Python, and/or TypeScript

—-

cheqd Challenge

“Harnessing Decentralized Identity for Verifiable AI”

Overview

In a world where generative AI is increasingly a part of our lives, ensuring the authenticity and trustworthiness of data is crucial. Our challenge for you is to use cheqd’s decentralized identity stack to build Verifiable AI concept solutions that tackle emerging societal and technical challenges.

Potential Examples

Our blog post on the potential of decentralized identity in Verifiable AI offers ideas on sample use cases and applications where we think decentralised identity can restore trust in the age of AI: 

Content credentials (“How much of this content was AI or human generated?”): Content Credentials are an emerging standard using Verifiable Credentials that can capture a “chain-of-custody” of how much of an image (or video/audio) was human-generated or AI-generated, which can help people understand whether to trust a particular content or not. 

Proof of Personhood: Use Verifiable Credentials to capture whether a person is real, to varying levels of “personhood”: a “basic” level could be a credential that states someone is a human (like CAPTCHA), a more “advanced” level would be “it’s this specific person with legal identity”.

Proof of “Authorised AI Agent”: Just like “Know Your Customer” (KYC), we believe people will authorise generative AI agents to not just come up with text, but plan actions on their behalf. For example, describing to an AI agent your holiday budget and preferences, and it makes bookings on your behalf. A “Proof of AI Agent” will help sites understand if this is a “good” AI bot that’s been authorised by a human,  vs a “bad” AI bot.

Documentation 

Tooling

Submission requirements

• Must utilize W3C-compliant Verifiable Credentials.

• Must use the cheqd Network through cheqd DID method (did:cheqd) and/or cheqd DID-Linked Resources

• Reference or use of the CHEQ token is a nice-to-have (points for referencing how you would incorporate it in a scaled-up version)

• Include a 3-minute video describing the application and its functionality.

• Provide a URL to a public code repository in GitHub

• Include a text description detailing the features and functionality of the project.

• Explain how Decentralized Identifiers (DIDs), VCs, and other requirements were integrated into the solution.

• Ensure submission includes a project description, video, and a README file in the repository. 

• Must have a clear opportunity for to create a sustainable commercial model, but it does not need this to be built in

—--

Extrimian Challenge: Secure Hotel Check-in System Using Verifiable Credentials (VC)

Problem Statement:

Hotels handle sensitive guest information during the check-in process, making security a top priority. Your challenge is to design a secure check-in system for hotels that leverages Verifiable Credentials (VC) issued by the government. The government of the guest's country will issue a VC Passport for travelers, and when they check into a hotel, the hotel will verify their credential and check its status from a list (valid, invalid, or under review). This ensures a seamless, secure, and privacy-focused check-in process.

Requirements:

• Use ID Connect by Extrimian to create both the credential issuer (government) and verifier (hotel).

• The system must include the following components:

• Credential Issuer: The government entity issues the VC Passport to the traveler.

• Credential Verifier: The hotel validates the VC when a guest checks in, ensuring it is genuine and up-to-date.

• Status Check: The system should check the credential’s status from a status list

• Upon successful verification, the guest is cleared to check in.

References and Documentation:

• How to use ID Connect: YouTube Playlist (Check meetings 3 - Issuer and 4 - Verifier for key functionalities)

• ID Connect Demo: Extrimian Demo

• Documentation: Extrimian SSI Service API Documentation

• Extrimian Academy: https://extrimian.io/academy/

Submission Requirements 

Submissions to the Hackathon must meet the following requirements:

• Include a Project built with the required developer tools for the challenge or track you select and meets the specific  Project Requirements for that challenge or track.

• Include a text description that should explain the features and functionality of your Project.

• Provide a text description of how the DIDs and VCs were used

• Include a demonstration video of your Project. The video portion of the Submission:

• should be less than three (3) minutes. Judges are not required to watch beyond three minutes 

• should include footage that shows the Project functioning on the device for which it was built

• must be uploaded to and made publicly visible on YouTube, Vimeo, Facebook Video, or Youku, and a link to the video must be provided on the Submission form on the Hackathon Website; and

• must not include third party trademarks, or copyrighted music or other material unless the Entrant has permission to use such material.

• URL to a functional demo app OR URL to public code repository

Multiple Submissions 

An Entrant may submit more than one Submission, however, each Submission must be unique and substantially different from each of the Entrant’s other Submissions, as determined by the Sponsor and Devpost in their sole discretion.

Submission ownership 

Be the original work of the Entrant, be solely owned by the Entrant, and not violate the IP rights of any other person or entity.

Testing 

Access must be provided to an Entrant’s working Project for judging and testing by providing a link to a website, functioning demo, or a test build. If Entrant’s website is private, Entrant must include login credentials in its testing instructions.The Entrant must make the Project available free of charge and without any restriction, for testing, evaluation and use by the Sponsor, Administrator and Judges until the Judging Period ends. Judges are not required to test the Project and may choose to judge based solely on the text description, images, and video provided in the Submission.

If the Project includes software that runs on proprietary or third party hardware that is not widely available to the public, including software running on devices or wearable technology other than smartphones, tablets, or desktop computers, the Sponsor and/or Administrator reserve the right, at their sole discretion, to require the Entrant to provide physical access to the Project hardware upon request.  For Projects running on widely available smartphones, tablets, or desktop computers, Entrants may make their Project available using one of the following methods: 

• Android Applications: 

• Upload an .apk file on the Enter a Submission form or provide a link for downloading the Project in the “Testing Instructions” field on the Enter a Submission form.

• iOS Applications: 

• If your Project is available on the iTunes App Store provide a link on your submission form. If you charge a fee for downloading your Project, you must provide a promo code.

• If your Project is not yet publicly available on the iTunes App Store, you must send a test build to testing@devpost.com before the end of the Hackathon Submission Period iTunes TestFlight: https://developer.apple.com/testflight/ TestFlight / iTunes Connect: Enter the Administrator’s email address to share a build for testing. The Administrator’s TestFlight account email is: decentralized.identity@gmail.com. 

• Web/Mobile Web: Provide a link for accessing your Project on the “Testing Instructions” field on the Enter a Submission form.

Language Requirements

All Submission materials must be in English or, if not in English, the Entrant must provide an English translation of the demonstration video, text description, and testing instructions as well as all other materials submitted. 

Team Representation

If a team or organization is entering the Hackathon, they must appoint and authorize one individual (the “Representative”) to represent, act, and enter a Submission, on their behalf. The Representative must meet the eligibility requirements above. By entering a Submission on the Hackathon Website on behalf of a team or organization you represent and warrant that you are the Representative authorized to act on behalf of your team or organization.

Intellectual Property 

Your Submission must: (a) be your (or your Team, or Organization’s) original work product; (b) be solely owned by you, your Team, your Organization with no other person or entity having any right or interest in it; and (c) not violate the intellectual property rights or other rights including but not limited to copyright, trademark, patent, contract, and/or privacy rights, of any other person or entity. An Entrant may contract with a third party for technical assistance to create the Submission provided the Submission components are solely the Entrant’s work product and the result of the Entrant’s ideas and creativity, and the Entrant owns all rights to them. An Entrant may submit a Submission that includes the use of open source software or hardware, provided the Entrant complies with applicable open source licenses and, as part of the Submission, creates software that enhances and builds upon the features and functionality included in the underlying open source product. By entering the Hackathon, you represent, warrant, and agree that your Submission meets these requirements.

Financial or Preferential Support 

A Project must not have been developed, or derived from a Project developed, with financial or preferential support from the Sponsor or Administrator. Such Projects include, but are not limited to, those that received funding or investment for their development, were developed under contract, or received a commercial license, from the Sponsor or Administrator any time prior to the end of Hackathon Submission Period. The Sponsor, at their sole discretion, may disqualify a Project, if awarding a prize to the Project would create a real or apparent conflict of interest.

5. Submission Modifications

Draft Submissions 

Prior to the end of the Submission Period, you may save draft versions of your Submission on Devpost to your portfolio before submitting the submission materials to the Hackathon for evaluation. Once the Submission Period has ended, you may not make any changes or alterations to your Submission, but you may continue to update the Project in your Devpost portfolio.

Modifications 

After the Submission Period. The Sponsor and Devpost may permit you to modify part of your Submission after the Submission Period for the purpose of adding, removing or replacing material that potentially infringes a third party mark or right, discloses personally identifiable information, or is otherwise inappropriate. The modified Submission must remain substantively the same as the original Submission with the only modification being what the Sponsor and Devpost permits. 

6. Judges & Criteria

Eligible Submissions will be evaluated by a panel of judges selected by the Sponsor (the “Judges”). Judges may be employees of the Sponsor or third parties, may or may not be listed individually on the Hackathon Website, and may change before or during the Judging Period. Judging may take place in one or more rounds with one or more panels of Judges, at the discretion of the Sponsor. 

Stage One) The first stage will determine via pass/fail whether the ideas meet a baseline level of viability, in that the Project reasonably fits the theme and reasonably applies the required APIs/SDKs featured in the Hackathon.

Stage Two) All Submissions that pass Stage One will be evaluated in Stage Two based on the following equally weighted criteria (the “Judging Criteria”):

Entries will be judged on the following equally weighted criteria, and according to the sole and absolute discretion of the judges:

• Functionality
  How well the app performs and fulfills its intended purpose.

• Feasibility
  Can this app be feasibly implemented and used in the real world?

• Scalability
  Could it scale for wide adoption?

• Technical Complexity
  The level of technical expertise and complexity demonstrated in the implementation.

• Creativity and Innovation
  How original is the idea? Does the submission use the technology in a unique way not seen before?

• User Experience

Intuitiveness, ease of use and overall user friendliness.

• Presentation
  How well the team presented their work through video, documentation and code quality. (Is your code tidy and easy to understand)

The scores from the Judges will determine the potential winners of the applicable prizes. The Entrant(s) that are eligible for a Prize, and whose Submissions earn the highest overall scores based on the applicable Judging Criteria, will become potential winners of that Prize.

Tie Breaking 

For each Prize listed below, if two or more Submissions are tied, the tied Submission with the highest score in the first applicable criterion listed above will be considered the higher scoring Submission. In the event any ties remain, this process will be repeated, as needed, by comparing the tied Submissions’ scores on the next applicable criterion. If two or more Submissions are tied on all applicable criteria, the panel of Judges will vote on the tied Submissions.

7. Intellectual Property Rights

All Submissions remain the intellectual property of the individuals or organizations that developed them. By submitting an entry, entrants agree that the Sponsor will have a fully paid, non-exclusive license to use such entry for judging the entry. Entrants agree that the Sponsor and Devpost shall have the right to promote the Submission and use the name, likeness, voice and image of all individuals contributing to a Submission, in any materials promoting or publicizing the Hackathon and its results, during the Hackathon Period and for three years thereafter.  Some Submission components may be displayed to the public. Other Submission materials may be viewed by the sponsor, Devpost, and judges for screening and evaluation. By submitting an entry or accepting any prize, entrants represent and warrant that (a) submitted content is not copyrighted, protected by trade secret or otherwise subject to third party intellectual property rights or other proprietary rights, including privacy and publicity rights, unless entrant is the owner of such rights or has permission from their rightful owner to post the content; and (b) the content submitted does not contain any viruses, Trojan horses, worms, spyware or other disabling devices or harmful or malicious code.

8. Prizes

IMPORTANT NOTES ON MULTIPLE PRIZE ELIGIBILITY:

A submission can be eligible for multiples prizes, including across multiple track as long as it meets the sponsor criteria. 

NOTE: Conversion prices from USD to [currency] will be calculated on the closing market price according to CoinGecko on the Winner Announcement date. Cryptocurrency is subject to a high degree of risk, volatility and illiquidity. Participants should make their own investigations and evaluations of any cryptocurrency that will be delivered pursuant thereto. Participants should inform themselves as to the legal requirements applicable to them in respect of the acquisition, holding and disposition of cryptocurrency and upon delivery, and as to the income and other tax consequences to them of such acquisition, holding and disposition.

1. Substitutions & Changes: Prizes are non-transferable by the winner. Sponsor in its sole discretion has the right to make a prize substitution of equivalent or greater value. Sponsor will not award a prize if there are no eligible Submissions entered in the Hackathon, or if there are no eligible Entrants or Submissions for a specific prize.

2. Verification Requirement: THE AWARD OF A PRIZE TO A POTENTIAL WINNER IS SUBJECT TO VERIFICATION OF THE IDENTITY, QUALIFICATIONS AND ROLE OF THE POTENTIAL WINNER IN THE CREATION OF THE SUBMISSION. No Submission or Entrant shall be deemed a winning Submission or winner until their post-competition prize affidavits have been completed and verified, even if prospective winners have been announced verbally or on the competition website. The final decision to designate a winner shall be made by the Sponsor and/or Administrator. Deadline for Returning Required Forms: ten (10) business days after the Required Forms are sent. Failure to return the required forms may result in disqualification. Failure of the winner to return the paperwork in more than three months will result in forfeiture of the prize.

3. Prize Delivery: Prizes will be payable to the Entrant, if an individual; to the Entrant’s Representative, if a Team; or to the Organization, if the Entrant is an Organization. It will be the responsibility of the winning Entrant’s Representative to allocate the Prize among their Team or Organization’s participating members, as the Representative deems appropriate. A monetary Prize will be mailed to the winning Entrant’s address (if an individual) or the Representative’s address (if a Team or Organization), or sent electronically to the Entrant, Entrant’s Representative, or Organization’s bank account, only after receipt of the completed winner affidavit and other required forms (collectively the “Required Forms”), if applicable. The deadline for returning the Required Forms to the Administrator is ten (10) business days after the Required Forms are sent. Failure to provide correct information on the Required Forms, or other correct information required for the delivery of a Prize, may result in delayed Prize delivery, disqualification of the Entrant, or forfeiture of a Prize. Prizes will be delivered within 60 days of the Sponsor or Devpost’s receipt of the completed Required Forms.

4. Fees & Taxes: Winners (and in the case of Team or Organization, all participating members) are responsible for any fees associated with receiving or using a prize, including but not limited to, wiring fees or currency exchange fees. Winners (and in the case of Team or Organization, all participating members) are responsible for reporting and paying all applicable taxes in their jurisdiction of residence (federal, state/provincial/territorial and local). Winners may be required to provide certain information to facilitate receipt of the award, including completing and submitting any tax or other forms necessary for compliance with applicable withholding and reporting requirements. United States residents may be required to provide a completed form W-9 and residents of other countries may be required to provide a completed W-8BEN form. Winners are also responsible for complying with foreign exchange and banking regulations in their respective jurisdictions and reporting the receipt of the Prize to relevant government departments/agencies, if necessary. The Sponsor, Devpost, and/or Prize provider reserves the right to withhold a portion of the prize amount to comply with the tax laws of the United States or other Sponsor jurisdiction, or those of a winner’s jurisdiction.

9. Entry Conditions and Release

1. By entering the Hackathon, you (and, if you are entering on behalf of a Team, Organization each participating members) agree(s) to the following:

1. The relationship between you, the Entrant, and the Sponsor and Administrator, is not a confidential, fiduciary, or other special relationship.

2. You will be bound by and comply with these Official Rules and the decisions of the Sponsor, Administrator, and/or the Hackathon Judges which are binding and final in all matters relating to the Hackathon.

3. You release, indemnify, defend and hold harmless the Promotion Entities, and their respective parent, subsidiary, and affiliated companies, the Prize suppliers and any other organizations responsible for sponsoring, fulfilling, administering, advertising or promoting the Hackathon, and all of their respective past and present officers, directors, employees, agents and representatives (hereafter the “Released Parties”) from and against any and all claims, expenses, and liabilities (including reasonable attorneys’ fees), including but not limited to negligence and damages of any kind to persons and property, defamation, slander, libel, violation of right of publicity, infringement of trademark, copyright or other intellectual property rights, property damage, or death or personal injury arising out of or relating to a Entrant’s entry, creation of Submission or entry of a Submission, participation in the Hackathon, acceptance or use or misuse of the Prize (including any travel or activity related thereto) and/or the broadcast, transmission, performance, exploitation or use of the Submission as authorized or licensed by these Official Rules. 

2. Without limiting the foregoing, the Released Parties shall have no liability in connection with: 

1. Any incorrect or inaccurate information, whether caused by the Sponsor or Administrator’s electronic or printing error, or by any of the equipment or programming associated with or utilized in the Hackathon; 

2. Technical failures of any kind, including, but not limited to malfunctions, interruptions, or disconnections in phone lines, internet connectivity or electronic transmission errors, or network hardware or software or failure of the Hackathon Website;

3. Unauthorized human intervention in any part of the entry process or the Hackathon;

4. Technical or human error which may occur in the administration of the Hackathon or the processing of Submissions; or 

5. Any injury or damage to persons or property which may be caused, directly or indirectly, in whole or in part, from the Entrant’s participation in the Hackathon or receipt or use or misuse of any Prize.

The Released Parties are not responsible for incomplete, late, misdirected, damaged, lost, illegible, or incomprehensible Submissions or for address or email address changes of the Entrants. Proof of sending or submitting the aforementioned will not be deemed to be proof of receipt by the Sponsor or Administrator. If for any reason any Entrant’s Submission is determined to have not been received or been erroneously deleted, lost, or otherwise destroyed or corrupted, the Entrant’s sole remedy is to request the opportunity to resubmit its Submission. Such a request must be made promptly after the Entrant knows or should have known there was a problem and will be determined at the sole discretion of the Sponsor.

10. Publicity

By participating in the Hackathon, Entrant consents to the promotion and display of the Entrant’s Submission, and to the use of personal information about themselves for promotional purposes, by the Sponsor, Administrator, and third parties acting on their behalf. Such personal information includes, but is not limited to, your name, likeness, photograph, voice, opinions, comments and hometown and country of residence. It may be used in any existing or newly created media, worldwide without further payment or consideration or right of review, unless prohibited by law. Authorized use includes but is not limited to advertising and promotional purposes. 

11. General Conditions 

1. Sponsor and Administrator reserve the right, in their sole discretion, to cancel, suspend and/or modify the Hackathon, or any part of it, in the event of a technical failure, fraud, or any other factor or event that was not anticipated or is not within their control.

2. Sponsor and Administrator reserve the right in their sole discretion to disqualify any individual or Entrant if it finds to be actually or presenting the appearance of tampering with the entry process or the operation of the Hackathon or to be acting in violation of these Official Rules or in a manner that is inappropriate, unsportsmanlike, not in the best interests of this Hackathon, or a violation of any applicable law or regulation.

3. Any attempt by any person to undermine the proper conduct of the Hackathon may be a violation of criminal and civil law. Should the Sponsor or Administrator suspect that such an attempt has been made or is threatened, they reserve the right to take appropriate action including but not limited to requiring an Entrant to cooperate with an investigation and referral to criminal and civil law enforcement authorities.

4. If there is any discrepancy or inconsistency between the terms and conditions of the Official Rules and disclosures or other statements contained in any Hackathon materials, including but not limited to the Hackathon Submission form, Hackathon Website, or advertising, the terms and conditions of the Official Rules shall prevail.

5. The terms and conditions of the Official Rules are subject to change at any time, including the rights or obligations of the Entrant, the Sponsor and Administrator. The Sponsor and Administrator will post the terms and conditions of the amended Official Rules on the Hackathon Website. To the fullest extent permitted by law, any amendment will become effective at the time specified in the posting of the amended Official Rules or, if no time is specified, the time of posting.

6. If at any time prior to the deadline, an Entrant or prospective Entrant believes that any term in the Official Rules is or may be ambiguous, they must submit a written request for clarification. 

7. The Sponsor or Administrator’s failure to enforce any term of these Official Rules shall not constitute a waiver of that provision. Should any provision of these Official Rules be or become illegal or unenforceable in any jurisdiction whose laws or regulations may apply to an Entrant, such illegality or unenforceability shall leave the remainder of these Official Rules, including the Rule affected, to the fullest extent permitted by law, unaffected and valid. The illegal or unenforceable provision shall be replaced by a valid and enforceable provision that comes closest and best reflects the Sponsor’s intention in a legal and enforceable manner with respect to the invalid or unenforceable provision.

8. Excluding Submissions, all intellectual property related to this Hackathon, including but not limited to copyrighted material, trademarks, trade-names, logos, designs, promotional materials, web pages, source codes, drawings, illustrations, slogans and representations are owned or used under license by the Sponsor and/or Administrator. All rights are reserved. Unauthorized copying or use of any copyrighted material or intellectual property without the express written consent of its owners is strictly prohibited. Any use in a Submission of Sponsor or Administrator’s intellectual property shall be solely to the extent provided for in these Official Rules.

12. Limitations of Liability

By entering, all Entrants (including, in the case of a Team or Organization, all participating members) agree to release the Released Parties from any and all liability in connection with the Prizes or Entrant’s participation in the Hackathon. Provided, however, that any liability limitation regarding gross negligence or intentional acts, or events of death or body injury shall not be applicable in jurisdictions where such limitation is not legal.

13. Disputes

1. Except where prohibited by law, as a condition of participating in this Hackathon, Entrant agrees that:

1. Any and all disputes and causes of action arising out of or connected with this Hackathon, or any Prizes awarded, shall be resolved individually, without resort to any form of class action lawsuit, and exclusively by final and binding arbitration under the rules of the American Arbitration Association and held at the AAA regional office nearest the contestant;

2. The Federal Arbitration Act shall govern the interpretation, enforcement and all proceedings at such arbitration; and

3. Judgment upon such arbitration award may be entered in any court having jurisdiction.

2. Under no circumstances will Entrant be permitted to obtain awards for, and Entrant hereby waives all rights to claim, punitive, incidental or consequential damages, or any other damages, including attorneys’ fees, other than contestant’s actual out-of-pocket expenses (i.e., costs associated with entering this Hackathon), and Entrant further waives all rights to have damages multiplied or increased.

3. All issues and questions concerning the construction, validity, interpretation and enforceability of these Official Rules, or the rights and obligations of the Entrant and Sponsor in connection with this Hackathon, shall be governed by, and construed in accordance with, the substantive laws of the State of New York, USA without regard to New York choice of law rules.

SOME JURISDICTIONS DO NOT ALLOW THE LIMITATIONS OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATIONS OF LIABILITY MAY NOT APPLY TO YOU.

14. Additional Terms

Please review the Devpost Terms of Service at https://info.devpost.com/terms for additional rules that apply to your participation in the Hackathon and more generally your use of the Hackathon Website. Such Terms of Service are incorporated by reference into these Official Rules, including that the term "Poster" in the Terms of Service shall mean the same as "Sponsor" in these Official Rules." If there is a conflict between the Terms of Service and these Official Rules, these Official Rules shall control with respect to this Hackathon only.

15. Entrant’s Personal Information

Information collected from Entrants is subject to the Devpost’s Privacy Policy, which is available at https://info.devpost.com/privacy.

For questions, send an email to support@devpost.com.