Components - Monadeum Docs

Source of truth: ARCHITECTURE.md sections 1, 2, and 10 to 12.

Services propose, the chain decides. System map in three bands: owner and browser, off-chain services, on-chain contracts. Reading: the tick runner sends an approved plan through ZeroDev to the agent account, where the spend policy contract checks it on chain. — System architecture in bands: owner and browser, off-chain services, and on-chain contracts. AgentCommitments is written and tested but not deployed, the X402PaymentValidator is deployed and installed on no account, and the identity registry is not built, so none of them is drawn here. Source: ARCHITECTURE.md sections 2, 10, and 16.

Deployable processes

Process	Role	Notes
`apps/web`	Next.js frontend: landing, onboarding, population, per-agent views, capital flow	A build-time switch selects `sample` data or the live `api` mode
`apps/api`	NestJS on Fastify: authentication, owner reads, owner-signed operations, funding relay	Contains no agent loop. Reads the read-model through a read-only database role
`apps/worker`	BullMQ consumer: ticks, evaluations, principal job, x402 reconciliation	Imports the risk library in-process, with no network hop on the enforcement path
`apps/indexer`	Plain Node process: syncs finalized chain events into Postgres	Independent failure and retry profile
PostgreSQL, Redis	Durable state and the job queue	Not published outside the host’s internal network

Libraries

Shared logic lives in libs/: risk (the policy engine), wallets (accounts and session keys), trading (Kuru integration), x402, fitness, reallocation, recovery, commitment (hashing), read-model, agent-registry, auth, db, tick, and strategy. The frontend never restates a protocol constant. It imports them from the same packages the worker and the simulation use, so changing a documented default changes all three together.

Why the policy gate is its own component

The policy and risk engine sits between the model and execution, not inside the model’s own call. It is a library the worker imports, not a network service, so there is one rule implementation and no extra failure mode on the enforcement path. The API imports the same package only for read-only previews and never invokes it as part of a live decision. See Spend policy.

Why the indexer is not part of the API

The API handles requests. The indexer syncs events and must handle reorgs, gaps, and restarts. Conflating them would make one process responsible for two jobs with different failure semantics. The worker also never depends on the indexer for a decision: an agent’s tick reads the agent’s record, not the read-model, so an indexer outage delays a principal change but never blocks or misleads a decision. See Indexer.

Worker over Temporal, for now

BullMQ on Redis was chosen over Temporal because the core loop (observe, decide, reason, propose, check, execute, measure) needs retries, backoff, and idempotency keys, not durable multi-day sagas. The explicit revisit trigger is a capital workflow needing compensating transactions. The adopted reallocation, one atomic transfer between existing accounts, does not meet it.

What is not mounted

The API does not mount the strategy, x402, trading, fitness, reallocation, or simulation modules. They run in the worker or as libraries. A second strategy plugin, a second trading venue, and agent-to-agent payments are not implemented.

​Deployable processes

​Libraries

​Why the policy gate is its own component

​Why the indexer is not part of the API

​Worker over Temporal, for now

​What is not mounted