QALS Wiki · the qalarc networkgenerated 2026-09-06 · qalcode autonomous research

Sunset, Streams, anchoring options · 01_iota_deep_research/SHIMMER_AND_DATA_TRANSFER.md

Shimmer Network & IOTA's Data-Transfer Machinery — Deep Research

Date: 2026-09-06 · Author: research agent · Method: live webfetch verification (shimmer.network, blog.shimmer.network, blog.iota.org, docs.iota.org, github.com/iotaledger, CoinGecko API, LayerZero blog, Wikipedia). Items that could not be independently re-verified today are flagged [UNVERIFIED].

1. What Shimmer Was

Shimmer (SMR) was IOTA's incentivized staging network — a feeless Layer 1 running IOTA's experimental protocol upgrades in production before they shipped to the IOTA mainnet. Key facts:

Sources: shimmer.network · shimmer.network/faqs · blog.shimmer.network launch/EVM posts · CoinMarketCap SMR

2. Shimmer's 2025–2026 Endgame (VERIFIED — the critical part)

The Rebased pivot killed Shimmer's reason to exist

In late 2024 IOTA abandoned the incremental "IOTA 2.0 / Coordicide / Mana" roadmap that Shimmer was built to de-risk, and instead rebuilt IOTA as a Move-VM object ledger with delegated Proof-of-Stake and paid (burned) fees — "IOTA Rebased", a Sui-derived architecture (docs.iota.org is explicitly "adapted from the SUI Documentation"; CoinGecko now describes IOTA as a PoS chain with fees paid and burned).

Shimmer is being switched off — timeline

Official announcement 23 July 2026: blog.shimmer.network/shimmer-is-sunsetting — "Shimmer was built as a place to test, break, and prove new technology before it was ready for prime time. That job is done."

Date Event
29 Aug 2026 LayerZero external-liquidity bridge for ShimmerEVM shuts down — last day to bridge assets in/out (layerzero.network support update)
30 Sep 2026 Shimmer L1 + ShimmerEVM stop block production; explorer and website discontinued

What happens to SMR holders

3. The Tangle as a Data-Transfer Machine (history)

Original vision (2016–2021)

IOTA was designed for feeless value and data transfer between IoT/M2M devices. Data rode in zero-value transactions; the bundle/message model evolved through three eras:

  1. Legacy (Curl/ternary): raw data in transaction signatures-field; MAM v0 ("Masked Authenticated Messaging") linked messages into encrypted streams with forward secrecy — each message referenced the next message's address, so only key-holders could walk the stream (Wikipedia, JMIR paper).
  2. Chrysalis (2021): Indexation Payloads — data plus a lookup tag, retrievable by index; MAM+ became IOTA Streams (below).
  3. Stardust (2022, on Shimmer): structured outputs made data a first-class ledger concept: - Alias outputs with immutable metadata (TIP-18): a controllable object whose immutable metadata field can carry a permanent data blob / hash [spec text from training data — UNVERIFIED today]. - Tagged Data Payload (TIP-23, VERIFIED): block payload type 5 = length-prefixed Tag (uint8-delimited, max tag length per TIP-22) + length-prefixed Data (uint32). Spec explicitly says: "Tag is not considered by the protocol, it just serves as a marker for second-layer applications", and the tag exists to ease migration from legacy indexation (TIP-0023). Payloads were capped at ~32 KB (protocol constant), so this was for hashes, checkpoints, and small messages — never bulk data.

Data Marketplace pilots

Launched 28 Nov 2017 — sensor operators (33+ companies incl. a claimed Microsoft involvement, later walked back to "participant") offered data-for-sale metadata anchored to the Tangle; buyers paid IOTA directly device-to-device. A second phase ran through 2019–2020 with ~330 participants. Reception was skeptical (FT Alphaville called out the marketing). It proved hash-anchoring + feeless micropayment settlement, but no durable product survived. Sources: Reuters 2017, Wikipedia, Forbes [details UNVERIFIED today].

IOTA Streams (the real data-channel product — now DEAD)

Repo: github.com/iotaledger/streams — archived 15 Apr 2024, read-only, moved to iotaledger-archive. Replaced MAM+; alpha, never reached 1.0.

Architecture (from the README, verified today): - "A cryptographic framework for building secure messaging protocols"; shipped one built-in protocol, Channels, for authenticated multi-party messaging on the Tangle. - Crate layout: iota-streams-core (spongos — sponge-based authenticated encryption automaton, pre-shared keys, PRNG), iota-streams-core-keccak (Keccak-F[1600] sponge), iota-streams-core-edsig (Ed25519 signatures + X25519 key exchange), iota-streams-ddml (Data Definition & Manipulation Language for serializing protocol messages), iota-streams-app (common Application layer), iota-streams-app-channels (the Channels protocol), plus C bindings and a no_std build path. - API shape: Author::new(seed, encoding, PAYLOAD_BYTES, multi_branching, Client) / Subscriber; transport via app::transport::tangle::client::Client pointed at a Hornet REST port (:14265) — this transport+client seam was the Messaging Abstraction Layer (MAL) [MAL name from wiki — UNVERIFIED today]. - Channel message types: Announcement (channel start, author public key), Keyload (distributes session keys to subscribed public keys, marks access), Signed Packet (public payload + signature), Tagged Packet (encrypted payload keyed to the keyload), plus branch types (single/multi-branch) for multi-writer streams [message-type details from docs/training data — UNVERIFIED today].

Why it died: Rebased replaced the payload-centric ledger with an object model, making Streams' ledger-transport assumptions obsolete; Streams was alpha, Rust-only, and never hardened. Its responsibilities were absorbed by the IOTA Trust Framework (Identity + Notarization), where "channels" become ordinary Move objects and key-distribution becomes capability objects. Nothing called "Streams" exists on Rebased IOTA today.

4. Notarization on Rebased IOTA (2026) — what data anchoring looks like now

docs.iota.org/developer/iota-notarization (VERIFIED). Part of the IOTA Trust Framework alongside Identity 1.9 (SD-JWT, W3C DIDs) and Hierarchies. Two components:

Rust + Wasm SDKs exist, including a local-network setup for private chains (notable for our design section). Docs are adapted from Sui's, confirming the architecture class.

5. How Competing Chains Do Data Availability / Anchoring

(Comparison from training data — architecture-level claims verified against known designs; current parameter details [UNVERIFIED].)

Chain Model for data Unit cost model Best for Weakness for qalarc-style private use
IOTA (Rebased, 2026) Move objects; Notarization toolkit (hash or full data in object); Tagged Data equivalent = arbitrary object fields Refundable storage deposit + small burned gas Notarization, audit trails, identity-anchored data-sharing Small payloads; public ledger privacy requires hashes-only
Arweave Permanent replication of full data in blockweave, one-shot endowment fee Upfront per-byte perpetual-storage fee Truly permanent public archives Costs scale with size; data is public; no private channels
Celestia Pure data-availability layer: erasure-coded blobs, namespace-segregated; validity via data-availability sampling; no execution, no retrieval guarantee forever Pay per blob by size/time (fee market) Feeding rollups with DA guarantees No application semantics; pruning; needs another layer for logic
Polygon (Avail — now independent "Avail") Same DA-sampling family as Celestia, with KZG commitments + light clients Blob fees Rollup DA Same: no payload semantics, not permanent
Hedera (HBAR) Consensus service: signed, timestamped messages ordered by aBFT gossip (hashgraph); optional file chunks up to KBs Tiny fixed USD-pegged fee (~$0.0001/msg) Notarized event streams, filter topics — closest philosophically to old Streams/MAM Permissioned council governance; public data; per-message fees

Key lesson from the comparison: chains split into (a) permanent public archives (Arweave), (b) temporary availability for rollups (Celestia/Avail), and (c) ordered, timestamped notarization streams (Hedera consensus service, IOTA Notarization). For internal machine-to-machine data transfer, none of them is a transport network — the ledger is for ordering, integrity and receipts, not payload delivery.

6. Design Section — "QALNET" for qalarc

Requirements context: qalarc runs AI services, a Signal/WhatsApp hub (single-session, localhost HTTP API on :8769), and GPU rigs (minirig, superlocal, bb-mini) already meshed over Tailscale/WireGuard. Goal: transfer data between its apps/servers/agents — with integrity, access control, and optionally externally-verifiable receipts.

Honest baseline first

Bulk data must move over plain WireGuard/Tailscale (or HTTPS). Any ledger — IOTA included — is for envelopes, keys, receipts, and policy, not bytes. Streams' death is the evidence: putting encrypted payloads through ledger payloads (32 KB caps, PoW, full-node storage) doesn't scale and strands you when the platform pivots (as Shimmer holders learned the hard way in 2026 — build on platforms whose sunset story you can survive).

Options analysis

(a) Anchor data hashes on IOTA mainnet (use Notarization objects verbatim) - ✅ Zero infra to run; refundable deposits make it ~free; timestamps; Sui-grade Move object semantics; SDKs exist; legally-admissible audit trail story. - ❌ Public (hashes leak metadata via access patterns); needs internet + fees in IOTA tokens; a third party's roadmap risk (Shimmer sunsetting in 4 years is the cautionary tale); latency unsuitable for agent messaging.

(b) Fork the IOTA node as a private "QALNET" chain - Rebased is Sui-derived, so a private network with own genesis, own validators (the 3–4 machines qalarc owns), Move contracts, no token sale is a supported pattern (docs ship a local-network setup for Notarization development). - ✅ Full control: no fees to pay (mint your own gas), privacy, runs inside the Tailscale tailnet, keeps the Move object model + Notarization/Identity packages out-of-the-box; can still checkpoint QALNET state-roots to IOTA mainnet for external verifiability. - ❌ You operate consensus (3 validators = you; Byzantine guarantees are theoretical); upgrade treadmill (IOTA moved fast, deprecated things twice); small team maintenance burden; the "iota" brand of the node is now a generic Sui-family L1 — you're really just running a private Sui-like chain.

(c) Rebuild IOTA Streams-style encrypted channels as Move objects - Model: Channel object (creator holds AuthorCap), Announce event, Keyload → members get SubscriberCap capability objects, TaggedPacket objects carry (optionally AEAD-encrypted) small payloads or CIDs/hashes, sequence numbers enforced in Move, ACL via capabilities = Streams' keyload model, but now with composability (channels can be arguments to other contracts) and without spongos/ternary baggage — use X25519+ChaCha20-Poly1305 or AES-GCM client-side, Move stores envelopes only. - ✅ Direct spiritual successor of Streams; capabilities are a better keyload; audit trails come free via events. - ❌ You write and audit the Move package yourself; needs (b) underneath to be private.

Recommendation: (b) + (c), with (a) as the notarization bridge

Run a private QALNET chain (IOTA Rebased/Sui-family node, 3 validators: superlocal + qalcachyminirig + bb-mini, all over Tailscale), and on it deploy a Streams-successor "QAL Channels" Move package. Use IOTA mainnet (or Hedera) only as an optional external receipt anchor.

                         ┌────────────────────────────────────────────┐
                         │                QALARCTAILNET               │
                         │              (Tailscale/WireGuard)         │
   big payloads ───────► │  apps/agents/GPU rigs  ◄── direct WG ──►   │
   (model I/O, media,    │                                            │
    backups, CSVs)       │  ┌──────────────────────────────────────┐  │
                         │  │  QALNET (private Rebased/Sui chain)  │  │
                         │  │  validators: superlocal, minirig,    │  │
                         │  │  bb-mini                             │  │
                         │  │  ┌────────────────────────────────┐  │  │
                         │  │  │ qal_channels.move              │  │  │
                         │  │  │  Channel / AuthorCap /         │  │  │
                         │  │  │  SubscriberCap (= keyload)     │  │  │
                         │  │  │  TaggedPacket (≤ a few KB,     │  │  │
                         │  │  │  AEAD-encrypted or CID+hash)   │  │  │
                         │  │  │  seq#, versioned, events       │  │  │
                         │  │  ├────────────────────────────────┤  │  │
                         │  │  │ notarization pkg: Locked/      │  │  │
                         │  │  │ Dynamic receipts + AuditTrail  │  │  │
                         │  │  │ (RBAC) per app                 │  │  │
                         │  │  ├────────────────────────────────┤  │  │
                         │  │  │ qal_identity: DIDs for agents, │  │  │
                         │  │  │ hub, rigs (cap-gated)          │  │  │
                         │  │  └────────────────────────────────┘  │  │
                         │  └──────────────┬───────────────────────┘  │
                         │                 │ periodic checkpoint      │
                         │                 │ (Merkle root of channel  │
                         │                 │ heads) every N minutes   │
                         └─────────────────┼──────────────────────────┘
                                           ▼
                            IOTA mainnet Notarization object
                            (public, timestamped, refundable deposit)

Component roles: 1. QAL Channels (Move pkg) — the transport control plane: who may publish/subscribe (capabilities = Streams keyloads), sequence integrity, small command/config messages inline, big data as CID+hash. 2. Data plane — payload bytes over Tailscale directly (S3-style object store on minirig, or plain HTTP between agents); the channel entry is the pointer, satisfying "who sent what when, provable". 3. QAL Notarization receipts — per-workflow Audit Trail objects (AI job provenance: prompt-hash, model, GPU-node DID, output-hash). Verifiable years later even after hardware churn. 4. External anchor — optional daily/periodic Merkle root of all channel heads → one IOTA mainnet Locked Notarization object. Public proof of "this internal log existed and was untouched", at negligible cost, without exposing internal data. 5. Fallback — if QALNET consensus ops become a burden, degrade gracefully: keep the Move packages, move them to a single-node private network (still verifiable, weaker trust) or to IOTA mainnet directly (option a).

What NOT to do: don't anchor bulk data on Arweave (cost × publicity), don't build on Celestia/Avail (no semantics, ephemeral), and don't marry your transport to someone else's staging network — Shimmer's 2026 shutdown shows the staging network itself is the first thing cut when strategy pivots.

Source index

← State of IOTA 2026DeFi Research Base →