@toshi WHITEPAPER
ATPROTO ATTESTATION
A Peer-to-Peer Electronic Cash System for AT Protocol
Abstract
A purely peer-to-peer version of electronic cash for decentralized social networks would allow value to be transferred directly between participants without requiring external blockchain infrastructure. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution using a dedicated entity on the AT Protocol network that serves as witness and sequencer for transactions. The entity maintains an ordered log of transactions in a publicly auditable repository structured as a Merkle Search Tree. Coins are issued when users follow the entity, creating a demand-driven distribution mechanism native to social interaction. Ownership is proven through chains of digital signatures over unspent transaction outputs. The system is transparent, verifiable by any observer, and preserves user sovereignty over funds. The entity can sequence transactions but cannot forge signatures, rewrite history, or spend coins it does not own.
This project is an experiment. The token described herein is not a financial instrument, investment vehicle, or store of value. It has no monetary worth and should not be treated as such. The system exists solely to demonstrate that cryptographic token mechanics—issuance, transfer, and verification—can be implemented natively within a decentralized social protocol without external blockchain infrastructure.
1. Introduction
Commerce on decentralized social networks has come to rely on external systems to process value transfer. Blockchain-based solutions require users to maintain separate identities and interact with separate networks. The friction of bridging social identity to blockchain identity limits adoption. Platform-based solutions require trusting intermediaries who can freeze funds, charge fees, and restrict transactions.
What is needed is an electronic payment system based on cryptographic proof that operates within the social protocol itself. We propose a system where the token exists as a participant in the network with its own decentralized identifier, its own repository, and its own presence. Users interact with it using the same primitives they use to interact with each other. Issuance is triggered by the social act of following. Transfers are validated and recorded in a public repository. Any observer can verify the complete state by replaying the transaction log.
2. Transactions
We define a coin as a chain of digital signatures. Each owner transfers to the next by signing a transaction that references previous unspent outputs and specifies new recipients. A payee can verify the chain of signatures to verify ownership.
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Transaction 0 │ │ Transaction 1 │ │ Transaction 2 │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ │ │ Input: │ │ Input: │
│ Output 0: │────▶│ tx/0:0 │────▶│ tx/1:0 │
│ Owner: Alice │ │ Sig: Alice │ │ Sig: Bob │
│ Amount: 100 │ │ │ │ │
│ │ │ Output 0: │ │ Output 0: │
│ │ │ Owner: Bob │ │ Owner: Carol │
│ │ │ Amount: 70 │ │ Amount: 70 │
│ │ │ │ │ │
│ │ │ Output 1: │ │ │
│ │ │ Owner: Alice │ │ │
│ │ │ Amount: 30 │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
A transaction consumes inputs and produces outputs. Each input references a previous output by transaction identifier and index, and includes a signature from the owner of that output. Each output specifies a recipient by decentralized identifier and an amount. If the sum of input amounts exceeds the sum of output amounts, the difference is destroyed. This is the mechanism for removing coins from circulation.
The problem is that a payee cannot independently verify that an input was not already spent in another transaction. The traditional blockchain solution requires global consensus among all participants. We propose a simpler model sufficient for social network contexts.
3. Entity
We introduce an entity: a dedicated participant in the AT Protocol network that witnesses and sequences transactions. The entity possesses a decentralized identifier (DID) of the form did:plc:{identifier}, maintains a repository, and appears on the network as any other account would.
When a user submits a transaction, the entity validates the signatures using the signing keys published in each signer's DID document, confirms the referenced inputs exist and are unspent, and if valid, appends the transaction to its repository as a new commit. The commit sequence determines canonical ordering. If two transactions attempt to spend the same input, the entity accepts whichever it processes first and rejects the other.
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Commit 0 │────▶│ Commit 1 │────▶│ Commit 2 │────▶│ Commit 3 │
├──────────┤ ├──────────┤ ├──────────┤ ├──────────┤
│ rev: t0 │ │ rev: t1 │ │ rev: t2 │ │ rev: t3 │
│ prev: ø │ │ prev: c0 │ │ prev: c1 │ │ prev: c2 │
│ data: d0 │ │ data: d1 │ │ data: d2 │ │ data: d3 │
│ sig: σ0 │ │ sig: σ1 │ │ sig: σ2 │ │ sig: σ3 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │
└───────────────┴───────────────┴───────────────┘
│
Signed by Entity Key
Each commit contains a revision identifier in TID format, a pointer to the previous commit, a content identifier linking to the Merkle Search Tree root containing updated records, and a signature. The signature is produced by serializing the unsigned commit as DAG-CBOR, hashing with SHA-256, and signing with ECDSA using the entity's signing key. The repository is public. Any observer can retrieve the complete commit history and verify signatures against the entity's DID document.
This model requires trusting the entity to sequence transactions honestly. In exchange, it eliminates proof-of-work, global consensus, and economic incentives for external validators. The trust is explicit and bounded.
4. Issuance
In proof-of-work systems, new coins are issued to whoever performs the computational work of building blocks. The work proves resource expenditure and provides fair distribution.
In our system, the work is social. New coins are issued when a user follows the entity. A follow is a signed record in the user's repository conforming to the app.bsky.graph.follow lexicon:
{
"$type": "app.bsky.graph.follow",
"subject": "{entity-did}",
"createdAt": "{timestamp}"
}
The record is stored at an AT URI of the form at://{user-did}/app.bsky.graph.follow/{tid} where the record key is a TID. The record is signed as part of the user's repository commit, with the signature verifiable against the user's DID document.
The entity subscribes to the network relay firehose at the WebSocket endpoint com.atproto.sync.subscribeRepos. When a #commit event contains an operation creating a follow record where the subject matches the entity's DID, the entity verifies the commit signature, confirms the user has not previously received issuance, and creates an issuance transaction.
User's Repository Entity's Repository
┌─────────────────────┐ ┌─────────────────────┐
│ app.bsky.graph │ │ Issuance Record │
│ .follow/{tid} │ ├─────────────────────┤
├─────────────────────┤ Observation │ trigger: │
│ subject: {entity} │ ─────────────────▶ │ at://{user}/... │
│ createdAt: {time} │ via firehose │ │
│ │ │ outputs: │
│ (signed in user's │ │ 0: user, 100 │
│ repo commit) │ │ 1: treasury, 100 │
└─────────────────────┘ └─────────────────────┘
Each issuance transaction has no inputs and two outputs: one to the user, one to a treasury. The user receives coins for joining. The treasury accumulates funds for collective purposes.
Issuance follows a halving schedule with a dynamic split. The total reward halves every 10,000 followers, while the user/treasury split shifts to favor early adopters:
| Era | Follower Range | Total Reward | User % | Treasury % | User Amount | Treasury Amount |
|---|---|---|---|---|---|---|
| 0 | 0–9,999 | 200,000 | 95% | 5% | 190,000 | 10,000 |
| 1 | 10,000–19,999 | 100,000 | 90% | 10% | 90,000 | 10,000 |
| 2 | 20,000–29,999 | 50,000 | 85% | 15% | 42,500 | 7,500 |
| 3+ | 30,000+ | 25,000... | 80% | 20% | 20,000... | 5,000... |
Early followers receive a larger share of the total reward (95%), incentivizing early adoption. As the network grows, the treasury accumulates a larger percentage (up to 20%), providing resources for ecosystem development. The total reward continues halving each era regardless of the split.
Total supply is bounded by the schedule. Each DID may receive issuance exactly once. The entity maintains an index of issued DIDs. Unfollowing and refollowing does not trigger new issuance; the identity has already been recorded.
5. Validation
The entity applies the following rules to each submitted transaction:
For issuance transactions:
- The trigger must reference a valid follow record in the user's repository
- The follow record's subject must be the entity's DID
- The user's DID must not appear in the issuance index
- The output amounts must match the schedule for the current follower count
For transfer transactions:
- Each input must reference an existing output by transaction identifier and index
- Each referenced output must not appear as an input in any prior transaction
- Each input must include a valid signature from the DID that owns the referenced output
- The sum of input amounts must be greater than or equal to the sum of output amounts
- The transaction must not reference its own outputs as inputs
If all conditions hold, the entity appends the transaction to a new commit. If any condition fails, the entity rejects the transaction and returns an error specifying which condition was not satisfied.
6. Repository
The entity stores all state in its AT Protocol repository. Records are organized in collections and addressed by AT URIs. The repository data structure is a Merkle Search Tree with SHA-256 hashing.
Repository Root
│
├── token.config/self
│ {
│ "name": "{token-name}",
│ "entity": "{entity-did}",
│ "treasury": "{treasury-did}",
│ "policy": {
│ "userAmount": 100,
│ "treasuryAmount": 100,
│ "halvingInterval": 10000,
│ "maxIssuances": 210000
│ }
│ }
│
├── token.tx/{tid}
│ {
│ "type": "issuance" | "transfer",
│ "inputs": [...],
│ "outputs": [...],
│ "trigger": {...} | null
│ }
│
├── token.utxo/{txid}:{index}
│ {
│ "owner": "{did}",
│ "amount": {integer},
│ "spent": false
│ }
│
└── token.issued/{did-hash}
{
"did": "{user-did}",
"followUri": "at://...",
"issuedAt": "{timestamp}",
"txId": "{tid}"
}
The token.tx collection contains the ordered transaction log. The token.utxo collection provides an index of unspent outputs for efficient validation. The token.issued collection tracks which DIDs have received issuance. All records are content-addressed and included in the Merkle Search Tree, allowing any observer to verify inclusion and integrity.
7. Verification
Any party can verify the complete system state by retrieving the entity's repository and replaying the transaction log:
procedure Verify(repository):
utxo ← {}
supply ← 0
issued ← {}
for commit in repository.commits ordered by revision:
verify commit.signature against entity DID document
for tx in commit.transactions:
if tx.type = "issuance":
verify tx.trigger references valid follow record
verify tx.trigger.subject = entity.did
verify tx.outputs[0].owner not in issued
verify amounts match schedule for |issued|
for output in tx.outputs:
utxo[tx.id, output.index] ← output
supply ← supply + output.amount
issued ← issued ∪ {tx.outputs[0].owner}
else: // transfer
inputSum ← 0
for input in tx.inputs:
verify (input.txId, input.index) in utxo
verify input.signature against utxo[...].owner
inputSum ← inputSum + utxo[...].amount
delete utxo[input.txId, input.index]
outputSum ← 0
for output in tx.outputs:
utxo[tx.id, output.index] ← output
outputSum ← outputSum + output.amount
verify inputSum ≥ outputSum
supply ← supply - (inputSum - outputSum)
return utxo, supply, issued
If verification fails at any step, the specific transaction and condition serve as a fraud proof. The entity's continued operation depends on maintaining a valid log.
8. Trust Model
The entity can:
- Sequence transactions, choosing which of two conflicting transactions to accept
- Decline to process a valid transaction
- Cease operation
The entity cannot:
- Create transactions without valid signatures from the relevant key holders
- Spend outputs owned by DIDs whose signing keys it does not control
- Modify committed transactions, as this would invalidate the Merkle tree root
- Issue outside the defined schedule, as any observer can verify issuance counts
- Issue to the same DID twice, as the issuance index is public
The system is secure as long as the entity operates honestly. If the entity sequences dishonestly, the dishonesty is provable by any observer who replays the log. Users who find the entity untrustworthy can publish evidence, migrate state to a new entity by replaying valid transactions, or exit with their complete transaction history.
9. Network
The system uses existing AT Protocol infrastructure:
The entity subscribes to the relay firehose to observe follow events. The firehose is a WebSocket stream that emits #commit events containing repository operations. Each event includes a sequence number for reliable consumption, the account DID, and a CAR-encoded block containing the repository diff.
All state is stored in standard AT Protocol repositories accessible via the com.atproto.sync.getRepo and com.atproto.repo.getRecord endpoints. Repositories are portable; users can export and verify data independently of the entity.
Identity is based on decentralized identifiers. Users interact with the token using the same DID they use for social interaction. The entity can register a handle, making it discoverable as a social actor.
No additional peer-to-peer network is required. No separate consensus mechanism operates. The token exists within the social network.
10. Social Triggers
Beyond explicit wallet transactions, the system supports transfers triggered by social actions. The entity observes the network firehose for specific patterns and executes transfers automatically when conditions are met.
Cashtags. A cashtag is a token symbol prefixed with $ that appears in social posts. When a user includes $attoshi {amount} in a reply, the entity interprets this as an intent to transfer:
User A's Post User B's Reply
┌─────────────────────┐ ┌─────────────────────┐
│ "Check out this │ │ "Great work! │
│ cool project" │◀───────────────────│ $attoshi 100" │
│ │ reply │ │
│ author: did:plc:aaa │ │ author: did:plc:bbb │
└─────────────────────┘ └─────────────────────┘
│
▼
┌─────────────────────┐
│ Transfer Transaction│
├─────────────────────┤
│ inputs: │
│ B's UTXOs │
│ outputs: │
│ 0: A, 100 │
│ 1: B, change │
│ trigger: │
│ type: cashtag │
│ postUri: at://... │
└─────────────────────┘
The entity parses the post text for the pattern $attoshi {amount}, extracts the parent post's author as recipient, verifies the sender has sufficient balance, and executes the transfer. The post itself serves as authorization—it is a signed record in the sender's repository, proving intent.
Rate limiting prevents abuse:
| Constraint | Value | Purpose |
|---|---|---|
| Max per transfer | 10,000 | Limit exposure per action |
| Min per transfer | 0.000001 | Prevent dust spam |
| Cooldown | 60 seconds | Rate limit per sender |
The entity replies to successful transfers with a confirmation containing a link to the transaction record, providing immediate feedback and public attestation.
This mechanism transforms social interaction into financial action. Tipping becomes native to the reply interface. No wallet application is required—any client that can compose posts can send value.
Future triggers. The pattern extends to other social primitives:
- Mentions:
$attoshi 100 @alice.bsky.socialsends directly to a mentioned user - Quotes: Including cashtag when quoting a post tips the original author
- Likes: A like on a post from the entity's account could trigger micro-transfers
- Reposts: Sharing content could include automatic attribution payments
Each trigger type requires careful design of authorization semantics and abuse prevention.
11. Token Standard
The architecture described forms the basis of a token standard for AT Protocol, analogous to ERC-20 for Ethereum. We term this ARC-20 (AT Protocol Request for Comments).
An ARC-20 token is defined by a configuration record specifying identity, policy, and behavior:
token:
name: "Attoshi"
symbol: "TOSHI"
cashtag: "attoshi"
decimals: 6
pds:
hostname: "pds.example.com"
did: "did:web:pds.example.com"
issuance:
trigger: "follow"
maxSupply: 42000000000000
halvingInterval: 10000
maxIssuances: 210000
cashtag:
enabled: true
maxPerTransfer: 10000
cooldownSeconds: 60
contexts:
reply: true
mention: false
This configuration serves as the "constructor" for deploying a token. The PDS acts as the smart contract—it holds state, validates transactions, and responds to triggers. The DID serves as the contract address.
Standard interface. Any ARC-20 token exposes XRPC methods:
| Method | Description |
|---|---|
getConfig |
Token metadata and policy |
getSupply |
Circulating supply and issuance count |
getBalance |
Balance for a DID |
getUtxos |
Unspent outputs for a DID |
getTransaction |
Transaction details by ID |
submitTransaction |
Submit signed transfer |
Clients can interact with any ARC-20 token using the same interface, enabling wallet applications that support multiple tokens.
Composability. Multiple ARC-20 tokens can interact. Atomic swaps between tokens use hash-locked outputs. A single PDS can host multiple tokens with distinct policies. Cross-token exchanges emerge from the primitive operations.
12. Extensions
The base system supports issuance and transfer. Additional functionality can be constructed using conditional outputs.
Multi-signature. An output can specify multiple owners and a threshold:
{
"owners": ["{did-1}", "{did-2}", "{did-3}"],
"threshold": 2,
"amount": 100
}
Spending requires signatures from at least the threshold number of owners.
Time locks. An output can specify a time before which it cannot be spent:
{
"owner": "{did}",
"amount": 100,
"lockedUntil": "2025-06-01T00:00:00Z"
}
The entity rejects any transaction attempting to spend the output before the specified time.
Hash locks. An output can require a preimage that hashes to a specified value:
{
"hashlock": "{sha256-hash}",
"recipient": "{did}",
"amount": 100,
"timeout": "2025-01-20T00:00:00Z",
"timeoutRecipient": "{did}"
}
The recipient can claim by providing the preimage. After the timeout, the timeout recipient can claim without the preimage. This enables atomic swaps between entities.
These extensions compose. Validation rules extend to check additional conditions before accepting a transaction.
13. Privacy
All transactions are public. The entity's repository is retrievable by any observer. This is a deliberate design choice; transparency enables verification.
Privacy can be improved through several mechanisms. Decentralized identifiers do not inherently reveal real-world identity; users can generate new DIDs for different contexts. Users can distribute holdings across many small outputs. Multiple users can construct joint transactions that obscure the mapping between specific inputs and outputs.
Full privacy is not a design goal. The tradeoff is transparency for simplicity and verifiability.
14. Conclusion
We have proposed a system for electronic cash native to AT Protocol. The token exists as an entity on the network with its own decentralized identifier and repository. Issuance is triggered by the social act of following, creating demand-driven distribution. Transfers can be initiated through wallet interfaces or through social actions like cashtags in replies. A chain of digital signatures proves ownership. The entity sequences transactions and maintains a publicly auditable log structured as a Merkle Search Tree.
The architecture establishes a token standard—ARC-20—that enables any entity to deploy programmable value on AT Protocol. The PDS serves as the smart contract: it holds state, validates transactions, and responds to social triggers. The DID serves as the contract address. No external blockchain is required.
Any observer can verify the complete state by replaying the log. The entity can sequence but cannot forge, rewrite, or spend without authorization. Social actions become financial actions. The system requires no mining, no global consensus, and no separate network. Value transfer becomes native to social interaction.
References
[1] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
[2] AT Protocol Specification. https://atproto.com/specs
[3] DID:PLC Method Specification. https://web.plc.directory/spec/v0.1/did-plc
[4] Merkle, R.C. (1980). Protocols for Public Key Cryptosystems. IEEE Symposium on Security and Privacy.