One agreement, different settlement chains
Atomic exchange is not exclusive to ArcBlock, and a personal market need not settle on an ArcBlock chain. Ethereum is already very good at trustless settlement. Solana offers a different programming and execution environment for the same broad goal.
The relevant boundary is a transaction's execution domain. Two compatible assets on one chain are a much simpler case than unrelated assets on different chains or money moving through a bank.
Ethereum: authorize an agreement, then verify it
A generic settlement contract can check both parties' authorization and transfer the specified assets in one transaction. A signed intent should bind the chain, verifying contract, assets, amounts, recipient, expiry and replay protection appropriate to the design.
EIP-712 provides typed structured signing, but does not itself supply replay protection. EIP-2612 permits signature-based allowance changes for compatible tokens; it is not universal token support or a guarantee that an order remains funded. Contract-wallet signatures require their own verification path, commonly EIP-1271. EIP-712, EIP-2612, EIP-1271
The contract can pull approved assets during execution, or a design can use escrow. The former avoids advance deposit but may fail when balances or allowances change. The latter creates a stronger availability commitment while locking capital and introducing escrow-contract exposure.
Production code must handle nonstandard token behavior, reentrancy, fee-on-transfer assets, authorization scope, cancellation and partial fills. A short transfer example is not a secure settlement implementation. Existing audited components deserve consideration before custom code.
Solana: programs and account authority
A Solana transaction can contain multiple instructions whose state changes succeed or fail atomically; transaction fees are a separate consideration. A settlement program can verify the agreement and invoke token programs to move assets. PDA authority can support escrow arrangements, while account ownership and signer checks define who may do what. Transactions, CPI, PDAs
That flexibility brings Solana-specific work: account validation, writable-account contention, compute limits, token-program differences and replay state. An Ethereum design should not be mechanically renamed and called a Solana implementation.
What changes when exchange is native?
| Design | Where exchange semantics live | Main trade-off |
|---|---|---|
| ArcBlock transaction primitive | Chain transaction handler | Shared rules; extensions may need protocol changes |
| Ethereum contract | Application contract plus token interfaces | Flexible logic; contract and approval complexity |
| Solana program | Program, accounts and invoked token programs | Composable instructions; account and authority discipline |
These are architectural comparisons, not performance benchmarks. Liquidity, security practice and tooling matter as much as expressive power.
Cross-chain settlement needs an additional mechanism such as locks, bridges or intermediated liquidity, with different timing and trust assumptions. Fiat and real-world assets require external evidence and enforcement. Neither should inherit the simple claim that everything happens together merely because one leg uses a blockchain.