@toshi: Trust Infrastructure Hiding in Plain Sight

I built @toshi (pronounced at-toshi), a fresh look at the 2008 whitepaper and Hal Finney’s musings from 1994 along with a big “what if?” This is the thinking behind it.

What AT Protocol Already Gives You

AT Protocol was built for social networking. But look at what it actually gives you.

Every user gets a cryptographic identity. A DID. Every action is signed. Every post, follow, interaction goes into a personal data repository. Merkle tree. Content-addressed. Verifiable by anyone. Portable between servers.

These are the same properties that make blockchains valuable. The difference is blockchains get there through global consensus. Everyone has to agree on the state before anything moves. It works. It’s also expensive. Energy, complexity, latency. And somehow everything ends up financialized.

AT Protocol gets the same properties a different way. Instead of requiring everyone to agree on truth, it just makes truth verifiable. Any observer can replay your repository from the start, check every signature, compute the current state themselves.

Trust becomes something you calculate. Not something a network certifies for you.

The Entity

So what does a token system look like on this?

You have an Entity. A dedicated PDS that sequences transactions. Alice wants to send tokens to Bob. She signs a transfer, submits it to the Entity. The Entity validates, commits to its public repo, broadcasts to the network. Anyone who wants Bob’s balance can replay the history and compute it.

The Entity has real power here. It orders transactions. It could censor. It could manipulate. Traditional thinking says this is the vulnerability. The whole point of decentralization is preventing any single party from having this control.

But the Entity operates in full public view. Every commit is signed. Content-addressed. Broadcast to the firehose. It can sequence however it wants. It just can’t hide what it did.

This part exists. @toshi runs on a single PDS instance bootstrapped with Cirrus. It’s 100% firehose dependent and needs the occasional manual sync. Early days. The project is open source on Tangled.

What follows is where it could go.

Taps as Validators (Proposed)

The Entity writes. The Tap reads.

The Entity sequences. The Tap validates.

Tap is middleware from Bluesky. Connects to the firehose, filters to specific accounts. For a token system, a Tap node subscribes to the Entity’s DID and does forensic analysis on every commit in real time. Running a Tap means running your own auditor.

Two layers of validation. First layer is physics. Hard rules. Does this commit hash to the root from the previous commit? Did the signer actually sign this? These checks happen before your code even sees the data. Prevents history rewriting and forgery at the protocol level.

Second layer is the token rules. Soft rules in the Toshi plugin. Commit arrives, plugin decodes, applies constraints. Has this input been spent already? Double-spend alert. Do outputs exceed inputs? Inflation alert. If it passes, update local state. Remove spent inputs, add new outputs.

This is fundamentally different from blockchain validation. Bitcoin miner is a gatekeeper. Stands at the door of the next block. Invalid transaction? Physically blocked from entering.

Tap node is a whistleblower. Can’t prevent the Entity from writing a bad commit. Only the Entity has those keys. But it can detect fraud instantly, prove it mathematically, broadcast the evidence.

Response to fraud is social. Tap node’s validation fails, it publishes a fraud proof to its own repo. Invalid block CID plus Entity’s signature. Wallets query their trusted Tap nodes. Surface alerts when fraud proofs appear. Community sees evidence, decides response. Users trigger emergency exit, export last valid UTXOs, import into a new honest Entity.

Reverse Panopticon. Bentham’s original was a prison where one guard watches many prisoners. Prisoners behave because they might be watched. Tap inverts this. Prisoners watch the guard. Entity behaves because thousands of independent nodes watch every commit. Misbehavior produces immediate cryptographic proof.

Cost of dissent approaches zero. Proof of Work fork needs massive hardware. Proof of Stake fork needs capital migration. Here the state is just signed data. Anyone can snapshot last valid state, spin up new Entity, continue from there. Penalty for misbehavior is instant exile. Community reconstitutes around honest infrastructure with minimal friction.

Why run a Tap? Merchant processing volume runs one to verify payments independently. Trading bot runs one because arbitrage needs state before the UI updates. Security as byproduct of speed. Community server runs one to warn members if the Entity acts against them.

Validator network scales organically. Collection signaling. Configure a Tap to track any repo with a specific record type. New user creates wallet record in their PDS, Tap nodes across the network start tracking automatically. Network grows with user base. No coordination. No registry.

The Object Layer (Proposed)

Bitcoin Ordinals and Ethereum NFTs share an inefficiency. They store media on infrastructure designed for financial consensus. Ordinals inscribe raw image data into witness data. Bloats the ledger forever for every node operator. Ethereum NFTs usually store metadata off-chain because on-chain is too expensive. IPFS or AWS. External dependency that may or may not persist.

AT Protocol already separates content from consensus. User media lives in their PDS. Already on the network. Already signed. Already content-addressed. NFT system on this can be pointer-based.

An Atthinal is a unique UTXO that wraps an AT-URI. Points to a record in someone’s repository. Token has a reference field: at://did:plc:bob/app.bsky.feed.post/3k7.... Media stays where it lives. Token is tradeable proof of ownership over that reference.

Minting verifies authorship. Bob posts a photo. Data lives in his PDS. He sends one TOSHI to the Entity with a mint instruction targeting that post’s URI. Entity checks Bob’s repo, verifies he authored it by validating signature. Destroys input TOSHI, creates NFT-UTXO with reference pointing to Bob’s post. Trading is normal transfer mechanics. Bob spends NFT-UTXO to Alice, Entity records it, Alice owns the token pointing to Bob’s content.

Ephemerality is a feature. Bob deletes the post, token points to 404. Value was never the file. It was signed acknowledgment of authorship at a moment. Viral content has value because context, moment, social proof. Inscription captures provenance without imposing storage costs on the network.

Extension supports programmable royalties. Entity enforces rules on reference outputs. This UTXO can’t be spent unless 5% goes to original author’s DID. Copyright management native to the protocol. Buy a token, buy a license that pays the creator on every transfer.

ARC Standards (Proposed)

Copying Ethereum standards imports EVM baggage into a protocol that works differently. ERC numbers reflect chaotic EIP history. Sequence by submission order, not logic. Native standard should organize by social primitive.

ARC taxonomy starts from first principles. Groups standards by what value represents and how it relates to identity, relationships, interaction.

Primitives (00-09)

Fundamental value storage. ARC-00 is standard fungible. Base unit of account. Minimum schema for PDS as ledger. Balance, transfer, mint, burn. ARC-01 is standard object. Unique pointer to AT-URI. After money, things.

Identity (10-19)

Value attached to who you are. ARC-10 is repo-bound account. DID owned by a token. Private key controlled by token holder. Transfer token, DID’s rotation key updates to new owner. Tradeable brand accounts. Bot personas. Agents that change hands. ARC-11 is attestation token. Restricted assets checking for credentials in user repo before receipt. Token requires “verified human” badge or age verification or jurisdiction credential. Signed by trusted authority, stored in recipient’s PDS.

Graph (20-29)

Value from relationships. ARC-20 is liquid graph. Token ownership alters social graph programmatically. Buy token, Entity writes follow to your repo. Sell, deletion. Subscription as liquid asset. Tradeable access control. ARC-21 is algorithmic vault. Pool funds to influence feed generators. Deposit ARC-00, vault boosts or pins content on custom feeds. Decentralized ad network governed by community.

Interaction (30-39)

Value triggered by social actions. ARC-30 is social intent. Text patterns in posts become financial execution. Cashtag syntax, mention parsing, safety mechanisms. Dust limits, cooldowns, reply-to-confirm. ARC-31 is reaction payment. Financial value tied to likes, reposts, reactions. Like becomes micropayment. Engagement as monetization without platform cut.

Taxonomy frames ecosystem as social engineering rather than financial engineering. Standards build from value to identity to relationship to action. Reflects actual structure of social protocol. Not historical accidents of another chain.

Why This Matters

Pattern underneath all this is the same. Cryptographic identity. Verifiable history. Others compute trust from that history.

The basic token system works today. Entity sequences in public view. Firehose broadcasts every commit. The rest (Tap validators, object layer, ARC standards) is where it could go. Infrastructure waiting to be built on primitives that already exist.

Social network already has identity. Already has verification infrastructure. Already has the graph that makes trust meaningful. Build financial applications here and you inherit those properties instead of reconstructing them.

idk. Seems easier than starting from scratch.

@toshi

Proof of concept running at attoshi.com. Single PDS instance. Firehose dependent. Needs manual sync sometimes. Things will break.

Open source on Tangled.

If you want the technical details, the whitepaper covers the architecture, transaction model, and issuance mechanics.