IBCOL 2021 Rules

Sections to be covered

1. Individual Eligibility
2. Team Eligibility
3. Project Eligibility
4. Deadlines
   • If you are submitting directly through IBCOL
   • If you are submitting through your country's BCOL
5. Submission Requirements
6. Submission Material Specifications
7. Criteria for Material Submissions
8. Criteria Grading Guidelines for Overall Project Evaluation
9. Criteria Grading Guidelines for Prototype Evaluation
10. Simplified Criteria for Overall Project Evaluation

Individual Eligibility

1. Students* only: Any current or recent student may register as a competitor; a recent student would have been a current student until 1 year ago as of the beginning of the 2020-2021 Season (5 July 2020 to 4 July 2021) — if a student had stopped school on or after 5 July 2019, the student is eligible to compete, otherwise, the student is ineligible to compete.
2. No age limit: A current student is defined as a person of any age that is enrolled in a recognized secondary or post-secondary academic institution.
3. Representation (Secondary Track): An individual is actively enrolled in a secondary school.
4. Representation (Post-secondary Track): An individual may be attached to an academic institution by being ever enrolled in it; a recognized institution is an accredited educational institution or an institution that may grant a degree or diploma.
5. Returning Participation: Previous individuals are eligible to compete.

Team Eligibility

1. Team Composition (Secondary Track): Projects are submitted by teams of one (1) to five (5) eligible individuals; one participant can be part of more than one team; each team shall have a team lead, as the main contact person.
2. Team Composition (Post-secondary Track): Projects are submitted by teams of one (1) to six (6) eligible individuals; one participant can be part of more than one team; each team shall have a team lead, as the main contact person.
3. Team Uniqueness: Each team must be unique, i.e. a team may not share more than 50% of the same composition as any other team, round to the lower number if the team is an odd number; team leads must be unique, i.e. one person cannot be the team lead of multiple teams.
4. Team Representation (Secondary Track): Each team must have students who are all from the same secondary school.
5. Team Representation (Post-secondary Track): Each team must nominate one representative academic institution if any of the team members are from different academic institutions; teams may be composed of members from different countries/territories or academic institutions.
6. Returning Participation: Previous teams are eligible to compete.

Project Eligibility

1. One Team, One Project: A team may submit only one project. Note: a team submitting a project for the IBCOL competition may also submit another entry for our sister competition IDSOL.
2. Returning Participation: Previous projects that have not won any awards from prior IBCOL competitions are eligible to compete in IBCOL.
3. Competition Tier: Secondary students and Post-secondary students shall compete in their respective tracks with different deadlines and submission criteria.

Deadlines

If you are submitting directly through IBCOL:

1. 5 Sep 2021 Submit your project by this date for free consultation by IBCOL mentors.
2. 10 Sep 2021 Submit your project by this date to get guaranteed evaluation by your country's BCOL Committee.
3. 15 Sep 2021 By this date, your country's BCOL Committe will nominate finalists (You will be notified if you are a finalist).
4. 25 Sep 2021 If your project is selected as a finalist, by this you must submit all the relevent submission materials. Please see Submission Requirements to find the relevant materials that you need to submit by each date.

If you are submitting through your country's BCOL:
1. 10 Sep 2021 Submit your project and the relevant materials to your country's BCOL Committee by this date.
2. 15 Sep 2021 By this date, your country's BCOL Committe will nominate finalists (You will be notified if you are a finalist).
3. 25 Sep 2021 If your project is selected as a finalist, by this you must submit all the relevent submission materials. Please see Submission Requirements to find the relevant materials that you need to submit by each date.

Submission Requirements

Secondary Track

1. 1st round submission Each project shall be evaluated by a Posterboard or Pitch deck submission by 23:59 5 Sep 2021.
2. 2nd round submission Each project shall be evaluated by a Posterboard or Pitch deck submission by 23:59 10 Sep 2021.
3. 3rd round submission Each project shall be evaluated by a Posterboard or Pitch Deck, Team Profile and Abstract submission by 23:59 15 Sep 2021.
4. 4th round submission Each project shall be evaluated by a Posterboard or Pitch Deck, 10-min pitch presentation and 1-min elevator pitch submission by 23:59 25 Sep 2021.
5. Final round Finalists will compete against each other with their projects from 8 to 10 Oct 2021.

Post-secondary Track
1. 1st round submission Each project shall be evaluated by a Whitepaper or Posterboard or Pitch deck submission by 23:59 5 Sep 2021.
2. 2nd round submission Each project shall be evaluated by a Whitepaper or Posterboard or pitch deck submission by 23:59 10 Sep 2021.
3. 3rd round submission Each project shall be evaluated by a Whitepaper, Posterboard, Pitch Deck, Team Profile and Abstract submission by 23:59 15 Sep 2021.
4. 4th round submission Each project shall be evaluated by a Whitepaper, Posterboard, Pitch Deck, 10-min pitch presentation and 1-min elevator pitch submission by 23:59 25 Sep 2021.
5. Final round Finalists will compete against each other with their projects from 8 to 10 Oct 2021.

The documents required in each round must be submitted within in the specified deadline. Each document mentioned in each round is required for evaluation by the judges. However, if any team fails to submit any document within the stated deadline, the team should let IBCOL know about their situation so that their situation can be considered with appropriate reasons.

Submission Material Specifications

1. Whitepaper: pdf file, 10-page limit excluding references and appendices.
2. Pitch Deck: pdf and pptx file, no slide limit.
3. 10-min Presentation: mp4 file or YouTube, 10-minute limit.
4. Posterboard: Figma or PDF, landscape, dimensions 36” × 48” at 300 dpi or equivalent (14400×10800 pixels).
5. 1-min Elevator Pitch: mp4 file or YouTube unlisted URL, 1-minute limit.

Criteria for Material Submissions

Adjudicators evaluate projects on the completeness of their solution design, based on their understanding of the proposal, which are evaluated through three types of presentations: paper, poster, and pitch.

1. WHITEPAPER: the proposal may include a document that describes in detail what the complete blockchain solution is. Papers may be multilingual but English must be present. If there are differences, the English version shall prevail.
2. POSTERBOARD: the proposal may include a research poster to showcase at the IBCOL Finals, and may be multilingual, but English must be present. If there are differences, the English version shall prevail.
3. PITCH: the proposal includes a 10-minute pitch presentation, those content may be multilingual, but English must be one of the languages. Speech must be in English, or if an exception is granted, must be subtitled in English.

Criteria Grading Guidelines for Overall Project Evaluation

• i. Problem & Solution (30 points total): project addresses an appropriate problem properly
• Suggested Evaluation Considerations:
• The problem is a complex challenge that involves various parties where incentives must be provided for coordination, reconciliation, and so forth.
• The solution must make sense to use a blockchain, rather than one that is oriented around a conventional cloud solution or database infrastructure.
• β. Comercial (15 points): the problem exists due to insufficient trust and the effort to build that trust is an insurmountable obstacle without the use of some technology to help coordinate and reconcile.
• τ. Technical (15 points): the solution shows that blockchain can address the problem better than other technologies.
• ii. Market & Partners (10 points total): project includes the appropriate collaboration properly
• Suggested Evaluation Considerations:
• The market is the collective size of the problem in quantitative terms, which further justifies the problem and provides a basis for revenue projections and distribution plans. A market is usually measured in terms of potential revenue, potential spending, potential users, or similar data.
• The partners are the entities that must be present for the solution to work — contestants need not have any relationship with potential partners. Typically, these are domain operators and regulators. A complete paper would describe the roles, responsibilities, and incentives of these partners.
• β. Comercial (5 points): the market is clearly defined in quantitative terms. The participants make sense. Their incentives can be (further) aligned with the help of blockchain technology.
• τ. Technical (5 points): the partners are aligned by the right incentives to cooperate (coordination play)
• iii. Competition & Risks (20 points): project is transparent about its potential vulnerabilities
• Suggested Evaluation Considerations:
• Competition may be direct (any product or service that does the same thing), very direct (other blockchain projects), or indirect (can even be alternative processes). A complete paper may not necessarily explain why the proposed project is the best, but why it is different and therefore better.
• Risks are all risks facing the proposed project. Usually, the biggest risks are non-cooperation or non-alignment of incentives of partners. Other risks include technical, execution, business, and other risks that may be encountered by any business plan.
• β. Comercial (10 points): the solution is convincingly better than others in terms of delivering value. Identifying and proposing remedies/mitigations of business risks, such as model failure, execution failure, etc.
• τ. Technical (10 points): the solution is convincingly better than others in terms of performance. Identifying and proposing remedies/mitigations of technical risks, such as how the solution can be compromised.
• iv. Architecture & Governance (30 points): project has appropriate design fundamentals
• Suggested Evaluation Considerations:
• Architecture refers to the technical design of the project. Justify why a certain blockchain platform or type of blockchain is preferred. How it interacts with non-blockchain systems, especially legacy processes and systems, technical or otherwise.
• Governance refers to how the project managed: network membership governance, technology infrastructure governance, and business network governance. Chapter 5 in the Blockchain for Business book by Arun, Cuomo, Gaur perfectly describes this concept.
• Asset tokenization may fall under this category, which is how non-blockchain ready, or even non-digital “things” are represented faithfully and consistently on the blockchain.
• Governance Checklist: the following is a reference for good blockchain governance. Many students will be very far from ideal, so if they have a good proportion of these concepts addressed in their paper, that would be great.
• Network Membership Governance
• Member on- and off-boarding
• Equitable and fair cost structure
• Data ownership structure
• Regulatory oversight provisioning
• Permission structure
• SLA management
• Network support services
• Risk optimization
• Network operations
• Business Network Governance
• Network charter and management
• Common/shared services management
• Business SLA: QA, performance, network security management
• Business exchange conditions management
• Industry-specific requirements, legal, regulatory compliance adherence
• Business operations structure
• Technology Infrastructure Governance
• Distributed IT management structure
• Model of distributed maintenance
• Framework for utilizing industry standards
• Resource optimization
• Technology assessment and adoption
• Network deployment
• Network support services
• Risk optimization
• β. Comercial (10 points): the solution ensures effective governance (see below), and faithful representation of non-blockchain ready or even non-digital assets for blockchain (tokenization).
• τ. Technical (20 points): the solution ensures effective tech infrastructure governance (see below), considers interfacing with legacy systems, justifies choice of chain (public or consortium; consensus implied), describes what data is on- and off-chain and the link between on- and off-chain activities, and addresses digital identity and privacy.
• v. Valuation & Distribution (10 points): project has value and can be brought into reality
• Suggested Evaluation Considerations:
• Revenue is about how the project generates value, which may not always be money.
• Distribution is about how the project will go to market and what the next steps would be.
• β. Comercial (10 points): the solution generates value and can capture it, and there is a plan to get it launched, and even better if there are immediate next steps or short term roadmap. No financial projections.
• τ. Technical (0 points): not applicable

Criteria Grading Guidelines for Prototype Evaluation

• i. Problem & Solution (40 points): prototype addresses an appropriate problem properly
• Why is blockchain the best solution to the problem?
• What problem or ‘pain point’ is being solved for stakeholders? For a company?
• What value is being created or captured?
• Does the solution adequately address the problem?
• ii. Privacy & Security Risks (20 points): prototype addresses privacy & security design
• Privacy — does the solution address data privacy and identity privacy?
• Privacy — will data unintentionally have leaked to unauthorized parties?
• Crypto-security — how does it address key management?
• Access Control — does the system have controls for who can access specific parts of the system?
• iii. Architecture (20 points): prototype architecture adheres to decentralized application design
• How are transactions verifiied? More precisely, what is the set up of the consensus? For example...
• If one uses Corda, what is the notary network?
• If it is Fabric, who are the orders, peers etc?
• If Algorand, are you using a public chain or a private instance ?
• What is stored on-chain and off-chain?
• How will the blockchain architecture handle compliance or regulation of the application if it is for a regulated industry such as banking or insurance?
• What is the data model if any?
• Is the integration of the blockchain solution with legacy systems addressed?
• How is data stored?
• Is there a digital identity system in place?
• iv. Governance (20 points): prototype handles governance and trust for decentralized application design
• Network Membership Governance — how to ensure effective network operations, including onboarding and offboarding of participants, permissions, support services, risks, and equitable costs distributed fairly based on participants’ activities?
• Member onboarding/offboarding
• Data ownership structure
• Permission structure
• Service level agreement (SLA) management
• Network support services
• Risk optimization
• Network operations
• Focuses on IT infrastructure, resources, performance, security and associated risks
• Distributed IT management structure
• Model of distributed maintenance
• Framework of utilizing industry standards
• Resource optimization
• Network deployment
• Network support services
• Risk optimization

Simplified Criteria for Overall Project Evaluation

1. Problem:
• The current situation has insufficient trust among relevant participants, e.g. the current system requires a centralized solution
• Difficult to build trusted relationships without the use of some technology, e.g. to help coordinate and reconcile perceptions and information
2. Solution:
• How is a decentralized solution more appropriate than a centralized one?
• Blockchain can address the problem better than other technologies or solutions, e.g. distributed database, shared database, an army of clerks and scribes, etc
3. Solution Design: Completeness of Trust Triangle Relationships
• Who is/are the Holder(s)?
• Who is/are the Issuer(s)?
• Who is/are the Verifier(s)?
• How are they onboarded such that trust prevails?
• What is the relationship between them?
4. Solution Design: Privacy, Security, Trust
• Privacy: What information is on-chain or off-chain and how is it stored? How is information exchanged and is it consent-based? Any use of privacy-preserving cryptography?
• Security: Identity management, e.g. participants and stakeholders have consistent identities. Access control, e.g. users can only access data related to them in specific instances.
• Trust: Identity linkability, e.g. people or objects can be linked with the digital identity that the solution relies on. Trust framework, e.g. the solution has relevant regulators or trusted agents. Governance, e.g. there are rules and policies for managing everyone.
5. UX Design: Workflow
• A walkthrough of the proposed solution, based on the “Happy Flow”, i.e. one scenario in an ideal world, including all assumptions required for this ideal world.
6. UX Design: Screenshots or High-Fidelity Prototype
• A Usability: User-oriented design, i.e. designer has empathy and understanding of what the user wants and needs — BONUS: background information of the users (personas).
• Appearance: Organized design, use appropriate color/shape to guide the user
• Functionality: Every item appears on the screen for a purpose