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 nominationsendDate
: 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
Scout Authentication
Scout logs in to the Glow platform
System verifies scout role permissions
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
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
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 nominatedprojectsIds
: References to Projects involvedcohortId
: Reference to the current CohortnominatorId
: Reference to the Scout making the nomination
Voting Process
Step 1: Wallet Connection
Voters authenticate by connecting their XRPL wallet. This integration occurs through:
Wallet provider selection (Xaman, GemWallet, Crossmark, etc.)
Connection via the corresponding wallet provider API
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 VoternominationId
: Reference to the Nominationvote
: The vote valuetimestamp
: When the vote was cast
API endpoints for voting:
GET /api/nominations/list
- View nominationsPOST /api/votes
- Cast votesPUT /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:
Is the contributor over 18?
Has the nominee contributed to core infrastructure?
Is the contribution recent work (within 6 months)?
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 NominationuserId
: Reference to the Judgestatus
: 'approved' or 'declined'criteria
: Object containing evaluation criteria resultscomment
: Optional judge feedbackrejectionReason
: Required if status is 'declined'
Key judge-related API endpoints:
GET /api/nominations/metrics
- View nomination metricsPOST /api/judgeAssessments
- Create assessmentsPUT /api/judgeAssessments/:id
- Update assessmentsPOST /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 fieldsKycVerification
model for KYC statusAPI 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
Last updated