> For the complete documentation index, see [llms.txt](https://glow-docs.xrpl-commons.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://glow-docs.xrpl-commons.org/technical-resources/application-workflow.md).

# 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

```mermaid
flowchart TD
    A[Login: Scout or Contributor] --> B[Search Projects]
    B --> C{Project exists?}
    C -->|Yes| D[Select Project]
    C -->|No| E[Create Project]
    E --> D
    D --> F[Identify Contributor]
    F --> G[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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://glow-docs.xrpl-commons.org/technical-resources/application-workflow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.