priya.iciness534

Project Owner

Seedbank: A Living Registry for MeTTa

Expert Rating

n/a

Type SingularityNET RFP
Funding Request n/a
RFP Guidelines An AI-native Development Environment for the ASI:Chain

Details locked. Check back later to view.
Details locked.Check back later to view.
Details locked.Check back later to view.

Overview

I have mass-deleted node_modules 847 times in my career. I know because I wrote a shell alias to count. The JavaScript ecosystem taught us that package management without type guarantees is a slow-motion disaster. Cargo showed us it can be better, but even Cargo can't prevent semver violations at the type level. MeTTa changes this equation entirely. Because Hyperon's type system can verify that an Atomspace subgraph is well-typed before publication, Seedbank can guarantee something no existing registry can: every package version is type-compatible with its declared dependencies. Not by convention. By proof. Seedbank treats packages as living organisms in a typed ecosystem.

RFP Guidelines

Internal Proposal Review

An AI-native Development Environment for...

Ended on:

13 Feb. 2026

Days

Hours

Minutes

Type SingularityNET RFP
Total RFP Funding $50,000 USD
Proposals 27
Awarded Projects n/a

SingularityNET

Feb. 4, 2026

View RFP

This RFP seeks proposals for the development of an AI-native Development Environment (IDE) that improves the efficiency and accessibility of blockchain application development for the ASI:Chain.

Proposal Description

Proposal Details Locked…

In order to protect this proposal from being copied, all details are hidden until the end of the submission period. Please come back later to see all details.

Total Milestones
4
Total Budget
$46,000_USD
Last Updated
14 Feb 2026

Milestone 1 - Research Architecture & Package Format

Description

Project initiation for MeTTa package manager. Architecture whitepaper covering package format Atomspace-based registry Hyperon verification pipeline dependency resolution on-chain governance. Survey cargo/npm/pip architectures and adapt for dependent types. Design package manifest format with MeTTa type exports. Evaluate DAS 1.0 for distributed registry storage. Connect to BlockDAG DevNet for governance contracts. Define 15 seed packages across 3 categories. Hiring plan budget risks. Budget: Personnel 3900 (65%). Infrastructure 1200 (20%: DevNet DAS). Review 600 (10%). Docs 300 (5%). De-risks M2-M4 by validating package format and dependency resolution approach.

Deliverables

D1. Architecture Whitepaper (20+ pages): Package format registry design verification pipeline dependency resolver governance contracts. D2. Package Manager Survey: cargo/npm/pip analysis with adaptation plan for MeTTa dependent types. D3. Package Manifest Spec: Format definition with type exports dependency declarations metadata. D4. DAS 1.0 Evaluation: Distributed registry storage assessment. D5. DevNet Connection: Governance contract deployment proof. D6. Seed Package Specs: 15 packages across core/contracts/AI categories. D7. Hiring Plan & Budget: Per-week allocation risk register. D8. Dev Environment: CI/CD setup <30 min.

Budget

$6,000 USD

Success Criterion

SC1. Architecture reviewed by 2+ community reviewers. SC2. Package format reviewed and approved by 3+ MeTTa developers. SC3. DAS 1.0 confirmed viable for distributed registry. SC4. DevNet governance contract deployed successfully. SC5. 15 seed package specs approved. SC6. Budget covers 100% of $50K with weekly granularity. SC7. CI/CD passing, setup <30 min.

Milestone 2 - CLI Registry & Verification Pipeline

Description

Build CLI tool (init install publish test search) Atomspace-based registry with DAS 1.0 storage and Hyperon verification pipeline. CLI handles full package lifecycle. Registry stores packages as Atomspace subgraphs with content-addressed storage. Every publish triggers Hyperon type checking — packages accepted only if well-typed. Semantic version detection through type signature comparison. 15 seed packages published: 5 core 5 contracts 5 AI modules. Budget: Personnel 11700 (65%). Infrastructure 3600 (20%: DAS Singularity Compute). Testing 1800 (10%). Docs 900 (5%). Risk: Verification speed → Singularity Compute offload. Registry scale → start local migrate to DAS.

Deliverables

D1. CLI Tool: metta init install publish test search audit. Cross-platform. D2. Registry: Atomspace-based with DAS 1.0 storage. Content-addressed packages. D3. Verification Pipeline: Hyperon type checking on every publish. Rejection of ill-typed packages. D4. Semantic Versioning: Automatic version detection via type signature comparison. D5. Seed Packages (15): 5 core libraries 5 contract templates 5 AI modules. All verified. D6. Dependency Resolver: Constraint-based resolution with type compatibility. D7. 250+ tests CI pipeline 85%+ coverage.

Budget

$18,000 USD

Success Criterion

SC1. CLI handles full lifecycle for all 15 seed packages. SC2. Registry stores and retrieves packages correctly. Semantic search works. SC3. Verification pipeline rejects 100% of ill-typed packages in test suite. SC4. Semantic versioning correctly detects breaking/non-breaking changes for 10+ test cases. SC5. Dependency resolution handles 3-level dependency chains. SC6. 3+ developers publish packages using the CLI. SC7. 250+ tests pass, 85%+ coverage.

Milestone 3 - Governance Compute & Advanced Features

Description

On-chain governance via Rholang contracts on BlockDAG DevNet. Package naming disputes maintainer transitions governed by CBC Casper consensus. Singularity Compute integration for heavy verification and complex dependency resolution. Atomspace-aware semantic dependencies — specify needs by capability not name. Conflict detection at type level with adapter suggestions via concept blending. Security audit integration. Lockfile generation for reproducible builds. Budget: Personnel 10400 (65%). Infrastructure 3200 (20%: Singularity Compute DevNet). Testing 1600 (10%). Docs 800 (5%). Risk: Governance complexity → start with naming only. Semantic deps → fallback to name-based.

Deliverables

D1. Governance Contracts: Package naming disputes maintainer transitions on BlockDAG. CBC Casper finalized. D2. Singularity Compute: Heavy verification offload. Complex dependency resolution. 3x+ speedup. D3. Semantic Dependencies: Atomspace queries for capability-based package discovery. D4. Conflict Detection: Type-level incompatibility detection with adapter suggestions. D5. Security Audit: Integration with vulnerability databases. 'metta audit' command. D6. Lockfiles: Reproducible builds with content-addressed lockfiles.

Budget

$16,000 USD

Success Criterion

SC1. Governance contracts handle 5+ naming/dispute scenarios correctly. SC2. Singularity Compute reduces verification time 3x+ for large packages. SC3. Semantic dependencies resolve correctly for 5+ capability queries. SC4. Conflict detection identifies 90%+ of type incompatibilities in test suite. SC5. Lockfiles produce reproducible builds for all 15 seed packages. SC6. Security audit detects known vulnerabilities in test packages.

Milestone 4 - Community Launch & Developer Beta

Description

10-developer beta testing full package management workflow. Community package contribution program. Documentation: user guide package authoring guide governance guide. Shell completions. Open source MIT release to SingularityNET registry. Project website with package browser. Community engagement and marketing. Budget: Personnel 6500 (65%). Infrastructure 2000 (20%: hosting). Testing 1000 (10%: beta). Docs/Marketing 500 (5%). Risk: Beta recruitment → leverage 200+ star community. Package quality → verification ensures baseline.

Deliverables

D1. Beta Program: 10 developers use full workflow. Recorded sessions NPS scoring. D2. Community Packages: 5+ external developers publish packages. D3. Documentation: User guide authoring guide governance guide API reference. D4. Shell Completions: bash zsh fish PowerShell. D5. Open Source: MIT SingularityNET registry. Install <30 min. D6. Package Browser: Web UI for exploring published packages. D7. Website & Marketing: Landing page tutorials community links.

Budget

$6,000 USD

Success Criterion

SC1. 8+ of 10 beta developers complete publish/install workflow in 4 hours. NPS 7+. SC2. 5+ community packages published and verified. SC3. 25+ total packages in registry. SC4. Package browser correctly displays all packages with type signatures. SC5. 50+ GitHub stars in 30 days. SC6. MIT licensed, documented, 85%+ coverage.

Join the Discussion (0)

Expert Ratings

Reviews & Ratings

No Reviews Avaliable

Check back later by refreshing the page.

The weighted average of the 4 perspectives Overall

0.0
Each RFP defines a maximum allowed budget, but teams can differentiate their proposal by offering a solution with a lower budget or a wider scope.Value for money

0.0
This rating indicates compliance to 'Must haves' but also adaptation of 'Nice to haves' and Non-functional requirements defined in the RFP.Compliance with RFP requirements

0.0
RFPs will offer varying degrees of freedom. This rating indicates the quality of the team's specific solution ideas, the provided details, and the reviewer's confidence in the team's ability to execute.Solution details and team expertise

0.0

Review Headline

0 /50 chars

Review Summary

0 /5000 chars

The weighted average of the 4 perspectives Overall

0.0
Each RFP defines a maximum allowed budget, but teams can differentiate their proposal by offering a solution with a lower budget or a wider scope.Value for money

0.0
This rating indicates compliance to 'Must haves' but also adaptation of 'Nice to haves' and Non-functional requirements defined in the RFP.Compliance with RFP requirements

0.0
RFPs will offer varying degrees of freedom. This rating indicates the quality of the team's specific solution ideas, the provided details, and the reviewer's confidence in the team's ability to execute.Solution details and team expertise

0.0

Review Headline

0 /50 chars

0 /5000 chars

Warning: Adding final group rating for this project will prevent expert users from adding new or editing existing reviews

Reviews and Ratings in Deep Funding are structured in 4 categories. This will ensure that the reviewer takes all these perspectives into account in their assessment and it will make it easier to compare different projects on their strengths and weaknesses. Overall (Primary) This is an average of the 4 perspectives. At the start of this new process, we are assigning an equal weight to all categories, but over time we might change this and make some categories more important than others in the overall score. (This may even be done retroactively). Feasibility (secondary) This represents the user\'s assessment of whether the proposed project is theoretically possible and if it is deemed feasible. E.g. A proposal for nuclear fission might be theoretically possible, but it doesn’t look very feasible in the context of Deep Funding. Viability (secondary) This category is somewhat similar to Feasibility, but it interprets the feasibility against factors such as the size and experience of the team, the budget requested, and the estimated timelines. We could frame this as: “What is your level of confidence that this team will be able to complete this project and its milestones in a reasonable time, and successfully deploy it?” Examples:

A proposal that promises the development of a personal assistant that outperforms existing solutions might be feasible, but if there is no AI expertise in the team the viability rating might be low.
A proposal that promises a new Carbon Emission Compensation scheme might be technically feasible, but the viability could be estimated low due to challenges around market penetration and widespread adoption.

Desirability (secondary) Even if the project team succeeds in creating a product, there is the question of market fit. Is this a project that fulfills an actual need? Is there a lot of competition already? Are the USPs of the project sufficient to make a difference? Example:

Creating a translation service from, say Spanish to English might be possible, but it\'s questionable if such a service would be able to get a significant share of the market

Usefulness (secondary) This is a crucial category that aligns with the main goal of the Deep Funding program. The question to be asked here is: “To what extent will this proposal help to grow the Decentralized AI Platform?” For proposals that develop or utilize an AI service on the platform, the question could be “How many API calls do we expect it to generate” (and how important / high-valued are these calls?). For a marketing proposal, the question could be “How large and well-aligned is the target audience?” Another question is related to how the budget is spent. Are the funds mainly used for value creation for the platform or on other things? Examples:

A metaverse project that spends 95% of its budget on the development of the game and only 5 % on the development of an AI service for the platform might expect a low ‘usefulness’ rating here.

A marketing proposal that creates t-shirts for a local high school, would get a lower ‘usefulness’ rating than a marketing proposal that has a viable plan for targeting highly esteemed universities in a scaleable way.
An AI service that is fully dedicated to a single product, does not take advantage of the purpose of the platform. When the same service would be offered and useful for other parties, this should increase the ‘usefulness’ rating.

priya.iciness534

Project Owner

Project leadership, package architecture, registry design.

View Profile

Account Pending

DevEx Engineer

Registry infrastructure, DAS 1.0 integration, governance contracts, Singularity Compute offload, content-addressed storage. 12 DevNet contracts.

Account Pending