Seedify incubation links project development with measurable milestones

Oct 12th, 2026 - updated

Seedify incubation originally aimed to connect development teams with structured feedback on their blockchain products. The design proposed category-based advice and specialist partnerships. Projects using Seedify's milestone-based funding framework must also define objective deliverables and completion evidence. Advisory work supports development, while milestone review checks evidence of delivery against the agreed funding commitment. Community voters make the final milestone-approval decision. The applicable program determines the support and approval rules a team must meet.

Jump to a section

Bottom line: Milestone approval depends on the agreed deliverable and its evidence, even when incubation support has helped the project progress.

Community advice and specialist partnerships support different development needs

Structured advisory work was central to Seedify's original incubation design, which organized community involvement around categories such as user experience, tokenomics and development so teams could share progress with relevant specialists. Teams would use the targeted advice to improve their products. Technical specialists could address smart contract development, while communication specialists could examine content or community engagement. The proposed Solution Partners Program added connections with outside providers for development, marketing and smart contract security. The model proposed selecting contributors for category-based teams using their expertise and experience.

The partner program's wider scope included grants, design and legal support. Its selection process proposed case-by-case research before inviting providers. Incubated projects would contact verified partners matching their needs, while community involvement channels would supply feedback throughout development.

Project selection and ongoing advice had distinct roles in that model. Community voting determined entry, and feedback supported subsequent development.

The project team remains responsible for delivery even when advice or a partner introduction helps shape the work. A milestone-funded project must demonstrate it meets the completion criteria; advisory support alone does not establish completion of that funding obligation.

What must a project define before milestone fundraising?

A project must specify measurable deliverables, a deadline and completion evidence before community voting and fundraising begin, with Seedify's review team pre-validating the milestones at this stage. Acceptance of a proposal therefore precedes the later judgment about whether the team delivered its promised work.

The SMART framework requires each milestone to be specific, measurable, achievable, relevant and time-bound. Seedify's milestone framework requires an explicit deadline for each milestone. The deadline format uses a UTC date and time: YYYY-MM-DD HH:MM UTC. An informal target month does not meet that requirement.

Completion criteria need objectively verifiable outcomes. A proposal explains how the deliverable advances the roadmap, identifies dependencies and justifies its share of the total raise. Milestone difficulty should match the funds allocated, avoiding trivially easy targets or criteria whose success depends on their own approval.

The complexity guidance associates documentation or a testnet launch with 10-15% of the total raise. Mainnet launches or initial features sit in a 15-25% band; full feature sets or major integrations sit in a 25-35% band.

Market-dependent targets introduce constraints beyond development work. Risk disclosures must cover relevant market conditions, external dependencies, technical risks and jurisdiction-dependent features. These conditions affect whether the proposed deadline and resources are realistic. The framework also rejects manipulated evidence and ambiguous completion states, even when a claim appears technically true.

Evidence quality determines how independently others can verify delivery

Technical milestones prefer public on-chain evidence because independent reviewers can inspect the underlying data. The on-chain verification standard requires historical data. A displayed metric needs a transparent, reproducible basis when it supports a claimed outcome over time, so a point-in-time observation alone does not satisfy the requirement for historical data.

Verified contracts on blockchain explorers and public Dune Analytics queries are accepted evidence sources. An open repository with commit history can support development work. Technical submissions identify deployments or code through transaction hashes, commit ranges and verification endpoints. They may also include timestamped screenshots or recordings displaying the relevant web address.

Off-chain activities use a different evidentiary route, with corroboration from multiple independent sources, verifiable timestamps and an archive of the original material. Acceptable methods include signed attestations from recognized third parties, timestamped app-store listings and GPG-signed GitHub commits within their relevant scope. Manual-review cases cover evidence others cannot inspect through those routes. Seedify must independently verify such cases and obtain multiple corroborating evidence pieces. Community voters must know when a claim needs manual review, and the framework reserves this lower-confidence category for cases where no alternative exists. Each method must support the specific activity the milestone claims.

Graphic: Seedify incubation with verifiable milestones

View full-size image

Who decides whether a funding milestone is complete?

Community voters make the final approval decision in Seedify's milestone funding framework. Using Claude, ChatGPT, Gemini and Grok, the AI-oracle stage assesses each completion criterion and returns pass-or-fail recommendations with confidence, evidence quality and concerns about ambiguous cases before Seedify conducts manual review.

Seedify then checks whether evidence links work, on-chain data matches the claimed metrics and timestamps fall within the milestone period. The team also checks for wash trading or Sybil activity, where artificial activity or multiple identities can distort reported progress.

Review examines whether the work meets project standards and whether an oracle misread the evidence. The community report gives voters the oracle results and Seedify's recommendation alongside an assessment of the evidence.

Seedify's review also checks for conflicts with previous milestone decisions. Earlier judgments matter when they concern criteria the project continues to use.

Match deployment evidence to the promised milestone

A milestone promising a mainnet launch requires evidence of deployment on the specified production network. A testnet deployment shows progress in a testing environment. Its evidentiary value changes with the deliverable: it can support a testnet milestone, while a mainnet milestone requires proof of the production deployment. The evidence package must also address any other criteria the milestone includes.

Match the deployment environment to the accepted completion criterion.
Identify the contract, deployment transaction or repository version under review.
Check the evidence falls within the milestone's required period.
Confirm any metric uses the specified calculation and observation window.
Identify unmet criteria before treating the milestone as complete.

Evidence of a different environment leaves that deployment criterion unmet. An approved roadmap change can revise the obligation; without approval, the original milestone governs.

Milestone changes alter commitments through a defined approval process

A revised product plan does not automatically revise a funding milestone. Separate procedures cover isolated delays, broader disruptions and accelerated delivery. A significant pivot requires a justified proposal, a revised roadmap mapping old milestones to their replacements and an assessment of timeline and funding effects. Seedify reviews the proposal before community voting. Approval replaces the old milestones; rejection leaves the original commitments in force.

Seedify incubation FAQ

How many completion criteria must a Seedify funding milestone contain?

The milestone submission standard requires 3 to 8 objective completion criteria per milestone. Each criterion identifies a measurable target or a deliverable status a reviewer can verify.

Can a private partnership under an NDA count as milestone evidence?

A private partnership under a nondisclosure agreement can enter the framework's manual-review category when no alternative evidence route exists. Seedify must independently verify the claim and obtain multiple corroborating evidence pieces. Community voters must also know the claim requires manual review. Confidentiality changes the verification process; a project's private assertion alone does not establish milestone completion.

What happens if Seedify disagrees with an AI oracle's recommendation?

Seedify can override an oracle recommendation after reviewing the evidence and explaining why it considers the result incorrect. A false positive leads to a denial recommendation; a false negative leads to an approval recommendation. The override notice gives the reasoning and identifies the team's recommendation. Community voters may follow the oracle or Seedify, so the team's override does not itself replace the community decision.

How does the framework verify an off-chain evidence timestamp?

The off-chain verification standard requires a timestamp verifiable through a blockchain or a trusted timestamping service. The recorded time concerns the evidence for the claimed activity, and Seedify's manual review checks whether evidence timestamps fall within the milestone period.

Did Seedify plan to earn commissions through solution-partner relationships?

Seedify's original Solution Partners Program explicitly ruled out financial or commission-based partnerships for that program. Its stated purpose was to provide professional support to incubated projects. This policy concerned Seedify's relationship with partners; it did not set the price of a provider's work for a project team.

When must a team request a delay for a single milestone?

A team facing an unexpected obstacle delaying one milestone must submit its delay request to Seedify at least 7 days before the deadline under the change-request framework. That route permits a maximum 60-day delay, requires an explanation and mitigation plan and must leave subsequent milestone timelines unaffected. Seedify reviews feasibility before a 3-day expedited community vote. Broader disruptions use a separate process.

Is new evidence allowed in a dispute over a milestone vote?

A dispute must use the original evidence submission; that route does not permit new evidence. The framework allows one dispute per milestone, filed within 48 hours of the community vote result. Seedify re-reviews the material before a new 7-day community vote. The second vote is final.

Who receives community involvement rewards in the original incubation design?

The original design proposed project-token rewards for community specialists who contributed advisory work to incubated projects. These rewards concerned participation in development feedback, separate from the project's funding allocation or a participant's right to buy tokens in a launch sale. The proposed community program assigned reward methodology to initial DAO sessions and voting, so the design did not establish one universal payment for every contribution.