You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
Learning path
Connect ArcBlock Chain to identity and applications
Separate account identity, transaction authority and the runtime hosting an application.
Read a documented transaction as an envelope plus an operation. Identify the account and authority involved, then explain which parts of the surrounding application belong in ARC rather than in the transaction.
Along this path
- How does ArcBlock Chain differ from ARC?
Separate shared on-chain records from application execution.
- ArcBlock accounts, wallets and DID
Separate signing tools, ledger records and identifiers.
- ArcBlock transactions: envelope and operation
Read the signed outer record and its typed inner operation.
- ArcBlock Multi IO: several inputs and outputs, one transaction
Compare a transfer format with a model of spendable outputs.
- ArcBlock delegation: permission without sharing a key
Understand operation-scoped delegation and revocation.
- Must a DID depend on a blockchain?
Identifiers and verifiable registries can combine without being synonyms.
- Which layer does OCAP unify?
Unified chain access does not merge chains.
- Bitcoin, Ethereum, Solana, Circle Arc, Base and ArcBlock
Compare state, execution and application responsibilities.
- ArcBridge: connecting ArcBlock and Ethereum
Understand the bridge without confusing it with an entire L2 chain.
- Ethereum and ArcBlock: applications and assets
Compare responsibilities, then examine the bridge between them.
Referenced here
Products
- ArcBlock Chain active
The application-focused Layer 1 for identity, assets and agreements. ArcBlock Chain brings these operations into the protocol, with ABT as the public network’s native token.