DeGrants Application Lifecycle

August 21, 2026

How a DeGrants application moves from submission to a completed grant. Written for applicants, stewards, admins, and anyone who needs the process in one place.

---

In one sentence

An application is reviewed and offered funding. A grant is created only after the applicant accepts the offer. Then the grantee submits a blueprint, delivers milestones, and finishes with an impact report.

---

Does the applicant need to accept if admin offers the full amount?

Yes. Approving the original amount and approving an adjusted amount both create an offer. The applicant must click Accept Offer in either case.

Approving never creates a grant by itself.

---

The two records

Applicants choose one funding amount when they apply: $3,000, $4,000, or $5,000.

---

End-to-end flow

Apply
  → Stewards score
  → Admin decides (approve full / approve less / reject)
  → Applicant accepts or declines the offer
  → If accepted: Grant is created
  → Applicant submits blueprint + KYC
  → Steward/admin approves blueprint
  → Milestones run one at a time
  → Impact report
  → Grant complete

---

Phase 1 — Applicant submits

1. Applicant logs in. Steward accounts cannot apply.
2. They fill the form at /funding/apply (project, team, funding amount, milestones, acknowledgements).
3. On submit, an application is created with status Submitted.
4. It appears in My DeGrants for the applicant and Review DeGrants for stewards and admins.
5. A Slack intake message is sent if Slack is configured.
6. The applicant waits. Scoring does not start automatically.

---

Phase 2 — After steward score

Steward scoring is review only. It does not approve, reject, or create an offer.

1. A steward opens /funding/review-degrants/[id]/review.
2. They score 6 criteria, each 1–5 (max 30):
   • Stacks ecosystem relevance
   • Community value
   • Feasibility and execution risk
   • Engagement and momentum
   • Applicant fit
   • Deliverables and timeline quality
3. Notes are required. They can recuse as conflicted.
4. They cannot score their own application.
5. They cannot score an application marked duplicate (scoring is locked).
6. The first score moves the application from Submitted to UnderReview.
7. Later stewards can still score. A steward can update their own score until an admin decides.
8. The average score is the average of non-conflicted reviews.
9. Slack posts that a review was submitted or updated.
10. After an admin decides, steward scores are locked.

Admins can decide even if there are zero steward scores. The review UI shows the average so they can use it.

---

Phase 3 — After admin decision

Only someone with grant-status permission sees the Admin Decision panel. There are three options.

A. Approve original amount (full amount)

1. Admin clicks Approve (original amount).
2. The system reads the requested amount from the application ($3,000 / $4,000 / $5,000).
3. Status becomes Approved.
4. offerAmount is set to that full requested amount.
5. Optional decision notes are stored.
6. Applicant gets an in-app Grant offer made notification.
7. No grant is created yet.

B. Approve adjusted amount

1. Admin enters a custom USD amount and confirms.
2. Same as above: status Approved, offerAmount = the adjusted number.
3. Applicant still gets an offer notification.
4. Still no grant until they accept.

C. Reject

1. Admin clicks Reject politely.
2. Status becomes Rejected.
3. offerAmount is cleared.
4. Applicant gets a Pitch rejected notification (notes included if written).
5. Process ends. No offer, no grant.

After any of these, the admin UI shows “already decided,” and stewards can no longer change scores.

---

Phase 4 — Applicant accepts or declines

On My DeGrants → that application, if status is Approved, the applicant sees You’ve received a DeGrants offer with Accept / Decline.

This is required for both full-amount and adjusted-amount approvals.

If they accept

1. Only the applicant can do this, and only while status is Approved and no grant exists yet.
2. The system creates a Grant:
   • awarded amount = the offer
   • requested amount = what they originally asked for
   • category = DeGrants
   • stage = blueprint
   • assigned steward = highest-scoring non-conflicted steward (if any)
3. Application status becomes OfferAccepted and is linked to that grant.
4. The admin who decided gets Grant offer accepted.
5. Applicant is sent to /funding/my-degrants/[grantId].
6. Next required step: submit the project blueprint.

If they decline

1. Status becomes OfferDeclined.
2. No grant is created.
3. The deciding admin gets Grant offer declined.
4. Process ends. They cannot accept later from this application.

---

Phase 5 — After accept: blueprint

The grant starts at blueprint. There are no active milestones yet.

1. Applicant opens the grant and submits a blueprint:
   • overall scope of work
   • at least one milestone (name, scope, amount)
   • KYC document (required)
   • optional start date / deadline
2. Milestone amounts cannot exceed the awarded amount.
3. All milestones are created as locked.
4. Blueprint review status becomes pending.
5. Assigned steward is notified.

Then a steward or admin reviews.

Blueprint approved

All three must pass:

• Blueprint: approve
• KYC: verified
• Funding release: approve

Then:

• Blueprint is marked approved
• Grant moves to milestones
• Milestone 1 becomes active
• initialFundingPaidAt is recorded
• Applicant is notified Blueprint approved

Blueprint rejected

• Stage stays blueprint, review = rejected
• Applicant can resubmit a new plan (old milestones are replaced)
• Applicant is notified Blueprint rejected

---

Phase 6 — Milestone steps on the grant

Milestones run in order. Only the current one is active. Later ones stay locked until the previous one is paid.

locked → active → submitted → approved → paid
                         ↘ requires_changes → (resubmit) → submitted

1. Grantee works on the active milestone

Only active or requires_changes can be submitted.

2. Grantee submits deliverables

• Must include a valid deliverables URL (optional notes)
• Status becomes submitted
• Steward is notified

3. Steward or admin reviews

Approve

• Status → approved
• Grantee is notified
• Payment is not automatic

Request changes

• Feedback text is required
• Status → requires_changes
• Grantee can resubmit
• Grantee is notified

4. Admin marks it paid

• Only after status is approved (admins only)
• Optional Hiro explorer transaction URL (https://explorer.hiro.so/txid/...)
• Status → paid
• Next milestone (if any) becomes active
• Grantee and steward are notified

5. When every milestone is paid

The grant automatically moves to impact_report.

---

Phase 7 — Impact report and completion

1. Grantee submits an impact report URL (optional notes).
2. Steward or admin reviews:
   • Approve → grant stage complete, grant status Completed
   • Requires changes → stays in impact report; grantee revises and resubmits

---

Quick reference

---

Details that often confuse people

• Steward score ≠ decision. Admins decide funding.
• Approve ≠ funded. Accept Offer creates the grant.
• Full amount still needs Accept. Same as a reduced offer.
• Decline is final for that application.
• Interview / submit_pitch exist in older frontend types. Live grants start at blueprint after accept.
• Duplicate applications can be flagged; they cannot be scored.
• Selected / public lists treat Approved and OfferAccepted as selected. Badge minting for “selected” also allows Approved even if they have not accepted yet.

---

Application statuses

Grant stages

---

Source of truth in code