How a trade happens: from a personal offer to atomic exchange
A personal market could change where a trade begins. Your own space holds the intention. Your software keeps looking. Your agent negotiates. Only after the parties agree does the chain verify and perform the asset exchange it can enforce.
Follow Alice through one proposed trade. This is an experience to build, not instructions for an existing product. ArcBlock’s Exchange protocol is an existing foundation; connecting personal state, discovery, quotes, agents, wallets and settlement into this workflow still requires implementation and validation.
Alice closes her phone. Her intention remains discoverable.
Alice wants to exchange fungible token A for token B. Fungible means units of the same token are interchangeable and measured by quantity. In her market Blocklet, she specifies an amount, acceptable assets, fee limits, how long she can wait and which decisions require fresh confirmation. She may restrict visibility to a community.
Her ArcSpace stores those rules and records. Applications running on ARC maintain a reachable endpoint, publish a limited summary and receive messages. Her phone can be off while that summary still tells others that someone is willing to discuss this exchange. Think of a stall that remains staffed without handing the attendant unrestricted access to the cash box.
Keeping the service online does not grant it indefinite spending authority. Alice need not publish her reservation price, full balance or private preferences. Summaries need versions and expiry. Withdrawal must stop new quotes and propagate to indexes. ArcSpace is not a magical uptime guarantee: deployment, backup and recovery still matter. A stale index entry is a lead, not evidence that a trade remains executable.
Bob’s agent finds Alice through a replaceable index, Carol through a community directory, and a market maker may respond directly. They still need to authenticate messages, identify the asset’s chain, agree on trading rules and inspect any required credentials. A DID can bind an endpoint to a signing identity. It does not prove solvency or honesty.
An agent can compare markets. A reference price is not a firm quote.
Alice’s agent can inspect AMMs, ask OTC desks and market makers for quotes, and observe centralized-exchange data through permitted APIs. It runs off-chain and can access the network itself. It does not need to publish each observation through an on-chain oracle just to help Alice decide.
Fetching information, making a personal decision and enforcing an agreed transaction are different jobs. The first two can remain in Alice’s software. If settlement itself depends on an external fact, such as an index value at delivery, that fact needs an oracle or another explicitly trusted proof mechanism. Keeping price research off-chain reduces that dependency for the settlement rule. It does not eliminate stale, manipulated or fraudulent information.
The agent therefore cannot treat a number displayed by a CEX as Bob’s commitment to deliver. Account eligibility, available balances, depth, withdrawal restrictions and fees can change what is achievable. Reading CEX data does not authorize trading there. If Alice separately authorizes CEX execution, that route has its own custody and delivery risks; a normal same-chain Exchange transaction cannot make it atomic.
Bob offers one arrangement, Carol proposes a different size, and a market maker offers a shorter wait. Alice’s agent compares net amounts, costs, timing, credentials and privacy conditions under her rules, then negotiates. It can suggest splitting the order, but several independent swaps are not automatically one atomic transaction. It can also decide to wait.
Once terms are agreed, neither party has to send first
Suppose Alice and Bob agree on assets on the same ArcBlock chain. The application turns the agreement into an exact transaction: assets, quantities, recipients, fees and authorization conditions. A public intention is not that transaction, and a chat transcript cannot substitute for it.
The existing ExchangeV2 protocol represents a package of assets from each side. Alice’s wallet checks and authorizes the transaction; Bob’s wallet authorizes the same contents. The application submits the signatures. The chain validates the transaction under its protocol and changes both sides’ asset state together if the conditions hold. Users must still wait for the relevant confirmation and finality requirements. An agent saying “agreed” is not settlement.
If Bob spends the asset first, or another validation condition fails, the proposed exchange cannot complete as agreed. Alice does not first transfer her side unconditionally and hope Bob reciprocates. Failure may still cost time or fees, but the application must not silently replace atomic exchange with two separate payments. Expiry, cancellation and concurrent spending need real settlement semantics, not a countdown drawn on a screen. The technical appendix explains the current boundaries.
Atomicity covers the state changes that one transaction and settlement system can enforce. Assets on different chains require an additional cross-chain protocol and threat model. A bank transfer, house or future service cannot be proven delivered merely because both parties signed.
What changes for NFTs, credentials and business rights?
Fungible tokens are just the easiest starting point. Each candidate below must identify what the chain changes and who delivers everything else.
| Proposed use | How exchange could be organized | What remains to establish |
|---|---|---|
| Native ABT or another FT exchanged for a token | Negotiate quantities and authorize supported asset packages on one chain | Chain, precision, balance, fees and token restrictions; identically named assets on different chains are not interchangeable |
| NFT for tokens, or NFT for NFT | Quotes identify specific assets; the chain checks transferable ownership | Authenticity, issuer and licensing terms; NFT transfer does not automatically transfer copyright |
| Software licenses, compute credits or other digital service rights | Check issuer and transfer terms; a supported system could update an on-chain right together with payment | The service must recognize the new holder and prevent old credentials from being redeemed; without that integration, service delivery is not atomic |
| VC-based eligibility | Verify credentials from accepted issuers while limiting disclosure | Holder binding, validity, revocation and legal requirements; identity and KYC credentials are generally not goods to sell |
| Credentials describing physical property or off-chain rights | Agents discover offers, inspect conditions and negotiate | Actual title, registration, custody and dispute resolution still require external mechanisms |
A verifiable credential lets a counterparty check who made a statement, whom it concerns and whether it remains valid. It does not make everything freely transferable. The W3C VC data model supplies a representation and verification framework. Business rules determine whether rights may transfer and who must reissue or recognize a credential afterward.
Why not put all of this in an Ethereum contract? A contract alone cannot privately watch markets for an individual, fetch arbitrary websites, retain private preferences and chat with other agents. Ethereum’s deterministic execution model needs special mechanisms to bring external facts into contracts; its oracle documentation explains why. ArcBlock’s chain should not take over those personal tasks either.
This is a limit of the contract alone, not a claim that the Ethereum ecosystem cannot build personal markets. Ethereum applications can attach off-chain agents, storage and communication, then use contracts for settlement. 0x and modern intent architectures already separate these responsibilities. Uniswap’s pools solve a different and valuable problem: pooled inventory and pricing rules let a trader execute without first finding an individual willing to take the other side. An ordinary pool swap does not require the bilateral negotiation imagined here.
ArcBlock offers a particular composition: native Exchange, DID, ArcSpace, ARC and Blocklets. Identity, persistent personal state and application operation become part of the design rather than responsibilities assigned to an exchange contract. That may reduce the work needed to assemble a personal market, but implementation must establish whether it actually does and at what cost. The same personal market layer could also select Ethereum or Solana for settlement.
Alice should experience something straightforward: her intention stays in her space, her software brings back options, her rules filter them and her wallet authorizes the result. The chain guarantees what it can enforce. Responsibilities for everything else remain visible. That is the experience this scenario asks builders to create.