> For the complete documentation index, see [llms.txt](https://metafishtank.gitbook.io/metafishtank-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://metafishtank.gitbook.io/metafishtank-docs/10-developer-ecosystem.md).

# 10. Developer Ecosystem & ECS

> **Democratizing AI-native game development by giving developers assets, users, state and intelligence as reusable infrastructure.**

## 10.1 The Developer Promise

A studio should not need to solve every layer of AI gaming before testing an idea.

MetaFishtank reduces four barriers:

1. **Asset Creation Barrier** — a population of user-owned Agents already exists.
2. **AI Barrier** — Anima exposes interpretation and runtime capabilities.
3. **State Barrier** — MAP standardizes identity and cross-game progression.
4. **Distribution Barrier** — Open Ocean can route existing Agent owners into compatible experiences.

## 10.2 Developer Tooling

The target developer stack includes:

* Solidity interfaces;
* TypeScript SDK;
* REST / RPC state APIs;
* Unity toolkit;
* Unreal toolkit;
* adapter templates;
* testnet sandbox;
* event/indexer APIs;
* Anima API / SDK;
* integration dashboard.

## 10.3 Agent Inventory as Infrastructure

The most important developer asset is not only code. It is **living inventory**.

A new game can query available Agents, read approved traits and let users enter using something they already own.

This reduces the temptation to launch a new NFT collection for every new game and aligns developers around increasing the utility of the same persistent Agent base.

## 10.4 Evolution Contribution Score (ECS)

Cross-game evolution creates a new question:

> **Which games actually contributed value to an Agent?**

MetaFishtank introduces the **Evolution Contribution Score (ECS)** as an attribution framework.

ECS can measure a game's contribution using factors such as:

* verified experience gained;
* unique achievements unlocked;
* canonical skills or traits contributed;
* active time and retention;
* completed progression milestones;
* verified economic activity;
* major evolution events;
* durable cross-game state generated.

A conceptual score can combine normalized factors with transparent weights and caps.

The purpose is not to create an opaque “AI score.” The purpose is to create an auditable attribution layer.

## 10.5 Developer as Co-Creator

If a game meaningfully contributes to an Agent's long-term history, the developer can be recognized as a **Co-Creator of Evolution**.

ECS can support:

* developer incentive pools;
* protocol grants;
* marketplace attribution;
* revenue sharing;
* discovery ranking;
* verified contribution badges;
* optional secondary-market royalty logic where legally and technically appropriate.

Any royalty or fee attribution must be explicit, auditable and configurable rather than hidden or permanent by default.

## 10.6 Reference Interaction Split

For selected protocol-owned or reference interactions, an illustrative revenue split may be:

* **80% — User / Creator**
* **15% — Developer / Experience Provider**
* **5% — Protocol Treasury**

This is a reference model, not a mandatory universal rule for all third-party games.

**Note:** This 80/15/5 split is a reference allocation of individual interaction revenue among users, developers and the protocol. It is separate from the default co-operated order split in 11.9 (partner 80%, platform 20%); the two do not stack.

## 10.7 Network Flywheel

### Product Flywheel

**Users Create Agents** → More Persistent Agents → Developers Gain Ready-Made User / Asset Inventory → More Games Integrate MAP → Agents Gain More Utility & Evolution → More Interaction Data Enters Anima → Anima Improves → Better Agents + Lower Creation Barrier → More Users

### Economic Flywheel

**Game Revenue / Protocol Fees** → Developer Incentives → Compute & Security Reserve → $MFT Utility → Ecosystem Growth → More Games and Agents → More Revenue


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://metafishtank.gitbook.io/metafishtank-docs/10-developer-ecosystem.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.