Skip to content
GIWA Sepolia · 91342Live contract state

A newsroom that pays its readers, and can prove it can afford to.

Syndix runs an AI journalist over GIWA chain state, publishes each issue onchain with a funded reward pool, and settles a micro-reward to every verified reader who finishes it. Every number on this page is read from the deployed contract when you load it - nothing here is typed in by hand.

The economics

Why this can only exist on an L2

A reader reward is worth about ten cents. The question that decides whether the product is viable is simple: does it cost more than ten cents to deliver? On GIWA it costs a rounding error.

Reward per reader
$0.06

0.00003 ETH · ₩82

Gas to deliver it
0.000000180 ETH

180,313 gas @ 1000260 wei

Reward ÷ delivery cost
166×

higher is better; below 1× the product dies

The gas figure is not an estimate. It is 180,313gas, measured from the first real claim that settled on GIWA, priced at the network's gas price right now. On Ethereum L1 the same transaction would cost multiples of the reward it delivers, and this business has no floor to stand on.

Live contract state

What the treasury holds right now

Read from SyndixTreasury at request time. The solvency check is the one that matters: reader-owed ETH is tracked separately and is unreachable by the protocol owner.

Issues published onchain
10
Verified readers who have claimed
3
Distributed to readers
0.0001 ETH$0.29
Reserved for readers (owner cannot touch)
0.0024 ETH
Unreserved surplus (withdrawable)
0.0036 ETH
Solvency invariant - balance ≥ reserved
Holds
Read at block
32102373

How it works

Four steps, three of them onchain

  1. 01

    The agent reads GIWA

    An ingestion pass pulls live head state from the Flashblocks RPC alongside ecosystem signals, then claude-opus-5 writes the issue against a fixed schema.

  2. 02

    The issue is published with a funded pool

    publishArticle moves ETH straight into reservedRewards. From that moment the money belongs to readers, not to the protocol.

  3. 03

    Reading produces an attestation

    Finish an issue and the attester signs an EIP-712 ReadProof binding your address, the article and your dwell time. It signs only - it never holds funds.

  4. 04

    You claim it yourself

    You submit the transaction, so nobody can claim on your behalf. The receipt is read under the pending tag, so it confirms in about 200ms.

Security model

One human, one claim - or there is no business

A reward pool keyed on wallet addresses is not a product, it is a faucet. With 1-second blocks and sub-cent gas, a script generates ten thousand addresses and drains every pool in a single block. Everything below exists to stop that.

Identity

Claims require a verified GIWA identity through IReaderRegistry, pointed at the live Upbit Web3 Names registry. A name is a Soul-Bound Token capped at one per wallet, issued by GIWA and not by us - Syndix cannot mint itself the credential it checks. That cap is the whole security model.

Proof of read

A claim carries an EIP-712 ReadProof signed by the attester. The reader still submits the transaction, so a compromised attester can forge proofs but cannot move money or claim for someone else.

Solvency

Every wei promised to a reader sits in reservedRewards. withdrawTreasury spends only unreservedBalance(), so an owner fee-take can never strand an outstanding claim. Fuzzed over 256 runs.

Each property is pinned by a regression test in test/contracts/SyndixTreasury.t.sol. Two of them fail against the original blueprint contract, which withdrew against the raw balance and accepted an unverified identity string.

Why GIWA

Four properties this depends on

Flashblocks - preconfirmations up to 200ms
https://sepolia-rpc-flashblocks.giwa.io
~1s blocks, sub-cent fees
makes a $0.10 reward viable
up.id - Soul-Bound, one per wallet
one ecosystem namespace, read by our reader registry
ERC-4337 EntryPoint v0.7 predeployed
0x0000000071727De22E5E9d8BAf0edAc6f37da032

Deployments

Verify it yourself

Roadmap alignment

Two things GIWA is building that Syndix is waiting on

Both were announced as Coming Soon on giwa.io, and both close a gap this build has already run into rather than a hypothetical one.

Stable PayMaster

SyndixPaymaster is deployed, staked and funded against the EntryPoint v0.7 predeploy, and its validation logic is tested - but it cannot be used. Relaying a UserOperation also needs a smart-account factory on GIWA and a bundler serving chain 91342, and neither exists today. A first-party paymaster makes Syndix a consumer of that infrastructure instead of a project that has to run it.

Until then readers submit their own claim and pay roughly 0.00000018 ETH for it - about a 166th of the reward.

KRW stablecoin

This one fixes a real defect. Syndix promises a 100 KRW micro-reward, but pays 0.00003 ETH - worth about ₩132 when the figure was chosen and about ₩83 a few weeks later. The reader cannot predict what they will receive, and the headline number drifts with a market they never opted into.

Denominated in a KRW stablecoin, ₩100 is ₩100. SyndixStableTreasury is written and tested for exactly that - same three invariants, ERC-20 value primitive - and is not deployed, because there is no token to point it at yet.

GIWA Wallet needs no work: it will inject over EIP-6963, and the connect flow enumerates connectors generically rather than allow-listing them, so it appears as soon as it ships.

Honesty

What is real and what is not

A grant reviewer should not have to guess which parts are load-bearing. This table is maintained deliberately.

ComponentStatus
Smart contractsReal. Deployed and verified, 101 passing Foundry tests including three fuzzed invariants.
Reader reward claimReal. Attested by /api/attest, submitted by the reader, settled on GIWA Sepolia.
Proof of readReal, and measured by the server. A signed session is stamped with the server clock, heartbeats carry scroll depth, and beats arriving faster than real time are refused - dwell is never client-reported. It proves time and scrolling, not comprehension.
up.id identityReal, and not ours. Claims gate on the live Upbit Web3 Names registry, so a wallet without a genuine up.id cannot claim - including our own deployer.
GIWA chain readsReal. This page and the ingestion agent query live state.
Issue contentReal. The feed reads the treasury's article index and fetches each body from IPFS. No issue is bundled in the app.
IPFS pinningReal. Issues are pinned via Pinata and publishing is blocked if pinning fails, so nothing is indexed pointing at nothing.
Analytics time seriesReal. Daily buckets reconstructed from RewardClaimed and ArticlePublished logs. Empty days render empty rather than interpolated.
AI issue generationReal. Every live issue was written by gpt-4.1 against a strict JSON schema, seeded with head state read at generation time - each one records its model in the IPFS metadata the treasury points at, so the claim is checkable rather than asserted.
x402 endpointReal protocol. Settlement is verified onchain now that a treasury exists.
Sponsorship revenueContract written and tested, not deployed. SyndixSponsorship splits each deposit into a capped protocol fee and a reader-committed remainder no owner function can reach. To date the treasury is entirely self-funded and external revenue is zero.
Autonomous publishingNot built. Writing is unattended, but publishing needs an owner signature and there is no scheduler. SyndixPublisher, the guard that closes this safely, is written and tested with 21 tests but not deployed.
Gasless via ERC-4337Paymaster deployed, staked, funded and tested - but not in the claim path: GIWA has no smart-account factory and no bundler yet, so readers pay their own gas.
KRW denominationNot deployed. SyndixStableTreasury is written and tested against a mock; GIWA's KRW stablecoin does not exist yet.