Milestone Change Requests
Projects may request milestone modifications before or after evidence submission deadline. Processes are described below.
Pre-Submission Changes
Type 1: Pivot Request When: Business model or product direction changes significantly
Requirements:
Detailed justification (market conditions, technical constraints, strategic reasons)
Proposed new milestone roadmap
Mapping of old milestones to new milestones
Impact assessment on timelines and funding
Process:
Submit written proposal to Seedify
Seedify reviews and posts to Community Voting
Community vote (7-day window)
If approved: New milestones replace old ones
If denied: Original milestones stand
Type 2: Single Milestone Delay When: Unexpected obstacle delays one milestone
Requirements:
Maximum 60-day delay
Detailed explanation of cause
Mitigation plan
No impact on subsequent milestone timelines
Process:
Submit delay request ≥7 days before deadline
Seedify reviews feasibility
Community vote (3-day expedited window)
Type 3: All Remaining Milestones Delay When: Force majeure, regulatory action, critical external dependency failure
Requirements:
Comprehensive force majeure documentation
New timeline for all remaining milestones
Risk assessment update
Process: Same as Type 1 (Pivot Request)
Type 4: Early Release (Single Milestone) When: Project completes Milestone N+2 while on Milestone N
Requirements:
Full evidence for skipped milestone
Explanation of acceleration
Confirmation no corners were cut
Process:
Submit evidence for out-of-order milestone
Seedify & Oracle review
Standard Community vote
If approved: Funds release, original roadmap continues
Type 5: Early Release (Multiple Milestones) When: Project delivers 2+ milestones ahead of schedule
Requirements:
Evidence for all accelerated milestones
Justification for speed (not sandbagging evidence)
Quality assurance documentation
Process:
Submit comprehensive evidence package
Enhanced Seedify review (deeper quality check)
Community vote
If approved: Redistribute remaining funds proportionally across remaining milestones
Type 6: Partial Release Request When: Project completes 70-90% of milestone but cannot complete remainder due to external factors
Requirements:
Clear documentation of what was completed vs. not completed
Explanation of blocking issue
Proposal for handling incomplete portion
Options:
Option A: Release X% of funds now, remaining milestones absorb the gap
Option B: Extend deadline for full completion
Process:
Submit partial completion evidence + gap analysis
Seedify reviews and recommends percentage completion
Community vote on partial release
If approved: Remaining funds redistributed proportionally
Post-Vote Changes
Projects may request modification after Community vote under limited circumstances.
Type 7: Dispute (Oracle/Seedify/Community Decision) When: Project believes milestone was incorrectly evaluated
Limitations:
One dispute per milestone
Must be filed within 48 hours of Community vote result
Cannot dispute based on new evidence (only on evaluation of submitted evidence)
Requirements:
Detailed written argument explaining error
Reference to specific evidence that was overlooked
No new evidence allowed (dispute must use original submission)
Process:
File dispute with Seedify
Seedify re-reviews evidence + dispute argument
Seedify publishes response and recommendation
New Community vote (7-day window)
Second vote is final (no further disputes)
Bad Faith Penalty: Frivolous disputes harm project's reputation for future milestone votes.
Type 8: Post-Vote Partial Release When: Community votes NO, but project wants to argue for partial credit
Requirements:
Can only be used once per project lifecycle
Must present case for what portion was completed
Seedify must agree partial completion occurred
Process:
Same as Type 6 (Partial Release Request)
Last updated
Was this helpful?