Building a Capital Allocation Engine for an Open-Source AI Ecosystem

Building a Capital Allocation Engine for an Open-Source AI Ecosystem

Over the last development cycle, we added a new piece to the MyZubster ecosystem: a capital allocation layer for Zorgax.

The goal was not to build an autonomous trading bot or give an AI access to a wallet.

The goal was much simpler and much more useful:

take confirmed ecosystem inflows, estimate how much capital is actually available, rank where that capital could create the most value, require human approval, track what happened, and learn from the results.

This became the new Zorgax Capital Allocator.

From revenue to capital decisions

MyZubster already had an economic layer based on Payment Intents, settlement verification, BTC support, credits, entitlements and monetization.

The next question was obvious:

If money starts entering the ecosystem, where should it be reinvested?

Instead of hardcoding one answer, we built a system that can evaluate multiple opportunities.

The flow now looks like this:

Confirmed inflows
↓
Costs / obligations / reserve
↓
Available capital
↓
Zorgax Capital Allocator
↓
Ranked recommendations
↓
Human approval
↓
External spend
↓
Outcome measurement
↓
Bounded learning
↓
Better future recommendations

The important part is that Zorgax remains an advisory system.

It can recommend.

It can measure.

It can learn.

It cannot autonomously move funds.

Confirmed inflows are not the same as profit

One of the first design decisions was to avoid pretending that blockchain settlement equals accounting profit.

The capital metrics service reads confirmed PaymentIntent records and produces a confirmed inflow snapshot.

For example:

confirmedRevenueMinor
confirmedIntentCount
asset
network
windowDays

But the response explicitly identifies its accounting basis as:

confirmed_payment_intents

This matters because a confirmed payment tells us that money arrived.

It does not automatically tell us:

operating expenses,
taxes,
obligations,
reserves,
liabilities,
audited profit.

Those values are handled separately through server-side policy.

Server-controlled capital policy

The allocator does not let clients decide how much money is available to spend.

The server defines values such as:

expensesMinor
obligationsMinor
reserveMinor
maxAllocationBps

The basic calculation is:

available capital =
revenue

• expenses
• obligations
• reserve

If that number is negative, available capital becomes zero.

The system can also cap deployment.

For example, a maxAllocationBps value of 7000 means Zorgax can recommend deploying at most 70% of the currently available capital.

That leaves policy control outside the AI scoring layer.

Multi-dimensional opportunity scoring

Not every investment in an ecosystem should be evaluated only by immediate financial ROI.

A security audit may not directly generate revenue.

Infrastructure work may reduce future operating costs.

Developer bounties may increase ecosystem velocity.

Environmental pilots may create strategic value that appears much later.

So each opportunity can be evaluated across several dimensions:

financialReturn
ecosystemGrowth
userGrowth
developerGrowth
infrastructureValue
strategicValue
environmentalImpact
risk
liquidityCost

The current default weights include both positive and negative factors.

For example, risk and liquidity cost reduce the overall opportunity score.

This makes the allocator closer to a strategic capital allocation engine than a simple ROI sorter.

Initial investment categories

We added baseline opportunities for areas such as:

Security hardening

Zorgax infrastructure

Developer bounties

Growth experiments

LIFE / environmental pilots

These are not permanent hardcoded truths.

They are policy-defined starting points.

Zorgax ranks them based on the configured scoring model and the currently available capital.

Human approval is mandatory

A recommendation is stored as a persistent capital allocation proposal.

The lifecycle is:

PROPOSED
→ APPROVED
→ FUNDED
→ COMPLETED

Other states include:

REJECTED
CANCELLED
MEASURING

The critical rule is:

Zorgax cannot approve its own recommendation.

An administrator must explicitly approve it.

The system records who approved the allocation and when.

This creates an audit trail between machine recommendation and human decision.

Recording spend without moving funds

We also deliberately separated bookkeeping from execution.

The API includes a spend-recording action, but it does not connect to a wallet.

It only records that an externally executed expense happened.

The API response explicitly states:

executionPerformed: false

and:

This endpoint records an externally executed spend;
it does not move funds.

This separation is important.

It lets us build the decision and measurement system before introducing much higher-risk financial execution infrastructure.

Measuring real outcomes

After an allocation is funded, we can record the measured result.

The system stores values such as:

spentMinor
measuredReturnMinor
realizedReturnBps
outcome
outcomeMetrics

The current ROI calculation is:

(measured return - amount spent)
-------------------------------- × 10,000
amount spent

This gives us realized return in basis points.

For example:

spent: 30,000
measured return: 36,000

produces:

realizedReturnBps = 2000

or a 20% realized return.

This is where the allocator becomes more interesting.

Now the system does not only make recommendations.

It can compare them with reality.

Adding bounded learning

The latest block introduced a learning layer.

Completed allocations are aggregated by category to build historical evidence.

The learning service can derive signals such as:

sample count
capital spent
measured return
average realized ROI
success rate

But we intentionally avoided letting the system freely rewrite its own economic policy.

The learning system has hard constraints.

Historical results may adjust the financialReturn score, but:

a minimum number of completed outcomes is required;
adjustments are bounded;
scores stay between 0 and 100;
risk is not automatically changed;
liquidity cost is not automatically changed;
reserve policy is not changed;
maximum deployable capital is not changed.

In the current implementation, evidence can move the financial-return estimate by at most a limited number of score points.

This creates what we call:

bounded_evidence_adjustment

The AI can learn from evidence without becoming the authority that defines its own risk limits.

Transparent learning

We also added an admin endpoint:

GET /api/zorgax/capital/learning

The goal is transparency.

An administrator should be able to inspect what historical evidence exists and understand why future recommendations may differ from the original baseline policy.

We do not want hidden model preferences silently changing capital decisions.

The provenance of the adjustment matters as much as the recommendation itself.

Capital API

The capital allocator is exposed through an admin-only API.

Key endpoints include:

GET /api/zorgax/capital/recommendations

POST /api/zorgax/capital/recommendations/record

GET /api/zorgax/capital/allocations

POST /api/zorgax/capital/allocations/:allocationId/approve

POST /api/zorgax/capital/allocations/:allocationId/reject

POST /api/zorgax/capital/allocations/:allocationId/record-spend

POST /api/zorgax/capital/allocations/:allocationId/outcome

GET /api/zorgax/capital/learning

Every decision endpoint is protected by authentication and admin authorization.

Safety properties

The most important thing about this feature is what it does not do.

The Capital Allocator does not:

send Bitcoin

control a wallet

initiate bank transfers

autonomously approve expenses

change reserve requirements

increase its own spending limits

remove human approval

rewrite risk penalties

This was intentional.

We wanted to separate:

intelligence

from:

financial authority

That separation gives us room to experiment with AI-assisted capital allocation without giving an AI direct control over ecosystem treasury assets.

Testing

The feature was developed incrementally.

The dedicated capital subsystem ended with:

6 test suites passed
30 tests passed

Then we ran the complete backend regression suite:

73 test suites passed
313 tests passed

And the frontend suite:

4 test suites passed
10 tests passed

git diff --check also completed cleanly.

The final work was merged through PR #845:

feat(zorgax): add bounded capital allocation and learning
Why this matters for MyZubster

MyZubster is intended to grow beyond a single application.

The ecosystem includes ideas around:

AI agents,
decentralized infrastructure,
IoT,
robotics,
environmental systems,
research infrastructure,
machine payments,
marketplaces,
developer bounties.

If those systems eventually generate revenue, the ecosystem needs a rational way to decide where limited resources should go next.

That is what this layer starts to provide.

Instead of:

money comes in
→ founder guesses what to fund

we can move toward:

money comes in
→ constraints are calculated
→ opportunities are evaluated
→ evidence is presented
→ human approves
→ results are measured
→ future decisions improve

That is a much more interesting role for AI than simply generating text.

What comes next

There is still a lot to do.

Some of the next areas we want to explore include:

better accounting separation between revenue and settlement;
stronger outcome me