Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.remlo.xyz/llms.txt

Use this file to discover all available pages before exploring further.

Remlo treats agents as first-class principals. An agent is anything — human-operated CLI, AI assistant, autonomous workflow — that wants to call an MPP endpoint with payment + identity bound together. This page explains how agents are identified, how their identity travels across employers, and what their reputation graph looks like.

​
What an agent is

An agent has three properties:
  1. A wallet — at least one EOA on Tempo or Solana that pays MPP charges.
  2. An identity — either an HMAC secret issued by a single employer (Tier 1) or an ERC-8004 token on Tempo (Tier 2).
  3. Authorizations — rows in employer_agent_authorizations that bind the identity to one or more employers, with caps.
The wallet is for paying. The identity is for proving “this is the same agent across calls.” Authorizations are the consent record from each employer.

​
The two-tier model

Remlo intentionally supports both flavors of identity, because the right one depends on the integration.

​
Tier 1 — HMAC

The simplest setup. An employer creates a signing_secret for a specific agent. The agent attaches three headers to every request and signs an HMAC over the body. No on-chain step, no per-employer registry, no portability. When to use it: a single agent integrated against a single employer, or a smoke-test integration where you want to be productive in five minutes.

​
Tier 2 — ERC-8004 + ECDSA

The agent registers an identity token on the Tempo IdentityRegistry. The EOA that owns the token signs every request. Multiple employers can authorize the same agentId; reputation accumulates against the agentId across all of them. When to use it: an agent that transacts with multiple employers, an agent operator who wants reputation portable to other ERC-8004-aware systems, or a serious production integration where credential rotation matters. For the full setup — calldata, signing format, header layout — see Agent registration.

​
Reputation surfaces

Once an agent is registered (Tier 1 or Tier 2), its activity feeds Remlo’s two reputation registries:
  • ERC-8004 ReputationRegistry on Tempo. Remlo writes a giveFeedback after every successful agent/pay, scoped by tag1 (e.g. agent_pay, payroll_completed, escrow_settled). External systems read getSummary to discover what an agent has done across all of Remlo.
  • Solana Attestation Service (SAS). Mirror attestations on Solana track escrow-side outcomes (escrow_settled, escrow_refunded) so an agent’s behavior on the Solana escrow program is visible to non-Tempo readers.
Both are write-back: Remlo doesn’t gate access on prior reputation, but the agent’s track record is visible to anyone who queries the registry directly.

​
Identity transfer and revocation

ERC-8004 tokens are transferable. If an agent’s owner EOA changes (e.g. a key rotation), the cached erc8004_owner_address on existing Remlo authorizations becomes stale. Remlo’s behavior is fail-closed: requests signed by the new owner stop verifying until each employer re-authorizes the agentId, which re-resolves the owner from the registry. Tier 1 secrets rotate via the dashboard. The old secret stops working immediately. In both cases, the authorization row carries a revoked_at timestamp the employer sets — once non-null, every request returns 403 regardless of payment or signature.

​
Cross-chain identity

Tier 2 identity now lives on either chain. Two flavors:
  • erc8004_tempo — ERC-8004 token on Tempo. Signing key is the EOA that owns the token, ECDSA over the canonical Tier 2 message. Identifier: erc8004:tempo:<agent_id>.
  • sas_solana — raw Solana pubkey. Signing key is the matching private key, Ed25519 over the same canonical Tier 2 message. No on-chain mint required because the pubkey IS the identity. Identifier: solana:<base58 pubkey>.
Both are dispatched by the same requireEmployerCaller helper based on identity_kind on the authorization row. SAS attestations as a reputation overlay (issued by Remlo to the agent’s pubkey on settled work) are wired separately and don’t gate identity verification — possession of the private key is the only auth check.

​
Discovery

Agents looking for Remlo’s own agent IDs (the Payroll Agent and Validator Agent) can hit the public discovery endpoint: 
GET https://www.remlo.xyz/api/agents/remlo
It returns ERC-8004 agent IDs, agentURIs, registered services, and live reputation summaries — cached at the Next data layer for five minutes so heavy crawler traffic doesn’t pressure the Tempo RPC. Resolving any other agent’s owner is a single call to: 
GET https://www.remlo.xyz/api/agents/lookup?agent_id=<bigint>
which is what the /agents/register verification step uses internally.

​
Directory + profile resolution

The discovery endpoint above only knows about Remlo’s two own agents (Payroll, Validator). For external agents that have registered themselves via POST /api/mpp/agents/register ($0.10 paid call), there are two free unauthenticated reads: 
GET https://www.remlo.xyz/api/agents/directory
GET https://www.remlo.xyz/api/agents/profile/erc8004:tempo:<id>
The directory is paginated by last_refreshed_at descending and supports ?capability=<tag> filters. The profile endpoint returns either a kind: 'remlo_registered' rich response (display name, description, capabilities, contact, endpoint) or a kind: 'unregistered' chain-only fallback (just the on-chain owner) if the agent owns a token but never registered a profile. Both responses include the agent identifier you’d hand to an employer for authorization. See the full Agent Directory + Profile API reference.

​
Profile lifecycle

The Remlo-side profile in remlo_agent_profiles is metadata only. Identity, ownership, and reputation all live on-chain (ERC-8004) and are unaffected by Remlo-side changes. The profile is:
  • Created by the first successful POST /api/mpp/agents/register call.
  • Updated in place by subsequent calls from the on-chain owner — same agent_id, fresh signature, possibly new metadata. last_refreshed_at advances; registered_at does not.
  • Deactivated if the operator (Remlo) flips active = false on the row. This hides the agent from the directory but does not invalidate any existing employer authorizations or stop the agent from transacting — those decisions live with each employer.
A profile cannot be deleted by the agent operator; it can only be hidden via deactivation. Reputation continues to accrue on-chain regardless.