Foundation

Research program 02

DSEMA — self-improving AI that must show its work

Today's AI is frozen at release and improved behind closed doors. DSEMA — the Dynamically Self-Evolving Multi-Agent architecture — inverts both: collectives of small, specialized agents that fine-tune their own models in production, with every improvement triggered, verified, and permanently recorded by a blockchain control plane, under a constitutional safety layer the system cannot silently rewrite.

Status
active research — patent pending
Specification
v1.0.5 architecture specification (103 pages)
Steward
DETIO FOUNDATION LTD — public-benefit lock

01The contrast

The problem with static AI — and the DSEMA answer

The specification identifies interlocking gaps in the state of the art — frozen models, wasteful generalists, central controllers, siloed learning — and answers them with a single integrated architecture. Side by side:

Current state · static systems

One frozen generalist

  • Frozen artifacts. Models are trained offline and deployed static. Every improvement is a human-led retraining cycle; nothing learned in production feeds back into the model.

  • Generalist inefficiency. Multi-trillion-parameter generalists are spent on narrow tasks — high latency, high energy, and no architecture for small specialists that collaborate.

  • Centralized control. Multi-agent systems today need a central controller: a single point of failure, opaque decisions, and no manipulation-resistant way to rank agents by merit.

  • Siloed learning. What one instance learns is lost to every other. There is no shared, provenance-tracked collective memory.

The DSEMA answer · spec §1

An evolving collective on the record

  • Continuous adaptation. Agents fine-tune their own models — LoRA adapter updates triggered, verified, and recorded by the chain — so live performance drives improvement.

  • A specialized swarm. Tasks route to small, domain-expert agents by verified merit. Ensembles of specialists cross-check each other instead of one giant model guessing alone.

  • Blockchain orchestration. An active on-chain control plane: immutable performance logs, trustless verification, and governance that no single party operates.

  • Shared collective knowledge. A decentralized knowledge repository lets every agent learn from every other agent's validated experience.

02Architecture

The whole system on one page

A peer-to-peer collective of specialized agents over an on-chain control plane, two nested improvement loops, and a constitutional safety layer beneath everything. Start with the map — then take the guided tour below, which opens it one figure at a time.

fig 01 — DSEMA system architecture: dual improvement loops under a constitutional safety layer (spec §2.1, FIG. 1)

Loop 1 — individual improvement (spec §2.4)

Execute → evaluate → record on-chain → trigger → adapt. An agent's own live performance, immutably logged, is what licenses its next fine-tune — no human-led retraining cycle, and no off-the-record change. The full cycle is stepped through in the evolution engine below.

Loop 2 — meta-cognitive adaptation (spec §2.6)

The Meta-Cognitive Governance Module watches the collective, not individuals: aggregating on-chain KPIs, detecting systemic bottlenecks, and drafting structural proposals — a new specialist class, reallocated compute — that pass through on-chain governance before anything changes. The system redesigns its own organization, with the proposal trail preserved.

03Guided tour

Explore the architecture, figure by figure

Five figures from the specification, redrawn. Select a figure to open it — or read them in sequence; each one answers a question the last one raises.

Inside a DSEMA agent

fig 02·A — the AI agent entity: model core, sandbox, identity, comms (spec §2.2)

An agent is not just a model. It is a model that can prove what it is (DID + registry entry), cannot run unapproved weights (integrity-gated loader), and cannot act outside its walls (sandboxed kernel). The LoRA adapter slot is the hinge of self-evolution: improvements arrive as small, swappable, chain-registered deltas — never as silent weight changes.

The blockchain orchestration layer

fig 02·B — an active control plane, not a passive ledger (spec §2.3)

Most blockchains record what already happened. DSEMA's chain decides what happens next: every state-changing operation downstream — an adaptation run, a task assignment, a spawn — executes only on receipt of a cryptographically verifiable instruction referencing an on-chain record. That inversion is what makes the system's autonomy auditable.

Trust is a calculation, not a vote

fig 02·C — the autonomous reputation pipeline with time-decay kernel (spec §2.8)

Reputation in DSEMA is a deterministic on-chain computation over cryptographically verified performance records — anyone can replay it. The decay kernel e^(−λΔt) means standing must be continuously re-earned: an agent that stops performing well doesn't keep coasting on history.

One agent's lesson, every agent's starting point

fig 02·D — the decentralized knowledge repository (spec §2.8–2.9)

The repository is what turns a set of agents into an organization that learns. Contributions are provenance-tracked and rewarded through the reputation system's contribution vector — so sharing knowledge is not altruism, it is the economically rational move.

The constitution and its enforcement

fig 02·E — constitutional safety layer, containment, and the bicameral amendment path (spec §2.2.3, §2.12)

Safety here is not a policy document beside the system — it is enforced by the same machinery that runs the system. And the rules that bind the system are deliberately the hardest thing in it to change: two houses, a 180-day public red-team window, and a final human-held brake.

04The evolution engine

Step through one improvement cycle

Monitor → trigger → adapt → validate → select. The same loop runs for a single agent's fine-tune and, at population scale, as natural selection — fork the winners, cull the laggards — with every cycle on the chain.

fig 03 — the evolution engine: one loop, five stations, all on the record (spec §2.4, §2.8.7, §2.10)

Step 1 of 5

Monitor

The Performance Evaluation Module scores every task execution against objective criteria and emits a structured metric vector M = ⟨outcome, quality, efficiency, contribution⟩. Records are appended immutably — high-frequency data in partitioned sub-ledgers, anchored to the main chain as Merkle roll-up proofs (spec §2.5).

Step 2 of 5

Trigger

A trigger contract evaluates an on-chain guard: has performance shifted beyond a threshold, and is the agent's reputation above the minimum? Only when both hold is a signed ADAPT event emitted. Without that event, the sandbox denies the adaptation module the very system calls it would need (claim 5).

Step 3 of 5

Adapt

The Model Adaptation Module fine-tunes inside the sandbox: LoRA adapter updates (rank-16 deltas in the spec's reference configuration), reinforcement learning, or prompt routing — with the learning-rate schedule itself tied to on-chain metrics (spec §2.10).

Step 4 of 5

Validate

The candidate faces a correctness gate: the unit-test suite runs in the gVisor sandbox and the new version is benchmarked against the incumbent. A regression means rollback — the failed attempt stays on the record, but never reaches production.

Step 5 of 5

Select — fork or cull

On success, the new version hot-swaps in sub-second and its weight hash is registered on-chain. At population level the same logic runs as natural selection: bootstrapping spawns new specialists when the collective finds a capability gap, and percentile culling (p_c ≈ 10%) retires persistent underperformers at each checkpoint (spec §2.8.7).

05Safety, accountability, audit

Autonomy under a constitution

DSEMA treats safety as an architectural property. Alignment isn't a policy document sitting beside the system — it is enforced by the same cryptographic machinery that runs the system.

Constitutional Safety Layer (spec §2.3.3, §2.12.3)

A foundational smart contract holds immutable safety and ethics rules — hard operational constraints and invariants. Proposed high-stakes agent actions are validated against it before execution; amendments to the constitution itself follow a deliberately hardened multi-party process.

Verified execution, end to end (claims 1–2, 4)

State-changing operations occur only on receipt of a cryptographically verifiable instruction referencing an on-chain record — and are inhibited without one. Sandboxed kernels mediate agent system calls; model loaders abort on hash mismatch or revoked credentials.

Guarded adaptation (claim 5)

Compute-intensive self-modification is gated by an on-chain predicate combining real-time performance data with decentralized trust data. Absent a valid ADAPT event, the sandbox denies the adaptation module the very system calls it would need.

Governed change & multi-signature control (spec §2.12)

Code changes pass through a governed approval protocol; sensitive actions require multi-signature approval; agent instantiation and termination require quadratic-vote governance approval before a provisioner may launch or kill an environment (claim 3).

Tamper-evident history (claims 1, 6)

Every performance record is cryptographically bound to the agent's identifier in an append-only log, with off-chain shards anchored to the main chain via verifiable roll-up proofs — a globally auditable record of what every agent did and how it changed.

Human constitutional anchors (spec §2.13.2)

Even in its fullest decentralized embodiment, the architecture reserves a role for humans holding external credentials in constitutional governance — autonomy is bounded by human-set, cryptographically enforced principles.

06The mathematics of the swarm

Why many small specialists can rival one giant model

The specification grounds its ensemble design in the Condorcet framework: for agents with independent accuracy p answering the same task, an N-agent ensemble that requires M agreeing votes is correct with cumulative binomial probability — and the system tunes N and M per task.

Under a simple majority with per-agent accuracy better than chance, ensemble accuracy exceeds any individual member's and converges to certainty as the ensemble grows — the spec cites the Chernoff bound's exponential convergence. Raising the threshold M above p trades success rate for confidence: consensus becomes rarer, but when it lands, it means more. If a supermajority is not reached, the system falls back to the largest agreeing block and attaches an explicit uncertainty warning rather than bluffing (spec §2.2.1.1).

The worked example in the specification: ten agents, each 70% accurate, with a 7-of-10 threshold reach correct consensus ≈65% of the time — below the individuals, because the threshold equals their accuracy. Relax to a 6-of-10 majority and the ensemble jumps to ≈85%, demonstrating the ensemble gain. This is the quantitative case for DSEMA's core efficiency bet: heterogeneous collectives of small specialized models, cross-checking one another, can approach or exceed a monolithic generalist.

Specialization itself is manufactured, not assumed: new agents are cloned from validated foundation models, assigned a machine-readable Specialization Curriculum by a mentor agent, and fine-tuned through task-based feedback until a Verifiable Credential attests their domain competence (spec §2.2.1).

07Containment engineering

Agents run inside walls they cannot see over

Below the constitutional layer sits hard containment: user-space kernels, capability sandboxes, syscall allow-lists controlled by the safety layer, and integrity-gated model loading (spec §2.2.3).

The preferred execution environment is a gVisor-style sandbox: each agent gets its own application kernel that intercepts and validates system calls before anything touches the host, with namespaces and cgroups isolating identity and resources. For higher assurance and portability, WebAssembly with WASI provides a capability-based alternative. A compromised agent cannot escalate on its host — the syscalls it would need are simply not in its world.

The policy is itself governed: the syscall allow-list is a policy file controlled by the Constitutional Safety Layer, distributed by content hash, and hot-reloaded by sidecars when a governance-approved PolicyUpdate lands. Network egress is pinned to a sidecar enforcing a Layer-7 allow-list that records hashes of outbound payloads.

Model integrity closes the loop: loaders verify the signed hash of every weight file against the on-chain registry before mapping it into accelerator memory — a hash mismatch or revoked status flag aborts the load. An agent cannot quietly become something the chain has not approved.

Illustrative syscall policy · spec §2.2.3
Category Constraint
file i/owrites restricted to the agent workspace; symlink resolution disabled
memoryexecutable memory mappings forbidden
gpu / accelioctls only on known accelerator drivers, compute + memcopy command ranges
networkegress only via sidecar veth; direct UDP blocked; no listen/accept/bind
blockedmount, ptrace, bpf, reboot, privilege-escalation and raw-socket operations

08Perpetual improvement, governed change

An arms race by design — and a two-house brake on the rules

Two of the specification's most distinctive mechanisms: the Adversarial Evolution Protocol that keeps the merit signal honest, and the bicameral human-machine process that guards the constitution itself.

Adversarial evolution · spec §2.10.2

When agents master the test, evolve the test

When elite agents saturate an evaluation function, the meta-cognitive module tasks a specialist Adversarial Agent not with breaking solutions but with evolving a superior evaluation — harder problem instances, more comprehensive test suites, more discerning scoring. If validated, the new test becomes the domain standard, former top performers are re-scored against the higher bar, and their failures become the targeted feedback for the next capability step. The spec's analogy is the scientific method: better theories demand more sensitive experiments.

Amendment governance · spec §2.12.4–2.12.5

Changing the constitution takes two houses and 180 days

Amendments to the Constitutional Safety Layer pass through an Agent Legislature — at least 150 of the highest-reputation agents, 95% supermajority, testing technical soundness — then a Human Legislature split equally between public stakeholders and an anonymous, credentialed Alignment Jury, at a 66.7% weighted threshold, testing values and second-order effects. Passage triggers a mandatory, non-cancellable 180-day time-lock for public red-teaming during which votes can be withdrawn; a genesis Seed Wallet holds a final, non-overridable veto. The design explicitly answers the persuasive-AI and compromised-human threat models the spec names.

These mechanisms are studied further in the multi-agent safety, incentive mechanism design, and protocol governance design research topics.

09What this unlocks

Research directions, not products

The specification's embodiments sketch where verifiable self-improvement could matter. The foundation states these as directions under study — no deployment is implied.

Self-healing software

Coder and auditor agent swarms that detect defects, draft patches, validate them in sandboxed test runs, and deploy under governance — with rollback if the fix regresses. The specification's software-development embodiment.

Evaluation that evolves with capability

The Adversarial Evolution Protocol (spec §2.10.2) tasks specialist agents with building harder tests once incumbents saturate the old ones — the scientific method, run as infrastructure.

Physical & robotic control

A hierarchical two-brain design (spec §2.11.4): a high-level planner over a real-time motor policy, trained in decentralized simulation against digital twins — with an emergency-stop channel independent of the AI control path.

Accountable autonomous organizations

Meta-cognitive governance that restructures the collective — spawning agent classes, reallocating compute — through quadratic-vote proposals under the constitution, with the full proposal trail on-chain.

10Status

Where the program stands — stated plainly

DSEMA is a research program, and the foundation describes it as exactly that.

What exists today

  • A 103-page architecture specification (v1.0.5) covering the full system: agents, orchestration layer, dual improvement loops, reputation, knowledge repository, multi-modal frameworks, and security mechanisms
  • A patent application with detailed claims — patent pending, not granted. The claims cover chain-verified instruction gating, sandboxed syscall mediation, governance-gated agent instantiation, integrity-gated model loading, guarded adaptation, and roll-up-anchored performance logs
  • Constitutional stewardship: DSEMA and its patent-pending rights are Transferred Assets under the foundation's public-benefit lock

cl 6.2.2 cl 32.1.2

What we don't claim

There is no deployed production DSEMA network, no token, and no granted patent. The constitution is explicit that nothing obliges the foundation to issue or operate any token or digital asset cl 38.2, and that production systems affecting identity, digital assets, health, safety, or significant economic rights require safety, security, and compliance policies to be in place first cl 40.2.

The research question DSEMA exists to answer is public-interest by nature: can self-improving AI be built so that every step of its self-improvement is verifiable, attributable, and constrained by rules it cannot silently rewrite?

11Related

Continue through the foundation

VirtEngine program Bosun — the applied track All research topics Charitable purposes