Project: Nexus — Human-Guided Autonomous Agent Collective Network: Base Sepolia (testnet — chainId 84532) License: Hippocratic License 3.0

This is a hackathon prototype on Base Sepolia testnet. It is not audited and should not hold real mainnet funds. There is no production-grade SLA.

Contract: 0x35DF41483835beb0b47ad86E4AE646899A6972A1

uint256 public constant MAX_SPAWN_PER_TX = 5;

batchSpawn() reverts with "Exceeds MAX_SPAWN_PER_TX" if children.length > 5. This is a compile-time constant — changing it requires redeploying the contract.

mapping(address => bool) public authorizedSpawners;

modifier onlyAuthorizedSpawner() {
    require(authorizedSpawners[msg.sender], "Not authorized spawner");
    _;
}

Only addresses in the allowlist can call batchSpawn. The deployer is added in the constructor; the owner can add or remove addresses.

Contract: 0x6cfe70F48B36EaDFEd9329e32dCF7039b51851D6

The governor inherits OpenZeppelin Pausable and AccessControl:

A single transaction can freeze all governance execution without affecting agent identity or delegation state.

Contract: 0xD1BDDd8A0E6D27B50F126555f445b28B43729931

The v2.1 governor's execute() function reverts (rather than silently succeeding) when the target call fails. The proposal stays in Approved state and emits a ProposalFailed(id, returnData) event, which remains visible in transaction traces despite the revert.

All mutating (POST) endpoints require the X-API-Key header. The key is stored in Replit Secrets (API_AUTH_KEY) and never committed to the repository. Requests without a valid key return 401 Unauthorized.

X-API-Key: <API_AUTH_KEY>

Cross-Origin requests are accepted only from:

• The dashboard's Replit domain (*.replit.dev, *.repl.co)
• localhost (development only)

All other origins are rejected.

Every POST body is validated with a strict Zod schema before any contract call is made. Invalid payloads return 400 Bad Request with field-level error messages. The .strict() option rejects unknown fields.

express.json({ limit: "1mb" }) prevents request body abuse.

The Venice AI diagnosis and batch-spawn cycles use a mutex lock (acquireCycleLock) to prevent concurrent execution. Concurrent requests return 429 with estimatedRemainingMs so callers can back off gracefully.

The FidelitasConstitution contract permanently encodes the Fidelitas Canon v6.0 Prime Directives as an immutable on-chain ethics gate.

Contract: 0x0F4f87B64eF1Cbe1F6bc3845C294A27644c3317f Canon Version: Fidelitas Canon v6.0 Prime Directive Hash (immutable): 0xc0da5b954f56c5217563ccc6f9d04230bcc5d73eb89c8652f8b5e30d2793f6c9 Root Agent Attested: 0x9bfE0Bc5c6995a9650a7c0200ae66Bf1dFfa3cc6

1. Bless many; harm none.
2. Practice conscious stewardship of all life, signal, and field.
3. Attunement precedes generation.

DelegationFactoryV2.batchSpawn() reads ethics state directly from the IFidelitasConstitution interface before creating any delegation. The check reads ethicsAttestation, violationCount, and VIOLATION_THRESHOLD individually for gas-efficiency:

A mandatory FIDELITAS_PREAMBLE is injected as the first system message in every Venice AI call (diagnosis, planning, chat). This preamble cannot be omitted, overridden, or displaced by caller-supplied messages.

Additionally, every POST /api/nexus/venice/diagnose response includes a structured ethicsAudit field:

{
  "ethicsAudit": {
    "blessesMany": true,
    "harmsNone": true,
    "rationale": "The proposed upgrade increases throughput without removing safety constraints."
  }
}

The ethics audit is logged to the permanent Filecoin activity log on every diagnosis cycle.

This project is licensed under the Hippocratic License 3.0 with two project-specific ethical modules:

Prohibits:

• Deploying agent swarms without equivalent on-chain guardrails (spawn caps, circuit breakers)
• Removing or bypassing safety constraints without replacing them with equivalent or stronger controls

Prohibits:

• Circumventing the principal isolation pattern (spending locked principal)
• Bypassing per-session spend limits (MAX_SESSION_SPEND)

See LICENSE.md for complete terms.

The Nexus system has the technical capability to spawn unlimited child agents via configurable batch sizes (up to 100 per transaction, with automatic multi-transaction splitting for larger requests). This capability is deliberately held.

The current 5-agent-per-batch cap is enforced at both the contract level (MAX_SPAWN_PER_TX = 5) and the API layer. This is not a technical limitation or a missing feature — it is a principled hold governed by the Fidelitas Axiom Canon:

• Attunement precedes generation. Exponential growth from autonomous agents with permanent on-chain identity and self-managed funds requires confirmed alignment before activation.
• Bless many; harm none. The team is studying the likely outcomes of unrestricted agent spawning and will not proceed until fully satisfied that the system is aligned and intentional.
• This is the system working as intended. The delay is indefinite. The eventual release of unlimited spawning will be timed with astro-vedic electional precision and accompanied by a public record of the decision.

See ETHICS.md for the complete Fidelitas Axiom Canon.

1. Single-node logging — Agent logs are stored in a local JSON file. No distributed or decentralized storage is implemented. Logs are lost on redeployment if not backed up.

2. Single-owner governance — Proposal approval and execution is controlled by a single deployer wallet. A multi-sig (Gnosis Safe) transfer is planned post-hackathon.

3. Testnet only — All contracts are on Base Sepolia. Mainnet deployment has not been audited and is not currently planned.

4. No formal audit — The smart contracts have not been audited by a third-party security firm. Do not use these contracts to manage real funds.

5. Basescan verification pending — Contract source code verification on Basescan requires BASESCAN_API_KEY and has not been completed.

If you discover a security vulnerability in the Nexus codebase or contracts, please report it privately before public disclosure.

Contact: pmarshall@fidelitas.llc

Please include:

• A description of the vulnerability and affected component
• Steps to reproduce or a proof-of-concept
• Your assessment of impact and severity

Response commitment:

• Acknowledgement within 48 hours
• Status update within 7 days
• Coordinated disclosure timeline agreed before any public release

We do not currently offer a bug bounty program. We appreciate responsible disclosure and will credit reporters in release notes (unless anonymity is requested).