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 submission to disbursement.

Wave Creation

A Wave represents a time-bounded collection of submissions processed together.

Note: In the platform's data model, a Wave is represented by the Cohort model. The terms refer to the same grouping — "Wave" is the public-facing name, "cohort" the internal schema name.

Technical Implementation

Waves are managed through the Cohort model with key fields:

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

• startDate: When the Wave begins accepting submissions

• endDate: When the Wave closes (null for active Waves)

• status: Current state of the Wave

Only one Wave can be active at a time. When a submission is created — whether a Scout nomination or a direct contributor submission — it is automatically associated with the currently active Wave (where endDate is null and startDate is in the past).

The admin interface allows administrators to:

• Create new Waves

• Set start dates

• Close Waves by setting end dates

• View all submissions within a Wave

Submission Process

Submissions enter the platform two ways: a Scout nominates a contribution, or a contributor submits their own project directly. Both create the same underlying record and follow the same downstream workflow.

Step 1: Authentication

Scouts and contributors authenticate using their credentials through the authentication module. Role-based access control ensures Scouts can create nominations and contributors can create direct submissions.

Step 2: Project and Contributor Selection

Nomination Workflow (Scout)

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 a submission linking:

     • Selected contributor

     • Selected project(s)

     • Current Wave

     • Scout information

Direct Submission Workflow (Contributor)

1. Contributor Authentication

   • Contributor logs in to the Glow platform

2. Project Management

   • Contributor searches for an existing project or creates a new one with the required details (name, description, GitHub repository, X handle, website URL)

3. Submission Creation

   • Contributor provides contribution details (description, date of contribution, project category) and the independence/employment disclosure

   • System creates a submission linking the contributor, the selected project(s), and the current Wave, with no associated Scout

Workflow Diagram

Login (Scout or Contributor) │ ▼ Search Projects │ ├─────────────┐ │ │ ▼ ▼ Project Exists? Project Doesn't Exist │ │ │ ▼ │ Create Project │ │ │ │ ▼ │ Select Project │ │ │ └──────┬──────┘ │ ▼ Identify Contributor (Scout selects/creates; direct submitter is the contributor) │ ▼ Create Submission

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: Submission Details

When creating a submission, the submitter provides:

• Contribution description

• Contribution date

• Project category

• Independence/employment disclosure

The system automatically records:

• Wave ID (active Wave)

• Submitter information (Scout for nominations; contributor for direct submissions)

• Timestamp

Technical Implementation

Submissions are stored in the Nomination model with relationships to:

• contributorId: Reference to the Contributor being put forward

• projectsIds: References to Projects involved

• cohortId: Reference to the current Wave

• nominatorId: Reference to the Scout making the nomination (null for direct contributor submissions)

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 submissions through public pages and can cast three types of votes:

• Yay (+1)

• Nay (-1)

• Null (0)

The voting system enforces one vote per submission per wallet.

Technical Implementation

Votes are stored in the Vote model with:

• voterId: Reference to the Voter

• nominationId: Reference to the Submission

• vote: The vote value

• timestamp: When the vote was cast

API endpoints for voting:

• GET /api/nominations/list - View submissions

• POST /api/votes - Cast votes

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

Judging Process

Step 1: Judge Review

Judges review submissions with access to:

• Contribution details

• Project information

• Contributor information

• Community voting metrics

Step 2: Assessment Creation

Judges evaluate submissions against eligibility and quality criteria:

1. Is the contributor over 18?

2. Does the contribution fall within an eligible category?

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

4. Has the work been previously funded (through Glow or another program)?

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 submission, typically a minimum of three.

Step 4: Final Approval

Once all submissions in a Wave 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 Submission

• 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 submission 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 nominated by a Scout receive email notifications about their nomination. Contributors who submitted directly continue straight to the application steps.

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

• Independence/employment disclosure (disclose if the contribution overlaps with employment at Ripple or an affiliated organization)

• Conflict of interest checks (not a Scout or Judge in the relevant Wave)

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 Aquarium 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:

• Submission 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