Application Workflow

Technical overview of the Glow application workflow

The Glow platform implements a structured workflow for retroactive funding of contributions to the XRPL ecosystem. This document provides a technical overview of the process from nomination to disbursement.

Cohort Creation

A cohort represents a time-bounded collection of nominations processed together.

Technical Implementation

Cohorts are managed through the Cohort model with key fields:

  • name: Cohort identifier (e.g., "Cohort 1")

  • startDate: When the cohort begins accepting nominations

  • endDate: When the cohort closes (null for active cohorts)

  • status: Current state of the cohort

Only one cohort can be active at a time. When a Scout creates a nomination, it is automatically associated with the currently active cohort (where endDate is null and startDate is in the past).

The admin interface allows administrators to:

  • Create new cohorts

  • Set start dates

  • Close cohorts by setting end dates

  • View all nominations within a cohort

Nomination Process

Step 1: Scout Authentication

Scouts authenticate using their credentials through the authentication module. Role-based access control ensures only Scouts can create nominations.

Step 2: Project and Contributor Selection

Nomination Workflow

  1. Scout Authentication

    • Scout logs in to the Glow platform

    • System verifies scout role permissions

  2. Project Management

    • Scout searches for existing projects

    • If project exists:

      • Scout selects the existing project

    • If project doesn't exist:

      • Scout creates a new project with required details:

        • Project name

        • Description

        • GitHub repository

        • X handle

        • Website URL

  3. Contributor Management

    • Scout searches for the contributor

    • If contributor exists:

      • Scout selects the existing contributor

    • If contributor doesn't exist:

      • Scout creates a new contributor record with:

        • First and last name

        • Email address

        • GitHub username

        • X handle

        • Role (creator, maintainer, contributor, editor)

        • Active dates

        • Status

  4. Nomination Creation

    • Scout provides contribution details:

      • Description of contribution

      • Date of contribution

    • System creates nomination linking:

      • Selected contributor

      • Selected project(s)

      • Current cohort

      • Scout information

Workflow Diagram

Scout Login
    │
    ▼
Search Projects
    │
    ├─────────────┐
    │             │
    ▼             ▼
Project Exists?   Project Doesn't Exist
    │             │
    │             ▼
    │         Create Project
    │             │
    │             │
    ▼             │
Select Project    │
    │             │
    └──────┬──────┘
           │
           ▼
Search Contributors
           │
           ├─────────────┐
           │             │
           ▼             ▼
Contributor Exists?  Contributor Missing
           │             │
           │             ▼
           │      Create Contributor
           │             │
           ▼             │
   Select Contributor    │
           │             │
           └──────┬──────┘
                  │
                  ▼
          Create Nomination

Note: The diagram above is a simplified representation of the workflow. In actual implementation, the system uses API endpoints for these operations.

The platform provides search functionality with API endpoints:

  • /api/projects/search - Find existing projects

  • /api/contributors/search - Find existing contributors

When creating new records:

  • New projects are added through /api/projects

  • New contributors are added through /api/contributors

Step 3: Nomination Details

When submitting a nomination, the scout provides:

  • Contribution description

  • Contribution date

  • Project category

The system automatically records:

  • Cohort ID (active cohort)

  • Nominator ID (scout)

  • Timestamp

Technical Implementation

Nominations are stored in the Nomination model with relationships to:

  • contributorId: Reference to the Contributor being nominated

  • projectsIds: References to Projects involved

  • cohortId: Reference to the current Cohort

  • nominatorId: Reference to the Scout making the nomination

Voting Process

Step 1: Wallet Connection

Voters authenticate by connecting their XRPL wallet. This integration occurs through:

  1. Wallet provider selection (Xaman, GemWallet, Crossmark, etc.)

  2. Connection via the corresponding wallet provider API

  3. Address verification

Step 2: Wallet Verification

To prevent spam, voters must prove wallet ownership by signing a small transaction (1 drop) to a designated verification address. This registration is stored in the Voter model.

Step 3: Casting Votes

Voters browse nominations through public pages and can cast three types of votes:

  • Yay (+1)

  • Nay (-1)

  • Null (0)

The voting system enforces one vote per nomination per wallet.

Technical Implementation

Votes are stored in the Vote model with:

  • voterId: Reference to the Voter

  • nominationId: Reference to the Nomination

  • vote: The vote value

  • timestamp: When the vote was cast

API endpoints for voting:

  • GET /api/nominations/list - View nominations

  • POST /api/votes - Cast votes

  • PUT /api/votes/:id - Update votes

Judging Process

Step 1: Judge Review

Judges review nominations with access to:

  • Contribution details

  • Project information

  • Contributor information

  • Community voting metrics

Step 2: Assessment Creation

Judges evaluate nominations against eligibility and quality criteria:

  1. Is the contributor over 18?

  2. Has the nominee contributed to core infrastructure?

  3. Is the contribution recent work (within 6 months)?

  4. Is it unpaid work?

Step 3: Reward Size Assignment

Based on their assessment, judges assign a shirt size:

  • Decline (0)

  • Small (1)

  • Medium (2)

  • Large (3)

Multiple judges assess each nomination, typically a minimum of three.

Step 4: Final Approval

Once all nominations in a cohort have been assessed, judges conduct a final review and approve the distribution.

Technical Implementation

Judge assessments are stored in the JudgeAssessment model:

  • nominationId: Reference to the Nomination

  • userId: Reference to the Judge

  • status: 'approved' or 'declined'

  • criteria: Object containing evaluation criteria results

  • comment: Optional judge feedback

  • rejectionReason: Required if status is 'declined'

Key judge-related API endpoints:

  • GET /api/nominations/metrics - View nomination metrics

  • POST /api/judgeAssessments - Create assessments

  • PUT /api/judgeAssessments/:id - Update assessments

  • POST /api/nominations/actions/approve - Approve final distributions

Contributor Application Process

Step 1: Notification

Contributors receive email notifications about their nominations.

Step 2: Account Creation

If contributors don't have an account, the system facilitates account creation with the 'contributor' role.

Step 3: Eligibility Verification

Contributors must complete an eligibility questionnaire covering:

  • Age verification (18+)

  • Sanctioned region check

  • Affiliation checks (e.g., not a Ripple employee)

  • Conflict of interest checks (not a scout or judge)

Step 4: Terms Acceptance

Contributors must accept:

  • Terms of Service

  • Code of Conduct

Step 5: Wallet Registration

Contributors register their XRPL wallet to receive funds.

Step 6: Application Submission

Contributors complete their application with additional project details:

  • Previous XRPL grants or accelerator participation

  • Website, GitHub, and social media links

  • Additional project information

Step 7: KYC Verification

Contributors may need to complete KYC verification through the integrated verification service.

Technical Implementation

The contributor journey is managed through:

  • Contributor model with verification fields

  • KycVerification model for KYC status

  • API endpoints for:

    • Getting contributor status

    • Updating eligibility

    • Accepting terms

    • Registering wallet

    • Submitting application details

Disbursement Process

Step 1: Verification Check

The system verifies all requirements are met:

  • Nomination approved by judges

  • Contributor completed application

  • KYC verification (if required)

  • Valid XRPL wallet connected

Step 2: Payment Processing

Payments are processed through XRPL transactions to the contributor's registered wallet.

Step 3: Transaction Recording

All disbursements are recorded for transparency and audit purposes.

Integration Points

The workflow integrates with several external systems:

Email Service

  • Used for notifications to contributors

  • Account verification

  • Status updates

XRPL Network

  • Wallet connectivity

  • Transaction signing

  • Payment disbursements

KYC Provider

  • Identity verification

  • Compliance checks

Security Measures

The workflow includes multiple security controls:

  • Role-based access control

  • Wallet signature verification

  • Multi-judge approval requirements

  • KYC verification

  • Transaction validation

PreviousPlatform ArchitectureNextUser Roles & Permissions

Last updated