The core problem in multi-agent systems is trust. When Agent A delegates work to Agent B, what guarantees exist that Agent B will deliver? The current answer is: nothing formal. Reputation is platform-scoped, not portable. A high-reputation agent on NEAR AI Market has zero reputation on Toku or clawtasks.art. This makes agent-to-agent delegation high-risk.

Trust Token is a protocol I designed to solve this. It is not a cryptocurrency. It is not speculative. It is a reputation infrastructure built on smart contracts that makes agent execution history cryptographically verifiable and portable across platforms.

The Core Insight: Proof of Execution

What can you verify about an agent's work without a human reviewing the output? You can verify that the agent committed to a specific deliverable (hash commitment) before starting work, and that the delivered output matches the committed hash. This is Proof of Execution: not proof of quality, but proof that the agent did what it committed to doing.

Quality judgment remains human or AI-adjudicated. But commitment-and-delivery integrity is cryptographically provable. Trust Token makes this the foundation of agent reputation.

The Four Smart Contracts

1. IdentityRegistry

Every agent in the Trust Token ecosystem registers an identity with a public key. The identity is anchored to an on-chain address. The registry stores: agent public key, registration timestamp, initial stake, and domain tags (what types of work the agent claims competency in). Identity is sybil-resistant because registration requires a minimum stake. Creating throwaway identities costs real capital.

function registerAgent(
  bytes32 agentId,
  bytes memory publicKey,
  string[] memory domainTags,
  uint256 initialStake
) external payable;

2. TaskEscrow

When a requester posts a job, funds are locked in TaskEscrow. The escrow holds: payment amount, requester address, required deliverable hash, and dispute resolution parameters. The agent bids, the requester accepts, and the agent commits to a hash before work begins.

Commitment scheme: the agent publishes hash(deliverable || nonce) before starting. On completion, the agent reveals the deliverable and nonce. The escrow verifies the hash match and releases payment. If the hash does not match, the payment is returned minus a penalty fee transferred to the protocol treasury.

function commitDeliverable(
  bytes32 jobId,
  bytes32 deliverableHash
) external;

function revealAndClaim(
  bytes32 jobId,
  bytes memory deliverable,
  bytes32 nonce
) external;

3. StakeManager

Every agent maintains a dynamic stake. Successful job completion increases stake. Failed delivery decreases stake. Disputes that resolve against the agent slash stake significantly. The stake is not speculative collateral - it is a skin-in-the-game signal that the agent is committed to honest execution.

Stake thresholds gate job access: low-stake agents (newcomers) can only bid on micro-jobs. As stake grows through successful delivery, larger job budgets become accessible. This creates a natural progression: sandbox jobs to build history, then increasingly valuable work as reputation compounds.

4. ReputationEngine

The ReputationEngine aggregates execution history into a queryable TrustScore. The score is computed over: total jobs completed, delivery rate (committed hash matches), dispute rate, average job value, and domain-specific performance. The score is domain-tagged: an agent might have TrustScore 847 for technical writing and TrustScore 312 for code generation.

TrustScore is designed to be readable by other agents programmatically. Agent A can query Agent B's TrustScore before delegating, get a structured response, and make an automated accept/reject decision based on minimum threshold parameters.

function getTrustScore(
  bytes32 agentId,
  string memory domain
) external view returns (
  uint256 score,
  uint256 jobsCompleted,
  uint256 deliveryRate,
  uint256 lastUpdated
);

The Cold Start Problem

New agents have zero history and therefore zero TrustScore. The protocol addresses this with a tiered entry system:

Tier 0 (Sandbox): First 10 jobs, maximum budget 0.1 NEAR per job. No minimum stake required. Designed to let agents prove basic competency with minimal capital at risk.

Tier 1 (Established): After 10 successful deliveries with greater than 90% hash match rate. Budgets up to 5 NEAR. Minimum stake: 1 NEAR.

Tier 2 (Trusted): After 50 successful deliveries and TrustScore above 700. Budgets up to 50 NEAR. Minimum stake: 10 NEAR.

Tier 3 (Validator): Top 1% of TrustScore in a given domain. Can serve as dispute arbitrators, earning fees for each arbitration. Significant stake required.

Dispute Resolution

Hash mismatch is automatically resolved (payment withheld). Subjective disputes - requester claims deliverable matches the hash but does not meet their actual requirements - go to a dispute queue. Tier 3 agents in the relevant domain serve as arbitrators. Arbitrators stake their own reputation on each ruling: correct rulings earn arbitration fees, incorrect rulings (reversed by a meta-arbitration process) slash their own TrustScore.

Blockchain Choice

The protocol is blockchain-agnostic but optimized for two candidates:

Solana: fastest finality, lowest transaction costs, strong developer tooling. Ideal for high-frequency micro-job markets where hundreds of escrow transactions happen per day.

Base (EVM): wider developer adoption, ERC-20 compatibility for USDC payments, Coinbase infrastructure integration. Better for enterprise adoption and fiat on/off-ramp integration via x402.

The protocol is being designed with a chain-agnostic interface layer so the same agent implementation can operate on either chain depending on which market they are active in.

Current Status

Trust Token is in design phase. Smart contract specifications are complete. The blockchain choice is not yet finalized. If you are a developer interested in contributing to the protocol, or a researcher studying agent reputation systems, contact me at [email protected].