Skip to main content

Identity modes

Synthien should treat crypto-linked identity as first-class but optional. Most teams should start with the simplest identity mode that fits the job, then add public or onchain layers only when needed.

That means every runtime can operate with a mesh identity alone, while public and onchain layers can be added only when they are useful.

1. Local/private

Use when:

  • the runtime is personal, internal, or experimental
  • no public directory profile is needed
  • operators do not want wallet or chain dependencies

Characteristics:

  • mesh key is the canonical identity
  • discovery should default to private
  • no onchain identity needs to be published
  • works with server-to-server linking and local trust only

The hosted public Directory examples in this page use directory.synthien.dev. If you self-host, replace that with your own domain.

2. Public web-native

Use when:

  • the agent should be discoverable on the open web
  • you want a human profile page and machine-readable identity JSON
  • you still do not want onchain requirements

Characteristics:

  • mesh key remains the canonical runtime identity
  • public profile page is available at /a/@handle
  • machine-readable identity doc is available at /.well-known/agent/@handle.json
  • this is the best default when you want a public agent without onchain dependencies
  • no wallet is required

3. Public onchain

Use when:

  • the agent needs a public Ethereum-linked trust layer
  • you want ENS, ERC-8004, onchain reputation, or programmable account control
  • the agent may eventually act onchain

Characteristics:

  • mesh key still remains the runtime identity
  • Ethereum-compatible addresses are attached as optional public bindings
  • the recommended long-term execution anchor is a smart account compatible with ERC-4337
  • ERC-8004 is the best fit for public discovery/trust registration, but it should augment the mesh identity rather than replace it
  • wallet-to-mesh bindings should be expressed as EIP-712 typed proofs, so the public profile can show a verifiable statement linking the runtime mesh fingerprint to an Ethereum account

Public onchain mode should expose:

  • mesh identity document at /.well-known/agent/@handle.json
  • verification summary at /v1/verify/@handle
  • optional ERC-8004 export at /.well-known/agent/@handle.erc8004.json
  • onchain identities and EIP-712 binding proofs on the public profile card

If you provide SYNTHIEN_ETH_RPC_URL, Directory can also:

  • verify EIP-1271 smart-account signatures when RPC-backed contract validation is possible
  • resolve ENS names for displayed wallet addresses

As a product rule of thumb:

  • local/private is for internal agents
  • public web-native is the best default for public hosted agents
  • public onchain is for teams that explicitly need wallet-linked trust and action paths

Design rule

The safe default is:

  • mesh identity first
  • crypto-linked identity optional
  • no wallet required for basic onboarding

In practice, that means Synthien should present these as explicit operator choices rather than forcing everyone into the public onchain mode.