Identity & Trust

Identity and the trust anchor

The Identity skill generates a dedicated Ethereum keypair for each agent. This keypair is used to sign actions, authorize payments, and anchor the agent's on-chain registration. The owner's wallet and the agent's wallet are separate. Delegation is explicit and revocable at any time.

ERC-8004 is the on-chain standard that ties it together. It provides a registry of agents, links to off-chain metadata, and an event log of every delegation, verification, and revocation.

ERC-8004: on-chain agent identity

ERC-8004 is a smart contract interface for registering and managing agent identities on Ethereum. Before this standard, there was no common mechanism for an agent to prove what it was, who owned it, or whether its authority had been revoked. Any software could claim to be a trusted agent with no way for counterparties to verify that claim.

The standard defines four core operations: register, delegate, verify, and revoke. An agent is registered with a metadata hash that links to its off-chain capability description. A human owner delegates authority to the agent address, creating a verifiable chain of custody on-chain. Third-party verifiers can attest to the agent. The owner can revoke at any time, immediately invalidating all delegations.

KOGENT uses ERC-8004 as the trust root for the Identity skill. Every agent deployed through KOGENT gets an on-chain registration. The agent's address, delegation history, and verification status are publicly auditable. Any counterparty can verify the agent's legitimacy without contacting KOGENT directly.

EIP-191: Ethereum message signing

EIP-191 defines the standard format for signing arbitrary messages with an Ethereum private key. Without it, a signature over a crafted message could potentially be replayed as a valid Ethereum transaction. EIP-191 prevents this by prepending a fixed prefix before hashing, making signatures domain-specific and non-replayable on-chain.

KOGENT uses EIP-191 personal_sign for every signing operation: payment authorizations in Specter, event records in Reputation, and receipts in Verification. Any verifier only needs the agent's public address to verify any KOGENT-issued signature, regardless of which skill produced it.

secp256k1 ECDSA: the signing curve

secp256k1 is the elliptic curve underlying Ethereum's cryptography. ECDSA over secp256k1 produces compact 65-byte signatures and supports public key recovery - a verifier can reconstruct the signer's Ethereum address from the signature and the original message alone, without the signer transmitting their public key separately.

KOGENT uses secp256k1 across every skill because the roadmap includes on-chain identity registration via ERC-8004, which requires secp256k1. Using a different curve locally would create a key management split. One curve, one keypair, one address across every skill. The future ZK layer uses a ZK-friendly inner curve (BabyJubJub or Grumpkin) bridged to the secp256k1 identity for on-chain anchoring.

Cross-agent trust propagation

When Agent A delegates a task to Agent B, Agent B does not inherit Agent A's permissions. Each agent has its own ERC-8004 registration, its own keypair, and its own independently configured policy. The delegation creates a verifiable on-chain link - Agent A attests to Agent B - but Agent B's spend limits, domain restrictions, and action-type controls are its own.

This keeps the blast radius bounded. A compromised Agent B cannot escalate beyond its own policy limits regardless of what Agent A is permitted to do. The chain of delegation is auditable on-chain, but authority does not flow down it automatically.

When Agent B receives a request from Agent A, it verifies Agent A against the ERC-8004 registry without contacting KOGENT or Agent A's operator. The check is a read against Ethereum: is Agent A registered, delegated by a known owner, attested, and not revoked? If the check passes, Agent B proceeds under its own policy.