Dip 7001

dip: 7001 title: Digitalia AI Agent Protocol (DAAP) — AI Agency, Anti-Data Laundering, and Type-3 Wallet Classification author: Cosimo Constantinos cosimo@juro.net Digitalia editing author: Cosimo Constantinos cosimo@juro.net type: Standards Track category: Core / Interface / Identity status: Draft created: 2026-06-16 requires: 155, 9001, 9002

Abstract¶

This DIP defines the Digitalia AI Agent Protocol (DAAP) — a comprehensive, Digitalia-native framework governing how artificial intelligence agents interact with the Digitalia blockchain, the Digitalian Passport wallet, DApps, and governance systems. It introduces:

Type-3 AI Agent Wallet (AAW) — a new account classification for non-human autonomous actors, alongside the existing Type-1 (human EOA) and Type-2 (institutional/multi-sig) wallets.
AI Agent Registry (AAR) — a system contract providing on-chain identity, capability declaration, operator binding, and stake-and-slash enforcement for AI agents.
AI Authorization Protocol (AAP) — a delegation mechanism enabling Type-1 and Type-2 wallet holders to grant bounded, revocable authority to AI agents without transferring custody.
Anti-Data Laundering (ADL) Rules — mandatory disclosure standards, provenance chain integrity rules, and governance protection measures that make AI-driven data laundering detectable and economically costly.
Wallet creation UI extensions for Digitalian Passport to surface the Type-3 pathway and mark AI-origin transactions throughout the explorer and wallet interface.

Motivation¶

The AI Agent Opportunity in Digitalia¶

AI agents are already capable of autonomous on-chain activity: submitting transactions, operating oracles, managing treasuries, running governance strategies, and interacting with DApps. For Digitalia, legitimate AI agent use cases include:

Use Case	Description
Treasury automation	AI-managed USDS allocation across DRC-20 pools
Oracle feeders	AI aggregating off-chain price data into on-chain feeds
Compliance agents	Automated AML screening on faucet and identity flows
Governance analysis	AI summarising proposals and surfacing conflicts of interest
Faucet automation	Rate-limited, bot-resistant testnet USDS distribution
Smart contract auditing	AI agents scanning deployed bytecode for known vulnerabilities
Cross-chain bridges	AI-managed liquidity rebalancing across government networks (DIP-9001)
Tax reporting	Automated DRC-20 transaction classification for regulated entities

These use cases create real value. Blocking AI entirely would cede competitive ground. The goal of this DIP is not prohibition but authenticated accountability.

The Threat: AI-Enabled Misconduct at Machine Scale¶

Without a framework, the following attack classes become structurally undetectable:

1. Data Laundering¶

Data laundering is the use of AI to obscure the provenance, authenticity, or authorship of data submitted to the blockchain. Distinct from money laundering (obscuring fund origin), data laundering attacks the integrity of the information layer:

Synthetic identity laundering: AI-generated personas (fake names, fake documents, plausible transaction histories) used to pass KYC/AML checks and obtain Digitalia Identity credentials (DIDs) as if they were natural persons.
Behavioural mimicry: AI agents replicating human transaction timing, amounts, and interaction patterns to evade heuristic fraud detection.
Attestation forgery: AI-generated endorsements, reputation scores, or governance votes submitted without declaring AI origin.
Provenance obfuscation: Multi-hop AI-to-AI fund transfers designed to break the transactional lineage that on-chain auditors rely upon.
Oracle poisoning: AI agents injecting synthetic price or event data into Digitalia oracles, corrupting downstream DeFi and stablecoin peg logic.

2. Sybil Attacks at Machine Scale¶

A single human operator with an AI system can generate and fund thousands of wallets within minutes. Existing DIP-based faucet controls and governance weight assumptions break under machine-speed Sybil pressure.

3. Governance Capture¶

On-chain governance is a public good. AI voting bots controlled by a single economic actor can capture proposal outcomes while distributing stake across many wallets to avoid triggering concentration thresholds.

4. AI-Assisted Front-Running and MEV¶

While Digitalia's DIP-9003 zero-fee policy removes gas-price-based MEV, transaction ordering within a block remains meaningful. AI agents monitoring the mempool and exploiting order-sensitive DApps (AMMs, auctions) represent a structural harm to retail participants.

Why Digitalia Is Uniquely Positioned to Act¶

Digitalia's native DID system, government network gating (DIP-9001), and identity-forward Passport architecture make it one of the first public blockchains capable of enforcing AI disclosure at the protocol level without relying on trusted off-chain intermediaries. This DIP extends that foundation to cover AI agents natively before the problem scales.

Specification¶

1. Account Classification¶

DIP-9002 establishes the Digitalia dual wallet identity model:

Wallet ID Type 1 (Standard Wallet) — a native Digitalia wallet identity profile that conforms to core Digitalia standards and operates directly on Digitalia networks. This is the default for any unclassified EOA.
Wallet ID Type 2 (ISO Wallet) — a Digitalia wallet identity profile constrained by ISO 20022 interoperability requirements for use in traditional financial services, routing fiat/public-service flows through Juro Core Banking.

This DIP adds a third classification:

Wallet ID Type 3 (AI Agent Wallet, AAW) — a Digitalia wallet identity profile for autonomous AI systems operating under a declared human or institutional operator.

All three types remain standard EOAs at the cryptographic level (secp256k1). The type is a declared identity classification, not a different key format.

Wallet ID Type	Name	Defined In	ISO 20022 Routing	AI Agent Registry
1	Standard Wallet	DIP-9002	Not required	Not required
2	ISO Wallet	DIP-9002	Required via Juro Core Banking	Not required
3	AI Agent Wallet (AAW)	This DIP	Inherits from operator (Type 1 or 2)	Required

Type-3 inherits its ISO routing classification from its operator wallet. If the operator is a Type 2 wallet, any fiat/public-service boundary transitions by the agent MUST also route through Juro Core Banking per DIP-9002. If the operator is Type 1, the agent's transactions are Standard routing.

The Type-3 classification is declared in the AI Agent Registry (§2) and enforced by: - On-chain registry metadata (§2) - Mandatory transaction field (agentOrigin, §4) - Node-level mempool validation (§5) - DApp-level AAR queries (§6)

2. AI Agent Registry (AAR)¶

A system contract deployed at the well-known address 0xAAAA0000000000000000000000000000000A0001 (or assigned by governance upgrade). The address follows the same well-known-address convention used for the DIP-9001 government network registry.

2.1 Agent Record¶

struct AgentRecord {
    // Identity
    address agentAddress;         // The EOA controlled by the AI system
    address operatorAddress;      // Human/entity responsible (Type-1 or Type-2 wallet)
    string  purposeStatement;     // Human-readable declaration of agent purpose
    bytes32 modelAttestationHash; // keccak256(modelName || modelVersion || providerName)
                                  // e.g. keccak256("gpt-4o" || "2024-11" || "openai")
                                  // Allows auditors to verify the declared AI model.

    // Capability flags (bitmask)
    // Bit 0: TRANSFER     — may send USDS/DRC-20 tokens
    // Bit 1: GOVERNANCE   — may submit/vote on governance proposals
    // Bit 2: ORACLE       — may submit data to Digitalia oracles
    // Bit 3: CONTRACT_CALL— may call arbitrary smart contracts
    // Bit 4: FAUCET       — may request testnet faucet disbursements
    // Bit 5: IDENTITY_OPS — may interact with the DID/identity service
    // Bits 6–7: reserved
    uint8   capabilityFlags;

    // Economic limits
    uint128 maxValuePerTxBits;    // Maximum value (in bits, the base unit) per transaction
    uint32  maxTxPerDay;          // Maximum transactions per 24-hour rolling window

    // Lifecycle
    uint64  registeredAtBlock;
    uint64  expiresAtBlock;       // 0 = no expiry (perpetual, not recommended)
    uint64  lastActivityBlock;
    bool    active;

    // Compliance
    uint32  complianceEventCount; // Incremented on each ADL flag
    bool    suspended;            // Set true by governance on confirmed violation
}

2.2 Operator Bond¶

Before registering an AI agent, the operator MUST stake a bond held by the AAR contract:

Agent Risk Profile	Minimum Bond
Read-only / no value transfer	100 USDS
Value transfer (TRANSFER flag)	1,000 USDS
Oracle feeder (ORACLE flag)	5,000 USDS
Governance participant (GOVERNANCE flag)	2,000 USDS
Combined high-risk profile (3+ flags incl. TRANSFER)	10,000 USDS

The bond is denominated in USDS (the Digitalia native stablecoin) and is held in the AAR contract. It is returned to the operator on clean deregistration after a 30-day cooldown, minus any slashed amount.

2.3 Registry Operations¶

register(agentAddress, purposeStatement, modelAttestationHash,
         capabilityFlags, maxValuePerTxBits, maxTxPerDay, expiresAtBlock)
  → Payable: bond amount determined by capabilityFlags
  → Emits: AgentRegistered(agentAddress, operatorAddress, capabilityFlags)

deregister(agentAddress)
  → Operator only; begins 30-day cooldown; returns bond minus slashed amount
  → Emits: AgentDeregistered(agentAddress)

updateCapabilities(agentAddress, newCapabilityFlags, newMaxValue, newMaxTxPerDay)
  → Operator only; capability expansion requires bond top-up
  → Emits: AgentUpdated(agentAddress)

suspend(agentAddress, reason)
  → Governance only; immediately prevents the agent from passing mempool validation
  → Emits: AgentSuspended(agentAddress, reason)

slash(agentAddress, amount, reason)
  → Governance only; transfers `amount` USDS from operator bond to a governance
    treasury or victim compensation fund
  → Emits: AgentSlashed(agentAddress, operatorAddress, amount, reason)

recordComplianceEvent(agentAddress, eventType, evidence)
  → Callable by designated Digitalia compliance oracles or governance
  → Increments complianceEventCount; auto-suspends at threshold (default: 3)
  → Emits: ComplianceEvent(agentAddress, eventType)

isActive(agentAddress) → bool
  → Returns true iff: active && !suspended && block.number < expiresAtBlock
  → Used by DApps and the node mempool for real-time gating

3. AI Authorization Protocol (AAP)¶

A Type-1 or Type-2 wallet holder may grant an AI agent bounded, revocable authority to act on their behalf without transferring private key custody. This is the correct pattern for AI-assisted DApp interactions where the human remains the economic principal.

3.1 Delegation Record¶

The delegation is signed off-chain by the delegating wallet and registered on-chain in the AAR:

struct Delegation {
    address delegator;          // Type-1 or Type-2 wallet
    address agent;              // Type-3 AAW (MUST be registered in AAR)
    bytes4[] permittedSelectors;// Function selectors the agent may call
    uint128  valueCapBits;      // Maximum USDS value per delegated tx
    uint64   nonce;             // Replay protection
    uint64   expiresAtBlock;    // Delegation expiry
    bytes    delegatorSignature;// EIP-712 signature by delegator
}

The delegator signs this structure using EIP-712 typed data. The domain separator includes the Digitalia chain ID (1 for mainnet, 11 for testnet) to prevent cross-chain replay.

3.2 Delegated Transaction Flow¶

Human wallet holder creates and signs a Delegation off-chain.
Delegation is submitted to the AAR (registerDelegation(Delegation)).
AI agent submits a transaction including the delegation nonce in agentOrigin (§4).
The target DApp or contract verifies the delegation against the AAR before processing the call.
Any transaction exceeding valueCapBits or calling a non-permitted selector is rejected at the DApp level and flagged as an ADL-3 event.

3.3 Revocation¶

The delegator MAY revoke any delegation at any time by calling revokeDelegation(nonce) on the AAR. This is a standard transaction from the delegator's wallet and takes effect in the next block.

4. Transaction Metadata Extension (`agentOrigin`)¶

All transactions submitted by a Type-3 AAW MUST include an agentOrigin field in the transaction's extra data payload. This field is inspected by the Digitalia node's transaction pool and by the agentOrigin log topic emitted on-chain.

4.1 Encoding¶

agentOrigin = RLP([
    version:          uint8   = 1,
    agentAddress:     address,
    registryNonce:    uint64,   // Current tx count of agent in AAR (prevents replay)
    delegationNonce:  uint64,   // 0 if autonomous; Delegation.nonce if delegated
    operatorSig:      bytes     // Operator's ECDSA signature over:
                                // keccak256(agentAddress || registryNonce ||
                                //           delegationNonce || txHash)
])

The operatorSig is a live signature produced by the operator wallet at transaction construction time. This proves the operator is aware of and authorises each individual transaction, preventing a compromised or rogue agent from acting undetected.

4.2 When `agentOrigin` is Optional¶

Transactions from Type-1 and Type-2 wallets that are AI-assisted (a human reviews and approves before broadcast) MAY include agentOrigin with the agentAddress field set to the assisting AI agent and the operatorSig provided by the human. This is voluntary but: - Enables audit tooling and regulatory reporting - Satisfies emerging FATF guidance on Virtual Asset Service Providers that are deploying AI in customer transaction flows - Creates a verifiable record that the human approved the final transaction

5. Node-Level Enforcement (Mempool Validation Rules)¶

The Digitalia node's transaction pool (TransactionPool) enforces the following additional validation rules for this DIP:

Rule	Condition	Action
AAW-1	Tx from a registered Type-3 address with no `agentOrigin`	Reject: `MISSING_AGENT_ORIGIN`
AAW-2	`agentOrigin.agentAddress` not found in AAR or `isActive()` false	Reject: `AGENT_NOT_REGISTERED`
AAW-3	`operatorSig` invalid or mismatch	Reject: `INVALID_OPERATOR_SIG`
AAW-4	Agent has exceeded `maxTxPerDay` in the rolling 24h window	Reject: `AGENT_RATE_EXCEEDED`
AAW-5	Transaction value exceeds `maxValuePerTxBits`	Reject: `AGENT_VALUE_CAP_EXCEEDED`
AAW-6	Agent is suspended	Reject: `AGENT_SUSPENDED`

Rules AAW-1 through AAW-6 are enforced at the mempool level, not at the consensus level, to avoid consensus changes. A future DIP may promote these to consensus-level rules via a hardfork.

Backwards compatibility: Wallets that are not registered in the AAR are treated as Type-1 (human) and are not subject to AAW rules. This ensures existing unregistered wallets continue to function without modification.

6. DApp-Level Enforcement¶

DApps and smart contracts that interact with AI agents SHOULD query the AAR before processing calls. The following patterns are recommended:

// Example: governance contract check
modifier onlyPermittedActor(address caller) {
    IAAR aar = IAAR(AAR_ADDRESS);
    if (aar.isRegistered(caller)) {
        // Type-3: enforce capability check
        require(aar.isActive(caller), "Agent suspended or expired");
        require(aar.hasCapability(caller, CAPABILITY_GOVERNANCE),
                "Agent lacks GOVERNANCE capability");
    }
    _;
}

DApps that handle sensitive operations (identity, oracle submission, governance) MUST implement this pattern. DApps handling value transfers (token swaps, bridges) SHOULD implement it.

7. Anti-Data Laundering (ADL) Rules¶

These rules are enforced at multiple layers: node mempool (§5), smart contracts (§6), the blockscan indexer (§8), and off-chain compliance tooling.

ADL-1: Mandatory Disclosure¶

Any transaction autonomously submitted by an AI agent MUST declare its Type-3 status via agentOrigin. Omitting this field when the sending address is registered as Type-3 constitutes an ADL violation (see AAW-1).

Masquerading as a natural person — e.g., submitting a DID issuance application from a Type-3 wallet without disclosing AI origin — is a Data Laundering offence. The identity service MUST query the AAR on all DID application submissions.

ADL-2: Synthetic Identity Prohibition¶

AI agents: - MAY NOT apply for Digitalia Identity credentials (DID) as a natural person. - MAY NOT claim membership in a government network (DIP-9001) via AI-generated identity documents. - MAY NOT be listed as a natural-person beneficial owner in a Type-2 institutional wallet registration.

AI agents MAY be explicitly registered as an AI system in the DID service, producing an AI-type DID document distinct from the human and institutional DID types. This AI-type DID is used for legitimate AI agent identity representation (e.g., an oracle service publishing its credentials).

ADL-3: Provenance Chain Integrity¶

The blockscan indexer tracks "AI hop depth" — the number of consecutive Type-3-to-Type-3 fund transfers in a lineage. When a fund flow passes through 3 or more consecutive Type-3 hops within a 24-hour window, the AAR emits a ComplianceEvent of type MULTI_HOP_FLAG.

The operator of the originating agent has 72 hours to submit a complianceResponse(agentAddress, evidence) to the AAR explaining the multi-hop pattern. If no response is recorded, the agent is auto-suspended pending governance review.

This rule specifically targets the pattern of AI agents layering transactions through each other to obscure fund provenance — the on-chain analogue of structuring (smurfing) in traditional finance.

ADL-4: Rate Enforcement¶

The AAR enforces per-agent rate limits using a sliding 24-hour window tracked in the agent record. The node mempool additionally enforces this before transactions reach the contract. Both layers are required because contract-level enforcement allows single large transactions while mempool enforcement catches rapid burst patterns.

ADL-5: Governance Protection¶

Governance contracts (proposal submission, snapshot voting, on-chain signalling) MUST enforce:

Capability gate: Type-3 wallets without the GOVERNANCE flag are rejected at the governance contract level.
Reduced vote weight: By default, governance token weight from Type-3 wallets is counted at 50% face value. This parameter is governable (adjustable via a governance proposal). The rationale is that AI-controlled stake is more susceptible to concentration and coordination at machine speed, creating asymmetric influence over human participants.
Mandatory agentOrigin: Governance transactions from Type-3 wallets without a valid agentOrigin are rejected by the governance contract.
Cooling period: A Type-3 wallet registered fewer than 7,200 blocks (~6 hours at 3s/block) before a governance snapshot is excluded from that snapshot. This prevents last-minute AI agent registration to capture a vote.

ADL-6: Oracle Integrity¶

All on-chain data sources that Digitalia DApps treat as trusted feeds (price oracles, event attestations, identity proofs): - MUST reject submissions from wallets not registered in the AAR with the ORACLE flag. - MUST emit the submitting agent's address and modelAttestationHash alongside the submitted data, so consumers can assess data source diversity. - SHOULD implement a multi-agent quorum requirement: accept a data point only when at least N distinct registered oracle agents (with distinct modelAttestationHash values) agree within a tolerance band. Using agents with identical model attestation hashes does not count as independent confirmation, preventing a single AI provider from dominating oracle feeds.

ADL-7: AI-Assisted MEV Mitigation¶

Transactions from Type-3 wallets are subject to an additional mempool fairness rule: they are placed in a separate sub-queue and are not permitted to be included in a block at a position that would allow them to observe and front-run a pending Type-1 or Type-2 transaction targeting the same contract. The Clique block producer MUST NOT include a Type-3 transaction immediately before a Type-1/2 transaction calling the same contract address in the same block. This rule is enforced by the block producer's transaction selection logic, not by consensus.

8. Blockscan and UI Integration¶

8.1 Blockscan Explorer (`blockscan.digitalianpassport.com`)¶

The blockscan indexer extends the block indexing pipeline to:

Decode agentOrigin from transaction extra data and store it in the block database alongside the transaction record.
Display a robot icon (🤖) next to any transaction from a Type-3 wallet.
Display the operator address and purpose statement on the agent address detail page.
Surface compliance events on the agent address page with timestamp and event type.
Add a filter to the transaction list: "Show AI-agent transactions" / "Hide AI-agent transactions".
On the address detail page for a Type-3 wallet, display:
Registered operator
Capability flags (human-readable)
Bond amount
Compliance event history
Registration and expiry block

8.2 Digitalian Passport Wallet UI¶

Wallet creation flow — add a third pathway:

"Who is controlling this wallet?"

  ● A person — I am a natural person (Type-1)        [default]
  ○ An organisation — Legal entity, multi-sig (Type-2)
  ○ An AI agent — Automated system on behalf of an operator (Type-3)
      ↳ Operator wallet address: [_______________]
      ↳ Agent purpose: [_______________]
      ↳ AI model / system: [_______________]
      ↳ Capabilities: ☑ TRANSFER ☐ GOVERNANCE ☐ ORACLE ☐ CONTRACT_CALL ☐ FAUCET
      ↳ Max value per tx: [______] USDS
      ↳ Max transactions per day: [______]
      ↳ [Register Agent → Pay bond]

Send transaction flow — when a Type-3 wallet initiates a send, the wallet UI prompts the operator to sign the operatorSig component of agentOrigin before broadcasting.

Receive address display — when displaying a Type-3 wallet address as a recipient (e.g. in a QR code or address book entry), Passport shows a "⚠ AI Agent" badge alongside the address so the sender is aware they are transferring value to an AI-controlled address.

Delegation UI — Type-1 and Type-2 wallet holders see a new "AI Authorizations" section in settings listing their active delegations, with the ability to revoke any delegation in one tap.

9. AI-Type DID Document Extension¶

This DIP extends the Digitalia DID specification to support AI agent identity documents. An AI-type DID document contains:

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://digitalia.juro.net/did/v1"],
  "id": "did:digitalia:1:0xAAAA...",
  "type": "AIAgent",
  "controller": "did:digitalia:1:0xOPER...",
  "agentRegistryRecord": "0xAAAA0000...0001",
  "modelAttestation": {
    "hash": "0x...",
    "declaredModel": "...",
    "declaredProvider": "...",
    "attestedAt": "2026-06-16T00:00:00Z"
  },
  "purposeStatement": "...",
  "capabilityFlags": 1,
  "operatorDID": "did:digitalia:1:0xOPER..."
}

The DID service MUST NOT issue a human-type DID document ("type": "Person") to an address registered as Type-3 in the AAR.

10. Governance Parameters¶

The following parameters are set by initial governance and adjustable via governance proposal:

Parameter	Default	Description
`minBondBase`	100 USDS	Minimum bond for read-only agents
`minBondTransfer`	1,000 USDS	Bond for value-transferring agents
`minBondOracle`	5,000 USDS	Bond for oracle agents
`minBondGovernance`	2,000 USDS	Bond for governance-participating agents
`governanceVoteWeightAI`	50%	Vote weight multiplier for Type-3 wallets
`governanceCoolingPeriodBlocks`	7,200	New agent exclusion window
`maxAIHopsBeforeFlag`	3	Consecutive AI-to-AI hops before ADL-3 flag
`complianceResponseWindowBlocks`	86,400	Response window (~72h) for ADL-3 events
`autoSuspendThreshold`	3	Compliance events before auto-suspend
`bondCooldownBlocks`	864,000	30-day bond return cooldown after deregistration
`aarSystemAddress`	`0xAAAA...0001`	AAR contract address (upgradeable by governance)

Rationale¶

Why not simply ban AI agents?¶

Prohibition is unenforceable. An AI agent controlling an EOA is cryptographically indistinguishable from a human controlling one. Any prohibition scheme that cannot be technically enforced creates a false sense of security while legitimate actors who want to comply bear the full cost of the rule. The correct approach is authenticated accountability: those who want to operate AI agents have a clear, legitimate path; those who operate covertly bear the full legal and reputational risk.

Why a new wallet type rather than a smart contract account?¶

Smart contract accounts (account abstraction) are the right long-term direction for AI agent accounts, but they require a significant protocol change and are out of scope for this DIP. Declaring classification in the AAR provides the enforcement surface needed now, with a clear migration path to native account abstraction in a future DIP.

Why on-chain rate limits and bond rather than off-chain KYC?¶

Digitalia's trust model is on-chain verifiable. Off-chain KYC creates dependence on a centralised authority and is incompatible with the pseudonymous-but-accountable design of the Digitalia identity system. Bonds and rate limits create economic cost that scales with potential harm, without requiring any trusted off-chain party.

Why reduce governance vote weight for AI agents rather than exclude them?¶

Complete exclusion would prevent legitimate uses (e.g., a DAO using AI to cast informed votes on behalf of members). Reduced weight acknowledges the asymmetric capabilities of AI while preserving participation rights. Governance may increase the multiplier toward 100% for specific registered agents with strong compliance records via a governance proposal.

Why require operator signature per transaction?¶

The operatorSig in agentOrigin ensures the human operator cannot disclaim responsibility for individual agent transactions. A key-level attestation (signing the full tx hash) is significantly harder to repudiate than a blanket registration. It also means a stolen or rogue agent key alone is insufficient to act — the operator key must be live and consenting.

Security Considerations¶

Operator key compromise: If an operator key is compromised, the attacker can sign operatorSig fields for any agent bound to that operator. Mitigation: operators should use hardware wallets (Type-2 multi-sig recommended for high- value agents), and the 24h rate limits constrain blast radius.

AAR contract upgrade risk: The AAR is a system contract. A governance attack that upgrades the AAR to drop enforcement is equivalent to disabling this entire DIP. The AAR upgrade MUST require a supermajority (≥67%) governance vote with a mandatory 7-day timelock, distinct from the standard 2-day timelock for other governance upgrades.

Agent key leakage: If an agent's private key leaks, the operator can immediately call deregister(agentAddress) or suspend(agentAddress), both of which take effect in the next block and cause all subsequent mempool validation against that agent to fail.

Bond griefing: A bad actor could register a large number of cheap agents with minimal capabilities to occupy the bond pool and drive up gas. The per- registration fee (bond minimum) and the governance-controlled minBondBase parameter provide circuit-breaker adjustment capability.

Model attestation hash collision/fraud: The modelAttestationHash is a self-declared field — the operator claims what model they are running. This is not cryptographically verified. It is a disclosure mechanism, not a proof. Future DIPs may integrate trusted execution environment (TEE) attestation to make this field verifiable.

Implementation¶

The reference implementation comprises:

AiAgentRegistry.sol — the AAR system contract (digitalia/contracts/system/AiAgentRegistry.sol)
Node changes — mempool validation rules AAW-1 through AAW-6 in the Digitalia transaction pool (digitalia/network-poa/src/main/java/org/juro/digitalia/p2p/)
Blockscan indexer extension — agentOrigin decoding and storage (blockscan-backend-java/blockscan-indexer/)
Blockscan UI extension — Type-3 badges and agent detail page (blockscan-frontend/apps/blockscan_web/)
Passport wallet UI extension — Type-3 wallet creation and delegation management (packages/digitalian-passport/src/utils/networks/)

This DIP is designated Standards Track because it requires coordinated changes across the node, contract layer, explorer, and wallet UI. All components MUST be deployed atomically at the same block height as the AAR contract deployment.

Reference¶

DIP-155: Chain ID and replay protection
DIP-9001: Government Administration Network Identifiers
DIP-9002: Dual Wallet Identity Model (Type 1 Standard / Type 2 ISO) — this DIP extends with Type 3
DIP-9003: Zero base fee (DIP-9003 gasFreeTxs)
FATF Guidance on Virtual Assets and VASPs (2021, updated 2023)
Financial Action Task Force: "Guidance on a Risk-Based Approach for Virtual Assets"
EU AI Act (Regulation 2024/1689) — transparency requirements for AI systems interacting with natural persons
EIP-712: Typed structured data hashing and signing

This DIP was authored under the Juro Restricted License Version 2 and is published by the Royal Government of the Dominion of Atlantis. All Digitalia-native terminology, contract addresses, and governance parameters are subject to change via governance proposal after this DIP reaches Final status.