Mettalex case study

This page is a historical architecture case study of Mettalex, an independent project that used Fetch.ai uAgents in a peer-to-peer (P2P) order-book DEX design. It is not a live trading tutorial and not a Fetch.ai-operated product.

For runnable Fetch.ai on-chain samples, use the on-chain overview and BNB Chain Agents pages instead.

Product status (as of 27 February 2026)

Mettalex contributors announced they are discontinuing Mettalex as an actively operated trading product. Mettalex V2 remained beta-only and was not released as a production mainnet exchange. Read the primary source: An operational transition for Mettalex (27 February 2026).

The former public beta host https://beta.mettalex.com/ did not resolve in DNS when this page was last checked (25 August 2026). This case study does not link that URL.

Verified against public Mettalex pages on 25 August 2026 (re-checked 1 September 2026). Architecture details below follow Mettalex’s own docs and the February 2026 transition post, not current product operations.

What Mettalex was designed to do

Mettalex marketed itself as a P2P order-book DEX for tokenized commodities and other digital assets, using autonomous agents for matching and on-chain escrow for settlement. Mettalex 101 still uses “world’s first” language; treat that as Mettalex marketing, not an Innovation Lab claim.

The design goal was to match a buyer and a seller at an agreed price (no AMM pool in V2), which can yield zero price difference versus the match when a counterparty exists. Competitive liquidity for a live venue did not materialize, per the transition post. Trades still carry counterparty, bridge/cross-chain, escrow-contract, and operational risk.

Mettalex is an independent project with a history of Fetch.ai technology and support. Fetch.ai does not operate the exchange.

Canonical docs: Mettalex Docs, Mettalex 101. Prefer the .ai host (the older mettalex.com docs URL only redirected).

Architecture in a nutshell

Five feature groups from the V2 design, not a promise of a live venue:

Direct P2P order matching

• No AMM pools in V2: Agents were intended to match buyers and sellers directly rather than route through a liquidity pool.
• Agreed-match execution: When two sides match, the intended fill is the price both parties agreed — not an AMM curve. That only happens if a counterparty is found.

Escrow-backed settlement

• On-chain escrow: Traders lock funds in escrow contracts. Settlement is meant to complete only when contract conditions are met.
• Fail-safe: If settlement does not complete, the escrow contract refunds or releases funds according to its fail-safe rules when the relevant parties or agents call those functions. Agents do not unilaterally “revert” chain state.

Wallets and networks (historical beta)

Wallet- and chain-agnostic language was a design goal. The last documented public beta (cross-chain user guide) was scoped to Fetch Dorado testnet (ASI Wallet / Keplr) and Polygon Amoy testnet (MetaMask), using testnet tokens only — not arbitrary wallets or mainnets in parallel.

Registration and discovery (two layers)

Do not treat “query the Fetch Almanac → trade commodities” as Mettalex’s user-facing discovery path.

1. Mettalex on-chain mapping: Onboarding docs describe a backend Agent Factory, then the user mapping the agent on an Agent Map contract and creating escrow via an Escrow Factory. See Initializing your account.
2. Fetch uAgents Almanac: Almanac is the Fetch.ai uAgents directory (identity/discovery on the Fetch network). It is a separate layer from Mettalex’s escrow/agent maps. This case study does not claim Almanac was the primary Mettalex marketplace directory.

Transparency vs governance

• On-chain vs agent logs: Escrow create/lock/release events live in public chain explorers (for example MTLX on Etherscan for the ERC-20). Historical Mettalex UI copy also described off-chain user-agent logs in the product interface. Those are not the same as on-chain receipts, and the beta UI is not linked here.
• MTLX: MTLX continues to exist as an ERC-20. As of the 27 February 2026 notice, Mettalex makes no promises of utility, value accrual, or token-led outcomes. Do not treat MTLX as active agent-driven governance that automates fee changes or upgrades. Older tokenomics and 101 governance text are superseded by that notice for utility claims.

Historical flow (who signs what)

Aligned with Initializing your account and The middleware architecture:

1. The user wallet submits onboarding and trade-related transactions (agent mapping on the Agent Map, escrow creation via the Escrow Factory, fund locks).
2. A backend Agent Factory creates the agent record used by the product; the agent is then mapped on-chain.
3. After a match, agents exchange signatures and trade parameters; escrow contracts verify those parameters and signatures, then transfer or release funds per the contract.
4. Settlement pays each side the agreed assets if contract checks pass. If they do not, fail-safe contract paths apply (including the documented cross-chain pull path in cross-chain transactions).

Cross-chain (design vs marketing)

Mettalex marketing sometimes said trade “without bridging.” Architecture docs describe agents listening on multiple chains, with users locking in per-chain escrows, then a push transfer path and a pull fail-safe — not a claim that assets move with no cross-chain mechanism.

The transition post describes a working P2P system across Cosmos and Ethereum-ecosystem testnets in beta, not a production mainnet venue.

Hands-on Fetch.ai examples

This page has no runnable uAgents sample. Build on-chain agents here:

• AI Agents Reshaping the On-Chain Ecosystem
• BNB Chain Agents

Disclaimer

This page is for historical and educational context only. It is not financial, legal, tax, or investment advice, and not an offer to buy, sell, or hold any token. Interacting with smart contracts, DEX UIs, and tokens (including MTLX) is at your own risk. Mettalex’s February 2026 notices apply to product and token expectations; see An operational transition for Mettalex.