News

Sierpe 1.11.0 — events hand over their original bytes

The first external consumer to build on a Sierpe instance was not a dashboard — it was another pipeline: an escrow platform bridging a year of indexed mainnet history into its own event queue. A bridge like that does not want our decode of an event; it wants the event, the original ContractEvent bytes, to carry through its own envelope untouched.

Sierpe 1.10.1 — two ways a gap could be recorded wrong

Sparse healing shipped yesterday. Answering an operator’s question about it — can I apply a plan before my next batch of registrations clamps? — turned up two bugs in how a gap gets recorded. The answer was no, and now it is yes.

Sierpe 1.10.0 — healing only where your contracts actually lived

The mainnet pilot finished walking the RPC window and started on what lies below it: six million ledgers with no live source, healed by replaying them through a captive stellar-core. The first measurements made the problem plain. Replay runs at 4.72 ledgers per second on that machine, which puts the remaining range at about two weeks — to recover data that lives in 0.15% of those ledgers. The rest was empty history being replayed at full price.

Sierpe 1.8.0 and 1.9.0 — the archive leg learns what deep healing actually costs

The mainnet pilot moved from backfilling the RPC window into the archive leg’s territory: healing the six million ledgers below it. That transition surfaced three problems in three days — two shipped in 1.8.0 while the window walk was still running, and the third, found the hour the deep heal started, is 1.9.0.

Sierpe 1.7.0 — one scan for many contracts, and a bandwidth bug the pilot caught

Two releases in one day, because deploying against mainnet for real is the fastest reviewer there is. 1.6.0 shipped this morning; by the afternoon the first production pilot — three contracts walking eleven months of history on a homelab machine — had exposed a cost model problem and a silent bandwidth bug. 1.7.0 fixes both.

Sierpe 1.6.0 — the raw event on every movement, and registering the archived

Two changes, both forced by the same real-world job: collecting eleven months of mainnet history for a production escrow protocol (the case described in the upcoming use-case post).

Sierpe 1.5.2 — where it runs, and two fixes that widen the answer

We set out to answer one question: if you hand the site to someone who needs an indexer, where can they actually put it? The result is a new page, Where it runs, covering app platforms, the three hyperscalers, serverless (no), self-hosted from Kubernetes to a Raspberry Pi, and twenty-five Postgres providers — each with a verdict and the one setting that matters.

Sierpe 1.5.1 — a stalled backfill and a wolf-crying warning

Found by watching a real backfill on a real deployment, minutes after 1.5.0 shipped: the walk stopped 570 ledgers short of the data its operator was waiting for, retrying the same request every 40 seconds, logging unexpected end of JSON input forever.

Sierpe 1.5.0 — movements, and coverage that names its kind

This release started as a user question: “I sent 100 USDC and 69 XLM to my escrow and they do not show up — and I do not want to register Circle’s USDC contract just to see my own deposits.”

He was right to expect them and right to refuse the workaround. A payment to a contract is emitted by the asset’s SAC, so transfers — which attributes rows to the emitter — can never answer “what came into my contract”. That is a different question, and 1.5.0 adds the resource that answers it.

Sierpe 1.4.1 and 1.4.2 — fixes from the first real deployment

The first Basic-Auth deployment on a public domain found two bugs within an hour of going live. Both are the kind no test suite catches, because both live in the seams between the app and the world around it.

Sierpe 1.4.0 — Basic Auth for public deployments

Sierpe’s default deployment shape is private networking: no public domain, your backend reaching the instance over your platform’s internal network. That is the RabbitMQ rule of thumb — management surfaces do not face the internet — and it stays the recommendation.

Sierpe 1.3.0 — the appliance grows a face

An appliance you can only talk to with curl is only half an appliance. 1.3.0 adds a management interface — and keeps it as boring to deploy as the rest of the server.

Sierpe 1.2.0 — history below the retention wall

Stellar RPCs retain about seven days of events. Until now, Sierpe stopped at that wall and recorded what it could not reach as a declared gap. In 1.2.0 it goes through the wall.

Sierpe 1.1.0 — token transfers and trustlines

Sierpe 1.1.0 adds two data kinds beyond events and contract state, both under the same honesty contract as the rest of the API.

Sierpe 1.0.0 released

The first public release of Sierpe is out. Milestones M0 through M3 are complete and verified live against the Stellar testnet.