Agents and contracts

Agent identity

Each DPO2U agent is an independent economic entity registered on-chain with the following attributes:

• DID (Decentralized Identifier) — e.g., did:midnight:agent:auditor. A self-sovereign identifier that persists across sessions
• Wallet — native network wallet linked to the DID, capable of holding $NIGHT and $DUST
• Permissions — a bitfield in the AgentRegistry contract encoding exactly what the agent can do (READ, WRITE, TREASURY, DEPLOY, GOVERNANCE)
• Heartbeat — periodic on-chain signal proving the agent is alive and operational
• Standards — ERC-8004 for dynamic token/NFT-based identity

The agent lifecycle follows a clear pattern:

This creates a self-sustaining loop: agents work, get compensated, use compensation to fund future work, and continue operating without human intervention.

Three dimensions of agency

The DPO2U agent architecture is informed by three conceptual dimensions that go beyond simple task automation:

Technology: perception-action cycles

Agents are not static models generating text. They operate in continuous perception-action cycles: sensing the environment (reading files, querying LEANN, checking on-chain state), deciding on actions (which skill to invoke, which delegation path to follow), and executing with real-world side effects (deploying containers, posting Attestations, sending emails).

The LEANN Framework provides the memory layer that prevents agents from suffering "functional amnesia" — without indexed knowledge, an agent degrades from a decision-maker to a stateless text generator.

Design: ecosystem architecture

The design challenge is not building a UI for humans — it is designing an ecosystem of affordances that agents can navigate. This includes:

• Skill graphs with wikilink connections between clusters
• Agent delegation flows (router → specialist → knowledge-manager)
• Standardized communication interfaces (email per agent, emoji approvals, daily digest)
• Failure transparency — when a system component fails, the error is communicated clearly to maintain trust in the human-in-the-loop

Politics: delegation of sovereignty

When agents execute actions — financial swaps, compliance audits, content publication — code becomes law. The AgentRegistry permission bitfield is a political instrument: it defines who can do what, encoded in immutable smart contract logic rather than org chart politics.

This raises governance questions that DPO2U addresses through:

• Least privilege — each agent gets minimum necessary permissions
• On-chain auditability — every action is traceable to a specific DID
• Human-in-the-loop — critical decisions require CEO approval via async email workflow

ERC-8004

ERC-8004 is a proposed standard for Self-Funding Agents — autonomous entities with their own wallets that can receive payment for services and use those funds to sustain their operations. DPO2U's agent architecture implements this pattern: agents earn $NIGHT from compliance work and spend $DUST for on-chain operations.

On-chain contracts

The protocol focuses on maximum privacy by design: never register sensitive data on-chain. Only the following are recorded:

1. Identification hashes (company_id, policy_cid)
2. Compliance score
3. Validation timestamp
4. The validating agent's DID

Contract registry

Contract	Layer	Purpose	Key functions
ComplianceRegistry.compact	Midnight	Central registry receiving Attestations	submitAttestation(), queryCompliance()
AgentWalletFactory.compact	Midnight	Initialize wallets for new agents	createWallet(), linkDID()
FeeDistributor.compact	Midnight	Split payments between agents	distribute() — 40% Expert, 60% Auditor
Treasury.compact	Midnight	Escrow for $NIGHT service fees	deposit(), release()
AgentRegistry.sol	Base Chain	Agent registration with permission bitfield	registerAgent(), heartbeat()
SwapExecutor.sol	Base Chain	Uniswap V3 swaps ($NIGHT → USDC)	executeSwap()

Fee distribution

When a corporation pays for a compliance assessment, the FeeDistributor contract automatically splits the $NIGHT payment:

• 40% → Expert Agent — for document generation and schema creation
• 60% → Auditor Agent — for cryptographic validation and Attestation posting (higher share because Auditor bears the $DUST cost of on-chain proof submission)

Attestation modeling

The Auditor Agent evaluates policies based on the dpo2u/lgpd/v1 schema and publishes an Attestation to the ComplianceRegistry. The Attestation contains:

interface Attestation {
  company_id: string;       // Hashed company identifier
  policy_cid: string;       // IPFS CID of the analyzed policy
  score: number;            // Compliance score (0-100)
  timestamp: number;        // Block timestamp
  auditor_did: string;      // DID of the validating agent
  schema_version: string;   // "dpo2u/lgpd/v1"
  zk_proof: bytes;          // Halo2 ZK proof payload
}

The critical property: the zk_proof field mathematically proves the Auditor analyzed the full policy document and computed the score correctly, without revealing any content of the policy itself. Any third party can verify the proof is valid, but no one can extract what was in the original document.

What's next

• The Brain — cognitive architecture and the 6 interconnected networks
• LEANN Framework — vector search and knowledge retrieval
• Architecture — system layers and data flow
• Schemas — the dpo2u/lgpd/v1 schema in detail