<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Sagitta Systems — Newsroom — Continuity Desk</title>
    <link>https://www.sagitta.systems/newsroom</link>
    <description>Network-wide records: releases, documents, statements, and system updates.</description>
    <language>en</language>
    <atom:link href="https://www.sagitta.systems/newsroom/continuity-desk/feed.xml" rel="self" type="application/rss+xml" />
    <lastBuildDate>Tue, 28 Jul 2026 00:00:00 GMT</lastBuildDate>
    <image>
      <url>https://www.sagitta.systems/sagitta.png</url>
      <title>Sagitta Systems — Newsroom — Continuity Desk</title>
      <link>https://www.sagitta.systems/newsroom</link>
    </image>
    <item>
      <title>Sagitta Radar launched</title>
      <link>https://www.sagitta.systems/newsroom/sagitta-radar-launched</link>
      <guid isPermaLink="true">https://www.sagitta.systems/newsroom/sagitta-radar-launched</guid>
      <pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
      <description>Sagitta Radar launched on 28 July 2026, monitoring oracle freshness, bridge settlement, and liquidity-pool depth for the protocols that depend on them.

Sagitta Radar launched on 28 July 2026. It watches three pillars of external dependency — oracle price freshness and deviation, bridge route settlement and pauses, and liquidity-pool depth and imbalance — and delivers signals as alerts and as structured daily briefings.

The three pillars are not an arbitrary selection. They are the dependencies a protocol does not own and cannot fix. A team can audit its own contracts, rehearse its own incident response, and rewrite its own governance; it cannot make an oracle publish a fresh price, cannot make a bridge settle, and cannot conjure depth into a pool that has thinned. Those are the failure paths that arrive from outside, on someone else&apos;s schedule, and they are the ones a protocol is least likely to be watching at the moment they matter.

Radar runs on the Sagitta Continuity Engine backend, which is what connects an infrastructure signal to continuity doctrine rather than leaving it as an isolated alert. The distinction is the product&apos;s reason for existing. An alert that a bridge has paused is information. The same alert, read against a doctrine that already names what a paused settlement route means for this protocol and what it should do next, is a decision — and the gap between those two is usually where the damage happens.

Delivery is to Discord, Telegram, and webhooks, which is a deliberate choice to meet operators where incidents are actually handled rather than requiring anyone to be watching a dashboard at the time.

Subscription plans and current pricing are published on the product page and are deliberately not restated here: they move, and a figure republished on an evergreen record is a figure that will eventually be wrong.</description>
      <category>System Update</category>
      <category>Continuity Desk</category>
      <dc:creator>Sagitta Systems</dc:creator>
    </item>
    <item>
      <title>Sagitta Protocol launched on Arc Testnet</title>
      <link>https://www.sagitta.systems/newsroom/sagitta-protocol-launched-on-arc-testnet</link>
      <guid isPermaLink="true">https://www.sagitta.systems/newsroom/sagitta-protocol-launched-on-arc-testnet</guid>
      <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
      <description>Sagitta Protocol launched on Arc Testnet on 11 May 2026 — a second testnet deployment, alongside Moonbase Alpha Testnet.

Sagitta Protocol launched on Arc Testnet on 11 May 2026. It is a separate milestone from the Moonbase Alpha Testnet launch of 13 April 2026, not a continuation of it.

The distinction is kept deliberately, and it is worth stating why rather than leaving it as a formality. Two testnet deployments on two networks are two pieces of evidence about two environments. Merging them into a single narrative would imply a portability claim — that what runs in one place runs in the other — which neither deployment establishes and which nothing in the record supports. Each launch evidences itself.

This record therefore states the launch and stops. No claim is made about which components are exercised on Arc, what assets its deposit path accepts, or how it relates to the Polkadot-native deposit route recorded on the Moonbase Alpha Testnet deployment, because none of that was verified. Where a fact was not read from a source, the record is silent rather than reasoning by analogy from the other deployment.

Both deployments are testnets. No mainnet deployment or contract addresses are published, and the protocol&apos;s operating state remains Public Test.</description>
      <category>System Update</category>
      <category>Continuity Desk</category>
      <dc:creator>Sagitta Systems</dc:creator>
    </item>
    <item>
      <title>Sagitta Systems hub published</title>
      <link>https://www.sagitta.systems/newsroom/sagitta-systems-hub-published</link>
      <guid isPermaLink="true">https://www.sagitta.systems/newsroom/sagitta-systems-hub-published</guid>
      <pubDate>Mon, 04 May 2026 00:00:00 GMT</pubDate>
      <description>sagitta.systems went online as the public directory and routing layer for the network.

sagitta.systems went online as the public record of the network: a directory of the operating systems, a newsroom, press and journalist resources, a careers and contributor centre, and a public roadmap.

The hub exists because the network had a structural problem that no individual product surface could solve. Sagitta&apos;s systems run on their own subdomains, each with its own audience and its own reason to exist, and a reader arriving at any one of them had no way to see how it related to the others — or to establish who was behind it, what state it was actually in, or whether the claims on it could be checked.

So the hub does four things the product surfaces deliberately do not. It explains: each system has a record stating what it is, who it is for, and what is usable today. It connects: the three families — continuity and defense, allocation and agent intelligence, capital infrastructure — are published as a structure rather than left to be inferred from a list of names. It documents: the whitepaper, the architecture, the allocation methodology, and the machine-readable surfaces are indexed in one place. And it routes: every record ends by handing the reader to the surface that can actually serve them.

The operating principle is that every claim carries the evidence behind it. Operating states are recorded with the date they were checked and the surface they were checked against. Figures carry their metric, scope, and source. Where something is not known — a date a source never published, a page count nobody read — the field is left empty rather than filled by inference, and the record says so.

Operating products continue to run on their own subdomains. This hub is the layer that explains, connects, documents, and routes across them, and it is the canonical location for the network&apos;s own record of itself.</description>
      <category>System Update</category>
      <category>Continuity Desk</category>
      <dc:creator>Sagitta Systems</dc:creator>
    </item>
    <item>
      <title>Sagitta Protocol Overview | Trustless Wealth Management Infrastructure</title>
      <link>https://www.sagitta.systems/newsroom/sagitta-protocol-overview</link>
      <guid isPermaLink="true">https://www.sagitta.systems/newsroom/sagitta-protocol-overview</guid>
      <pubDate>Sat, 18 Apr 2026 00:00:00 GMT</pubDate>
      <description>A video overview of the Sagitta Protocol architecture — the Vault, Treasury, Reserve, and Escrow, and the doctrine behind treating capital protection as a system requirement rather than an operator promise.

A video overview of the Sagitta Protocol architecture, published on the Sagitta Labs YouTube channel.

The protocol&apos;s subject is trustless wealth management infrastructure: holding, allocating, and recovering capital under rules that are enforced by the system rather than promised by an operator. Its components divide the work. The Vault handles custody and accounting. The Treasury manages liquidity and settlement. The Reserve is a gold-backed insurance layer. Escrow is the interface to external allocation venues, so capital leaving for a third-party venue crosses a boundary that was designed rather than improvised.

Two intelligence systems are embedded as components rather than integrations. The Autonomous Allocation Agent decides where capital goes, inside a policy agreed in advance. The Sagitta Continuity Engine governs what happens when something fails — which is the half of the design most protocols leave to incident response.

The organising claim is that fiduciary responsibility should be enforced through architecture instead of operator discretion, and that capital safety ranks above yield optimisation where the two conflict. That ordering is the whole argument: a system that will take a smaller return in exchange for surviving a bad month is making a different promise from one that will not, and the promise is only credible if the architecture is what enforces it.

This is not a deployment announcement. Sagitta Protocol remains in Public Test on Moonbase Alpha Testnet and Arc Testnet, and no mainnet deployment or contract addresses are published.

This record describes the protocol from its own system record and the whitepaper, not from the video&apos;s narration, which was not transcribed. No runtime is recorded, because none was published by the source.</description>
      <category>Video</category>
      <category>Continuity Desk</category>
      <dc:creator>Sagitta Labs</dc:creator>
      <enclosure url="https://www.sagitta.systems/watch/protocol-overview.jpg" type="image/jpeg" length="0" />
    </item>
    <item>
      <title>Sagitta Protocol launched on Moonbase Alpha Testnet</title>
      <link>https://www.sagitta.systems/newsroom/sagitta-protocol-launched-on-moonbase-alpha-testnet</link>
      <guid isPermaLink="true">https://www.sagitta.systems/newsroom/sagitta-protocol-launched-on-moonbase-alpha-testnet</guid>
      <pubDate>Mon, 13 Apr 2026 00:00:00 GMT</pubDate>
      <description>Sagitta Protocol launched on Moonbase Alpha Testnet on 13 April 2026, with Polkadot-native deposits crossing into Moonbeam as xcDOT and accepted directly by the Vault.

Sagitta Protocol launched on Moonbase Alpha Testnet — the Moonbeam testnet — on 13 April 2026. The interface reports v0.1 active there.

Deposits on this deployment are Polkadot-native: DOT crosses into Moonbeam as xcDOT via XCM and is accepted directly by the Vault. That last clause is the substance of the milestone. Accepting a cross-consensus asset directly, rather than requiring a holder to bridge and wrap it into something the Vault already understood, means the custody and accounting layer treats an asset that arrived over XCM as a first-class deposit — with the same ownership record and the same accounting treatment as any other.

What this deployment demonstrates is therefore narrow and specific: that the Vault&apos;s deposit path works against a real cross-chain asset on a live network, with real transaction semantics rather than a local simulation. It does not demonstrate allocation performance, continuity behaviour under stress, or economic assumptions, none of which a testnet can evidence.

This is a testnet deployment. No mainnet deployment or contract addresses are published, and the protocol&apos;s operating state remains Public Test.

It is also one of two separate Protocol milestones. The Arc Testnet launch of 11 May 2026 is recorded on its own and the two are deliberately never merged into a single launch narrative.</description>
      <category>System Update</category>
      <category>Continuity Desk</category>
      <dc:creator>Sagitta Systems</dc:creator>
    </item>
  </channel>
</rss>
