# Boreal cross-chain interoperability v0.1

Requested 8 November 2026: make Boreal interoperable with Ethereum, Solana and
Bitcoin. Status: architecture and local accounting research only. No contracts,
tokens, keys, RPC integrations or real-fund bridge have been deployed.

## Asset identity and routes

BOREAL is the proposed native asset of the future Boreal chain. Ethereum and
Solana representations must be claims on escrowed native units, not independent
issuance or a second premine. Name/ticker clearance is still pending.

| Route | Proposed representation | Current implementation status |
| --- | --- | --- |
| Boreal to Ethereum and back | Escrow-backed ERC-20 representation with restricted mint authority and verified burn/redemption | Local accounting model tested; no deployed contract |
| Boreal to Solana and back | Escrow-backed SPL-compatible mint with controlled mint authority and verified burn/redemption | Local accounting model tested; no deployed program/mint |
| Bitcoin to Boreal and back | Separately backed BTC representation, confirmed by Justin, with explicit Bitcoin custody/proof and redemption rules | Required route; custody/proof model unresolved; no integration |
| BOREAL representation inside Bitcoin | Outside the current requested Bitcoin scope | Not selected |

Bitcoin scope is confirmed: BTC moves into and out of Boreal, with 1:1 BTC
redemption as the design objective. It is not a BTC-to-BOREAL exchange or BOREAL
issuance on Bitcoin. No Bitcoin custodian, federation or cryptographic bridge
has been selected. Do not market a Bitcoin
route as trustless, native or available before a concrete design proves that.

## Proposed canonical units

Use the native BOREAL atom (10^-8 BOREAL) as the exact accounting unit. An
Ethereum/Solana representation can expose 8 decimals; preserve integer amounts
without rounding, floating point, decimal truncation or implicit 18-decimal
conversion. BTC satoshis, if supported, remain a different asset and backing pool.
Never use BOREAL collateral to imply 1:1 BTC backing or vice versa.

Native issuance and the current proposed cap do not change because wrapping is
added. Bridging is an asset movement/accounting operation, not a block subsidy.
Cross-chain fees, destination gas and minimum transfer amounts need explicit
specifications; they must not silently create liabilities or alter fee burning.

## Global backing invariant

For one canonical asset across every destination:

```
external_wrapped_supply
  + reserved_pending_mints
  + reserved_pending_native_releases
  <= canonical_native_escrow
```

Count all supported destination chains in the same invariant. Lock 100 native
atoms: reserve 100 for a specific destination. Mint 100 there: consume that
reservation, increase wrapped supply by 100 and retain 100 escrowed atoms.
Burn 40 wrapped atoms: reduce wrapped supply to 60, reserve 40 for native
release, then release exactly 40 and leave 60 in escrow. The same source deposit
must never back both an Ethereum mint and a Solana mint.

Escrowed native units and the representations they back are not added together
as additional economic supply. Representations moving directly between external
chains must burn/reserve/mint through the same global liabilities accounting;
do not build arbitrary chain-to-chain minting into the first prototype.

## Message and replay domains

A versioned message must bind bridge/network identity, source/destination chain,
source genesis/domain identifier, asset and backing pool, transaction ID and
event/output index, amount in canonical units, recipient, unique nonce and
operation (lock/mint/burn/release). Production encodings and address validators
are not specified by a JSON simulator.

Retain globally consumed source-event IDs and distinct destination operation
IDs. Reject duplicates, destination substitution, wrong asset/domain/version,
negative/boolean/float/overflow amounts, unsupported routes, replays after
restart and double redemption. A bridge-wide source-deposit identity must not
be bypassed by changing the destination network or message envelope.

## Finality, proofs and trust

Wait for the route's explicit finality policy before minting or releasing. An
RPC response or simulator boolean is not a cryptographic proof. Policies must
handle differing source-chain finality and Bitcoin reorganization risk, stale
proofs, light-client bootstrap/update rules and unavailable peers.

Compare light-client/proof verification, optimistic/fraud-proof designs and
externally attested/custodial designs with their actual assumptions and costs.
A signer committee or multisig may add custody/collusion risk; threshold
signatures do not turn that design into a trustless bridge. No approach is
selected or certified secure in this document.

Before mint: an invalidated deposit must not create a wrapped liability. After
mint: a backing-loss/reorg event requires a halt and explicit insolvency/incident
handling; it cannot be repaired by silently erasing users' wrapped balances or
pretending finality cannot fail. Do not release escrow to maintain activity when
proofs, accounting or signing assumptions fail.

ML-DSA authorization on Boreal does not make Ethereum, Solana, Bitcoin or a
bridge verifier post-quantum secure. Cross-chain signing/verification compatibility
and its gas/compute costs are separate design questions. No native ML-DSA
verification support is assumed on destination chains.

## Dependencies and gates

The existing local ledger lacks asset identifiers/multi-asset accounting, bridge
escrow scripts, multi-party bridge authorization, production finality and peer
consensus. A BTC representation requires a separate asset identity and ledger
rules; do not treat a signed BOREAL transfer as a BTC deposit. A simulator cannot add
these features to the live chain. Keep protected consensus and live state intact.

1. Local bridge accounting/state-machine model and adversarial tests, clearly
   treating finality/custody observations as simulated external inputs.
2. Explicit escrow/unlock and proof/authority specification; independent vectors,
   persistence/replay and reorg/insolvency handling.
3. Local EVM and Solana adapter tests against maintained token standards; no
   deployment, account creation, gas spend or live minting implied.
4. Implement and review the confirmed BTC-in/BTC-out route separately: deposit
   script/custody, confirmation/reorg handling, BTC-specific backing pool, an
   identified BTC asset on Boreal and Bitcoin redemption transaction validation.
5. Independent review of accounting, contracts/programs, keys, upgrades, pause
   controls, rate limits, watcher diversity and incident recovery.
6. Separately authorized valueless testnet deployments with published addresses,
   source/build hashes and clear risks. Real-asset launch is a later decision.

Bridge availability and liquidity are different deliverables. Do not promise
DEX listings, redemption liquidity, exchange support, popularity or asset value.

## Acceptance tests for the first local model

- Aggregate backing across Ethereum and Solana; same deposit cannot mint twice.
- Lock, reserve, mint, burn, reserve release and release preserve solvency.
- Reject burn/release without a corresponding liability and prevent double release.
- Route/recipient/asset/domain substitutions, invalid amounts and capacity limits
  fail without partial mutation.
- Unfinalized/invalidation observations reject or halt as explicitly specified.
- Export/reload preserves consumed event IDs and reservations; duplicate events
  after restart remain duplicates.
- Unsupported Bitcoin operations fail closed until that adapter/trust model exists.

## Primary references checked 8 November 2026

- Ethereum bridges/trust and asset-transfer patterns: https://ethereum.org/developers/docs/bridges/
- ERC-20 interface: https://eips.ethereum.org/EIPS/eip-20
- Solana mint authority: https://solana.com/docs/tokens/basics/mint-tokens
- Solana token burning: https://solana.com/docs/tokens/basics/burn-tokens
- Bitcoin confirmation/reorg considerations: https://developer.bitcoin.org/devguide/payment_processing.html