Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Expert · Lesson 17 of 21

Arc, Base and cross-chain dependencies

Name the settlement rules behind the interface.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 17 of 21
  1. Threat model before tools
  2. Design a custody architecture
  3. Entropy, mnemonics and passphrase tradeoffs
  4. Hardware signing and trusted displays
  5. Multisig and independent control
  6. Recovery and continuity across people
  7. Coin control and privacy tradeoffs
  8. Lightning operations and recovery
  9. Payment operations and reconciliation
  10. Native bitcoin and wrapped claims
  11. USDC, reserves and redemption
  12. Identify a Morpho market precisely
  13. Oracles, prices and measurement risk
  14. LTV, liquidation and nonlinear losses
  15. Variable rates and growing debt
  16. Vaults, allocation and exit liquidity
  17. Arc, Base and cross-chain dependencies
  18. Allowances, signing and simulation
  19. Treasury accounting and restricted funds
  20. Incident response with clear human authority
  21. Capstone: a defensible treasury design

What you will learn

  • Explain why EVM compatibility does not imply Bitcoin security.
  • Map a cross-chain workflow into distinct finality and exit steps.

Compatible software can sit on different foundations

EVM compatibility helps applications use familiar contract tooling, but it does not define a chain’s consensus, validator access or withdrawal process. Arc’s documentation describes a permissioned validator set using Malachite, a Tendermint BFT implementation. Base documentation describes deriving its L2 chain from data published to its L1. Neither should be presented as Bitcoin proof-of-work settlement.

A bridge adds a separate transition

A cross-chain action can involve custody, locking, burning, minting, proofs or external messages depending on the design. The exact bridge and asset determine the assumptions. Submission on the starting chain is not automatically usable value at the destination. Identify each state and the evidence that advances the workflow; a single spinner conceals too much for an accountable financial interface.

Evaluate the whole exit route

In a fictional architecture review, list the source chain, destination chain, asset contracts, bridge mechanism, administrative powers, fees and expected waiting conditions. Then remove the usual front end and ask what the authorized human can still verify or recover. A decentralization goal should be expressed as dependencies to reduce, not a claim that a particular deployment has no third parties. This course does not certify a bridge or imply that Arc and Base inherit Bitcoin’s consensus guarantees.

Practice on paper

A product runs the same Solidity interface on two chains. Which conclusions cannot be inferred from that fact alone?

Reveal the worked answer

You cannot infer identical consensus, validator openness, finality assumptions, gas behavior, bridge safety or exit availability. Inspect each chain and deployment with its current official specification.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does EVM compatibility mean Bitcoin proof of work?

  • Yes
  • No
Reveal answer 1

No. Execution compatibility and consensus are different properties.

2. Is a source-chain transaction alone proof of destination availability?

  • Yes
  • No
Reveal answer 2

No. The complete transition must be verified.

Take this with you

Describe every trust boundary in a cross-chain flow.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.