Bitcast SN93 turns its creator engine into an application API

Bitcast SN93 is trying to separate the engine that scores creator campaigns from the products people use to run them.

The project described that direction publicly on September 3. Its shorthand compared different teams building different cars around the same Bitcast engine. The public repository now makes the comparison more concrete with a versioned application API for creator platforms.

The API does not prove that independent products have customers or revenue. It does establish a boundary in code and documentation. Bitcast’s miner node can expose campaign discovery, creator qualification, eligibility, claims, submissions, results and reward recommendations without deciding how every application should look, charge or manage users.

The implementation gives Bitcast a more substantial role than a creator dashboard alone.

September 10 update: identical same-block writes can now reconcile

Bitcast has merged a narrow repair for an awkward chain edge case inside this application path.

Miner recovery and validator scanning previously rejected a finalized block when one miner had sent more than one direct commitment call in that block, even when every successful call stored the same bytes. Pull request 130 introduces a shared resolver for both paths.

The resolver does not accept duplicates broadly. It collapses only byte-identical successful calls from one miner in the same block, selecting the last successful extrinsic after checking the block’s dispatch outcomes and block-pinned commitment storage. Missing, malformed, conflicting or storage-mismatched evidence is still rejected.

Chain-operation failures now return a retryable HTTP 503 chain_operation_unavailable response. Definite validation errors keep their non-retryable meaning. That distinction prevents a temporary chain read failure from being presented as bad creator evidence.

The repository includes a wallet-free replay of public Finney block 9,031,452. Bitcast reports that it resolved one commitment at extrinsic index 11 with sequence 490. Its test record lists 388 passing tests, three opt-in skips and two passing localnet integration tests.

These are project-reported validation results. Tao Outsider did not independently reproduce the replay, and the pull request explicitly says the trigger for the duplicate send remains a hypothesis. The merge does not establish an exploit, stolen rewards, customer impact, production deployment or acceptance by every external validator.

The update strengthens the original application-API story because reconciliation is where a shared campaign engine either becomes dependable infrastructure or leaks ambiguity into every product built above it.

What the Bitcast SN93 application API exposes

Bitcast documents /api/v1 as the stable interface between a miner node and a creator product built on top of it. The routes cover the operational life of a campaign, from discovering a brief to reading its final results.

Resource	What an application can read or do
Qualification and ecosystems	Check the miner’s current qualification and enabled markets
Leaderboard	Read a combined, paginated creator ranking
Campaigns and eligibility	Discover briefs and check whether a creator can participate
Claims	Register a pre-publication claim and inspect its status
Submissions	Submit published work and track scoring and rewards
Campaign results	Read the tweets associated with a campaign

The documentation deliberately leaves platform sessions, wallet connections, creator payments, branding and product-specific policy outside the API. A team can use the common campaign machinery while owning those commercial and interface decisions itself.

This is the strongest evidence behind Bitcast’s platform claim. It is an implementation surface, not a list of prospective partners.

The difficult details are about reconciliation

Creator campaigns generate awkward state changes. A user may click twice. A brief can close while a request is still moving. A post can exist before its submission reaches the chain. A platform’s internal identifier should not silently become the protocol’s source of truth.

The API addresses several of those problems explicitly. Mutations require an idempotency key, so reusing the same key with a different payload returns a conflict rather than creating a second ambiguous action. An external identifier lets a platform reconcile its own record without making that identifier authoritative for the protocol.

Every submission also carries an immutable numeric X creator ID. The miner commits it into the event, and validators compare it with the author of the fetched post before attributing a direct or exclusive submission.

Those controls do not establish that the market cannot be gamed. They show where Bitcast expects disputes to occur and which records its applications need to preserve.

Recent repository changes address campaign edge cases

Two September 1 changes sharpened that application boundary.

One is designed to allow existing posts to be submitted during a defined grace period for an exclusive direct campaign. The posting window does not reopen. Claims and new publications remain closed, historical eligibility still applies, and validators reject posts published after the campaign deadline.

The miner must also force its durable event on-chain and compare the finalized block with the scoring close block. A late commitment fails. A commitment that is not confirmed inside the bounded request window returns a retryable pending response rather than pretending that submission succeeded.

Another change is designed to refresh engagement for featured posts every hour. That is a practical product concern because a creator application cannot keep showing a stale score indefinitely while the underlying post continues to collect attention.

Tao Outsider verified the changes in the public repository, but did not verify their production deployment. Both remain listed under Unreleased in the repository’s changelog.

Neither fix proves demand. They indicate that Bitcast is working through the timing and reconciliation problems that appear when a protocol is exposed to an application.

One engine can support products with different incentives

Bitcast says SN93 maps ecosystems, identifies influence and scores content. A specialist product could choose a narrow creator category, a different interface and its own customer relationship while relying on that campaign engine.

The architecture would let a sports creator market and a crypto campaign product share protocol mechanics without sharing a brand or audience. It could also let an operator expose only the ecosystems it supports.

That possibility should remain a possibility. Tao Outsider has not verified a list of independent teams using the API, paying customers attached to it or revenue produced through third-party applications. Bitcast’s public dashboard and buyback posts are project records, not audited financial statements.

The September 3 TaoSwap snapshot showed four active miners on SN93 and an emission_value of 0.012051689. That confirms current subnet context in TaoSwap’s data. It does not prove that applications use the API or that creator campaigns are commercially durable.

Why this changes the Bitcast story

The earlier Bitcast question was whether creator work could be turned into a campaign protocol with claims, submissions and validator checks. The application API raises another one. Can that protocol become shared infrastructure without forcing every product into the same interface?

The answer will require evidence outside the repository. Independent applications need to become visible, their users need to complete campaigns, brands need to return, and payments need to reconcile with protocol records under real load.

Bitcast has not supplied all of that proof. It has published a cleaner place for the proof to arrive.