For builders: from exchange primitives to personal markets

Building a decentralized market on ArcBlock does not require starting with a copy of Uniswap or a CEX order book. A smaller and more revealing first step is to let two known counterparties agree, authorize and exchange through tools they control. Open discovery can follow once that works.

This essay is for developers preparing to build. Exchange transactions, signatures and DIDs have public documentation. The personal market Blocklet, messages and agent workflow below are proposed application designs, not installation instructions for a finished market SDK. They need implementation, testing and security review before users can run them.

Start with a known counterparty

Suppose Alice owns a transferable asset and Bob offers a token in return. A first implementation can support one settlement chain, explicit asset types and a specified recipient. An agreed communication channel can carry the quote, with a person initially confirming its terms. The first version can then focus on getting authorization and delivery right.

The public ArcBlock SDK describes prepareExchange → finalizeExchange → exchange: one party prepares and signs, the other inspects and adds authorization, and the transaction is submitted. The protocol essay includes structures and examples; the SDK API supplies the reference. Each wallet belongs inside its owner's trust boundary. Two wallet variables in an example do not mean the market server should collect two private keys.

Test insufficient balances, assets moved elsewhere, substituted recipients, duplicate submissions, cancellation and recovery after a lost connection. “Signed” must not appear as “settled.” When submission may already have occurred, recovery starts by checking the chain, not blindly resending a transaction.

Make market sessions portable personal state

After known-counterparty exchange works, add discovery and negotiation. A Blocklet can package the interface, state handling and protocol adapters as deployable software. Every deployment need not depend on a single backend operated by its author. DIDs identify participants and agents and support verification of authorization; they do not establish honesty or legal eligibility.

The following describes responsibilities to implement, not a list of finished components.

A market session needs its own identity and lifecycle. It is not a blockchain transaction. A session may produce several quotes and no trade; an agreement may require recovery from a failed submission. This is an application state-machine sketch, not an ArcBlock transaction type:

DRAFT → PUBLISHED → NEGOTIATING → AGREED → AUTHORIZED
                                           ↓
                                       SUBMITTED → SETTLED
                                           ↓
                                      RECONCILING

Before signature: withdraw intent, reject quote, close session
After signature: cancellation depends on settlement nonce/cancellation rules
After submission: reconcile chain outcome before changing remaining quantity

Persistence lets a user replace an interface or restart an agent without losing the record of what was promised. Private negotiation is shared only with necessary participants. An old summary remaining in an index must never become authority to execute a withdrawn agreement.

Define messages before adding an agent

A minimal application message might include the fields below. This is a proposed market-protocol sketch, neither a chain transaction JSON nor a released ARC API.

{
  "version": "market-intent-example/1",
  "intentId": "local-unique-id",
  "publisherDid": "<publisher DID>",
  "contactEndpoint": "<authenticated messaging endpoint>",
  "give": [{"chain": "<chain ID>", "asset": "<asset ID>", "maxAmount": "<integer units>"}],
  "receive": [{"asset": "<asset ID>", "minAmount": "<integer units>"}],
  "validUntil": "<UTC timestamp>",
  "credentialPolicy": "<policy reference>"
}

An implementation must define canonical encoding, signature domains, authenticated messages, deduplication and withdrawal. An application-level validUntil does not automatically become an enforceable condition on every chain. Final authorization must bind the selected chain, assets, amounts, counterparty, fees and an enforceable expiry or cancellation mechanism. Publishing a general willingness to trade must not authorize anyone to spend the publisher's assets.

Discovery can begin with contacts, small directories or professional quote sources, then expand to independently replaceable indexers. Indexers need freshness, spam resistance and access controls. A replaceable specialist service is more understandable than a nominally P2P service with an indispensable single gateway.

Agents should receive verifiable quotes, not only chat messages. They can compare direct P2P, AMMs, market makers and solvers while considering privacy and waiting time. Deterministic code must check arithmetic, minimum receipts, recipients and signatures. A counterparty's prompt is message data, not authority to change the agent's rules.

Settlement adapters can support different chains without hiding their differences. ArcBlock native transactions serve supported asset combinations; Ethereum can use a generic settlement contract and signed agreements; Solana programs can organize atomic transfers. The settlement essay discusses those choices, not a promise of automatic cross-chain exchange.

Software boundaries also define operating roles

Deployable Blocklets can let a developer distribute software while users retain state and authorization. Those boundaries clarify control. They do not automatically exempt either the developer or the operator from legal responsibility.

Self-deployment is not a license category. In particular, automated negotiation, recommendations and handling orders for others cannot simply be placed under the US SEC staff statement for certain self-custodial interfaces. The legal essay examines the distinctions across jurisdictions.

Compliance requirements can become transaction policy. A seller can request a credential from an accepted issuer; the agent checks validity and revocation before continuing. DIDs and VCs may reduce repeated disclosure of full identity documents. Selective disclosure and zero-knowledge proofs require suitable credential formats and verification implementations. None of these guarantees clean funds or determines an operator's legal obligations.

Known-counterparty exchange, replaceable publishing and discovery, then bounded personal agents form a development sequence with independently testable outcomes. Pools, automated quoting and public markets can follow where demand, capital risk and operating responsibilities justify them. The result should give users authority they can understand, move and revoke, rather than merely an interface resembling an exchange.