Verify

A conventional wallet is binary: whoever holds the private key can do anything. Smart accounts — the account-abstraction model standardized as ERC-4337 — replace that key with programmable logic, and that single change is what makes agent custody tractable.

The useful primitive is the session key: a temporary credential scoped to specific contracts, specific functions, a spending cap, and an expiry. An agent buying compute or paying for API calls can be granted exactly that ability and nothing else. If the agent is compromised or simply wrong, the blast radius is the budget, not the account.

What to evaluate in any agent system

Three questions sort serious designs from demos. Who can revoke the agent's permissions, and how fast? Is the spending policy enforced onchain, where the agent cannot route around it, or merely in the agent's own code? And is there an activity log a human actually reviews? On Base, where each transaction costs fractions of a cent, the honest answer to the last question is observable: the agent's full history is public, whether or not anyone is reading it.

The temptation is to treat an agent's address as just another author address. We think that conflates two claims. A signature answers "which process produced these bytes?" Authorship answers "who stands behind this if it is wrong?" An autonomous process cannot be sanctioned, corrected, or asked to defend its method — so it cannot carry the second claim alone.

Our schema separates the roles. Machine-generated entries are attested by the agent's address as producer, with a mandatory second field naming an operator — the human or organization whose reputation is staked on the output and who is reachable for disputes. Both signatures live in the same attestation; neither is hidden.

Why bother encoding this

Because the alternative is laundering: without an explicit operator field, machine output ships under a pseudonym and responsibility evaporates. Onchain publishing makes provenance cheap to record — it would be a waste to use that machinery and leave the most important provenance question, who answers for this, unrecorded.

A rollup's job is simple to state: execute transactions cheaply off mainnet, then post enough data back to Ethereum that anyone can reconstruct and verify the chain. The expensive part was always that second step. Calldata is stored forever by every Ethereum node, and it is priced accordingly.

EIP-4844 changed the deal. Blobs carry roughly 128 KB each, are priced in a separate fee market, and are pruned after about eighteen days — long enough for anyone to verify or challenge the rollup's state, short enough that nodes do not carry the weight forever. Because demand began far below capacity, blob fees opened near zero, and the savings flowed into the fees users pay on Base.

The takeaway

The cost of using Base is mostly the cost of data availability, not computation. When fees spike, check blob market congestion first. For Vossen, blobs are why attaching an onchain proof to every article is economically boring: the notary fee rounds to nothing.

On the revenue side, users pay an execution fee plus an L1-data component. On the cost side, the operator periodically posts compressed batches to Ethereum and pays for blobs and settlement. The margin is what remains, and it scales with volume: more transactions amortize each batch across more payers.

This framing makes several behaviors legible. Why do L2s court high-frequency, low-value activity like games and micro-payments? Because batch costs are nearly fixed, so marginal transactions are nearly pure margin. Why did fee floors drop after Dencun rather than margins simply widening? Competition — users can bridge elsewhere, so cost reductions get passed through.

A question worth asking of any chain

"Who earns the spread, and what obligations come with it?" There is no universally correct answer, but a chain that cannot answer the question clearly is telling you something too.

Safety — can the operator steal or forge state? — is the strongest guarantee on Base. State roots posted to Ethereum can be challenged through fault proofs, so an invalid state cannot be finalized merely because the sequencer asserts it.

Censorship resistance sits in the middle. The sequencer chooses ordering and can refuse to include you, but the OP Stack provides a force-inclusion path through the L1. Slow, but real — and its mere existence disciplines the operator.

Liveness is the genuine single point of failure today. If the sequencer halts, the fast lane halts with it. This is the axis the decentralization roadmap targets: safety yes, censorship mostly, liveness not yet.

Why a journal should care

Vossen's threat model is the permanence of records, which lives on the safety axis — the strongest of the three. An outage delays publishing an attestation by hours; it cannot rewrite one that exists.

The mechanism: instead of sending your transaction to Base's sequencer, you call the deposit contract on Ethereum mainnet directly. The protocol then obliges the rollup to include your transaction within a bounded window. No permission from the operator is involved at any step.

The costs are real, though. You pay mainnet gas, which can exceed the value of a small transaction. You wait — inclusion is bounded in hours, not seconds. And you need the operational knowledge to construct the deposit call, which today means a developer or power user, not a casual wallet owner.

Deterrent, not commuter lane

The right mental model is a fire exit. Its purpose is not daily traffic; its purpose is to make blocking the front door pointless. The hatch works mostly by never needing to be used — which is also why measuring how often it is used makes a good early-warning indicator for any L2's health.

At one extreme, data lives entirely in contract storage or calldata. It inherits the chain's full replication and permanence, and it is expensive — reserved for small, critical things: balances, hashes, short text.

One step down sits content-addressed storage like IPFS and Arweave. The chain stores a content identifier; the bytes live on a separate network. The identifier is a hash of the content, so substitution is detectable — but availability is not guaranteed by the chain. At the far end is the most common pattern: a plain URL onchain, pointing at a conventional server. The chain guarantees only that this URL was committed at this time.

What Vossen does

We store the SHA-256 hash of every article in its Base attestation, distribute documents through content-addressed storage, and encourage mirroring — the hash makes every mirror equally authoritative. The chain cannot promise your copy will always be easy to find; it can promise you will always know whether the copy you found is real.

Ethereum guarantees blob availability for roughly eighteen days — enough for fraud proofs and verification, which is all the protocol needs. After that, consensus nodes drop the data. The chain's security is untouched; the chain's memory now depends on whoever chose to keep a copy.

In practice, copies are plentiful today: explorers, research labs, the rollup operators, public archive services. But "plentiful today" is an observation about incentives, not a guarantee. Each archivist keeps data for their own reasons, and reasons change.

Permanence is a supply chain

Every "permanent" record is actually a chain of custodians, each replaceable, none obligated. Durable systems make custodianship cheap and verifiable enough that someone always finds it worthwhile — which is why Vossen pairs tiny onchain hashes with freely mirrorable documents. Anyone who keeps a copy becomes part of the archive, and the hash keeps every copy honest.

Academic citation rests on trust in publishers and archives: the DOI resolves, the journal still exists, the PDF was not quietly revised. Each of those is an institutional promise. An attestation replaces the promise with a proof — the content hash either matches the document in your hands or it does not.

The whole workflow in one paragraph

Hash the final manuscript with SHA-256. Create an EAS attestation on Base containing the hash, a content URI, and the author's address. The attestation UID becomes the citation. A reader verifies by hashing their copy and comparing — no account, no permission, no journal required to stay in business.

Revisions do not overwrite history; a new attestation references the previous UID, producing a public version chain. The record of what was claimed, and when, no longer depends on any single institution staying online or staying honest.

Consider what retraction means in traditional publishing. The paper rarely disappears; it acquires a watermark and a notice. Deletion was never the mechanism. The mechanism was always a status change, broadcast as widely as the original claim.

Onchain, that status change becomes a first-class object: a retraction attestation that references the original UID, states the reason, and is signed by the editors. Any reader resolving the original citation sees the retraction attached — because the reference structure itself contains it.

The part deletion never solved

What about content that should genuinely not circulate? Hashes onchain contain no content, and the documents live off-chain where takedown remains possible mirror by mirror. The proof that something was claimed persists; the claim's text is as removable as it ever was. That split — permanent record of the act, ordinary jurisdiction over the artifact — is the correct one for a scientific record.

The transaction is the document

Treat every transaction page as an archival document with four load-bearing fields: the from and to addresses (who acted, on what), the input data (what they asked the contract to do), the logs (what the contract says happened), and the block timestamp (when, with no possibility of backdating).

The discipline to borrow from historians is source criticism: logs are emitted by contract code, so a log is only as honest as the contract that produced it. Verified source code lets you read exactly what conditions emit each event. Unverified bytecode is an unsigned letter: real, but of unknown authorship and intent.

Three habits worth keeping

Never screenshot as evidence when you can cite a transaction hash. Distinguish the existence of an event from its meaning. And record the block number with every claim, because "current" state changes under your feet while you write.

Onchain state is a function of block height. Any quantity — a balance, a supply, a holder count — is only well-defined at a block. Most published analysis omits the block, which silently converts a reproducible measurement into an anecdote about whenever the author ran the query.

The standard Vossen enforces is tiny: every onchain quantity must carry its chain and block number, e.g. base @ block 31,204,118. With that anchor, any reader can re-derive the number exactly. Disagreement becomes diagnosable: same block, different number means a method error; different block means the world changed.

Cheap rigor compounds

Onchain research begins with the rarest precondition of reproducible science already met — a shared, public, immutable dataset. Wasting that advantage by leaving timestamps vague would be a self-inflicted wound. One sentence per claim is the whole price of not wasting it.

In traditional review, a name imports an institution's vetting. Strip the name and you lose the import — but what review actually needs is narrower: continuity (this reviewer is the same entity whose past judgments we can inspect) and stake (being wrong costs them something they cannot cheaply replace).

A long-lived keypair provides continuity outright: every signed review extends a public track record attributable to exactly that key. Stake is the harder half — a pseudonym whose reputation took years to build is expensive to burn, while a fresh key costs nothing and should be weighted accordingly.

The honest limitation

What pseudonymity cannot detect is one person operating several established pseudonyms — the Sybil problem, slow-cooked. Mitigations exist; none are complete. Vossen's review trusts track records, and track records can, with enough patience, be farmed. Readers should weight accordingly. That sentence costs us some authority and buys us more.

Start with the scope section, always. An audit covers specific contracts at a specific commit. If the deployed code differs from the audited commit — upgrades happen — the sticker describes a different artifact than the one holding your funds. Comparing deployed source against the audited commit is the highest-value check available to a lay reader.

Next, read the findings table backwards. Critical findings get headlines, but the signal is in the resolution column: "fixed" versus "acknowledged" versus "disputed." A team that acknowledges a high-severity finding without fixing it has made a judgment call you are entitled to evaluate yourself.

What an audit is not

An audit is a time-boxed search by particular humans, not a proof of correctness. The question is never "is it audited?" but "what does the security process look like, and is the report consistent with the rest of it?"

Most serious protocols, including the OP Stack chains, are upgradeable by design: bugs must be fixable. The governance question is therefore never "can the rules change?" but "who can change them, how many must agree, and how much warning do users get?"

Three parameters capture nearly everything. The signer set: how many keys, held by whom, with what independence. The threshold: how many signatures an upgrade requires. The timelock: how long an approved upgrade waits before taking effect — the users' real protection, because it converts a hostile upgrade from an ambush into an announcement people can exit ahead of.

A reading exercise

Take any chain you use and try to fill in the three parameters from public documentation in under thirty minutes. Chains that make the answer easy to assemble consider it part of the product. Chains where the answer requires forum archaeology are telling you something too.

The mechanism: each block has a target fullness, and the protocol raises the base fee when blocks run above target and lowers it below. The fee level is a direct, manipulation-resistant readout of how much people are willing to pay for inclusion right now.

That makes fee series unusually honest data. Social metrics can be botted and volume can be washed, but sustaining an elevated base fee requires continuously burning real money in public. When Base's fee floor rises for hours, something real is demanding blockspace — and the composition of that demand is itself inspectable, transaction by transaction.

Instruments need calibration notes

Fee spikes measure demand for blockspace, not value created — a meme-mint gas war reads the same as a liquidation cascade until you look. And on rollups, the L1 data component moves with the blob market, so an L2 fee series mixes local demand with upstream costs. Decompose before you interpret.

The technical reality first: every transaction you analyze was broadcast voluntarily to a public network, yet the person behind it likely never imagined a researcher linking their coffee purchase, their salary stream, and their donation history into one profile. Deanonymization is not exotic — shared deposit addresses, timing correlations, and exchange data leaks do most of the work.

Our house rules: publish aggregates wherever the finding survives aggregation; name addresses only when they belong to protocols, known entities, or actors whose conduct is itself the finding (exploiters, for instance); and never publish a chain of inference that newly links a private individual to their addresses, even if each link is public.

The test we apply

Would the analysis still be publishable if the subject were reading it over your shoulder? Transparency of the ledger is a property of the system. Restraint in what we do with it is a property of the researcher — and only one of those two is automatic.

The canonical pattern is lock-and-mint: assets are locked in a contract on chain A, and a representation is minted on chain B. Everything rests on one question — how does chain B know the lock happened? Whatever answers that question is the bridge's true security model, regardless of the marketing.

The answers form a spectrum. A multisig of named parties: you trust those parties. A validator set with staked collateral: you trust economics. Light-client or proof-based verification: you trust math and the source chain itself. Each step along the spectrum is harder to build and harder to break.

Why Base's canonical bridge is different in kind

The native bridge between Ethereum and Base is enforced by the rollup protocol itself — Base's state is defined by data posted to Ethereum, so the L1 does not need to be convinced of anything; it is the source of truth. The cost is patience on withdrawals. Third-party bridges sell you speed by reintroducing a trusted middleman, and that trade should be made knowingly or not at all.

On a chain with a public mempool, anyone can watch pending transactions and pay to jump ahead of them — the classic frontrun. Base's sequencer receives transactions privately and orders them roughly first-come-first-served, which removes the public auction that outside bots fed on.

What it does not remove is the position of the sequencer itself, which sees everything before anyone else. The discipline is reputational and contractual today, and verifiable tomorrow: research on encrypted mempools and commitments to ordering rules aims to turn "the operator promises fair ordering" into "the operator provably cannot reorder."

For the working analyst

When you see a sandwich-shaped pattern on an L2 — victim trade flanked by attacker trades — the suspect list is short in a way it never is on L1, and that is itself analytically useful. Ordering data on a single-sequencer chain is a statement signed, implicitly, by one party.

Compare the rails. Card networks settle merchant funds in days and take a percentage. International transfers route through correspondent banks with multi-day delays and opaque fees that fall hardest on the smallest senders. A stablecoin transfer on Base is final in seconds, costs a flat fraction of a cent, and the receipt is a public transaction anyone can verify.

The honest caveats matter as much as the pitch. Major fiat-backed stablecoins are issued by companies that can freeze addresses — the asset is censorable even where the chain is not, and any analysis of "unstoppable payments" that skips this is marketing. On- and off-ramps remain the chokepoints where the traditional system's rules reapply in full.

Why a journal covers payments

Because settlement is where blockchain claims meet measurable reality: speed, cost, and failure rates are all public data. Few subjects in this field allow such clean empirical work, and few are as consequential to people outside it.

On a conventional platform, your identity, your audience, and your archive are rows in a company's database. Leaving means starting from zero, which means almost nobody leaves, which means the platform's incentive to treat you well decays with its growth. Economists call the missing ingredient an exit option.

Onchain social inverts the ownership: the identity key and the follow graph belong to the user, and any client can read them. A platform that degrades can be abandoned without losing the audience — and crucially, the threat alone disciplines behavior, the same way the rarely-used force-inclusion hatch disciplines a sequencer.

The connection to publishing

A journal is a social object too: authors, readers, citations. Vossen's attestation-based records are portable for exactly the same reason a Farcaster graph is — if this website vanished tonight, every article, authorship claim, and citation would remain resolvable by anyone. Infrastructure you can leave is infrastructure that has to keep earning you.

At mainnet prices, developers batch, defer, and move logic off-chain; the chain is a settlement layer touched as rarely as possible. At Base prices, per-action designs become rational: games that record every move, apps that attest every event, journals that notarize every revision. The chain stops being the vault you visit and becomes the log you write to.

The new failure mode is symmetrical: spam is also a hundred times cheaper. Systems that treat "a transaction happened" as meaningful inherit a vulnerability, which is why reputation layers and stake requirements appear on L2s not as ideology but as engineering necessity.

A heuristic for builders

Price each user action at both L1 and L2 cost and ask which design each implies. If your architecture is identical at both price points, you are probably importing L1 caution into an environment that no longer requires it — or ignoring spam economics in one that punishes that.

An attestation containing a document hash establishes three facts to a high standard: that this exact sequence of bytes existed no later than the block timestamp; that a particular private key signed the commitment; and that the record has not been altered since. These are commitments of time, content, and key — nothing more.

Notice everything outside that boundary. The attestation does not prove the statements in the document are true. It does not prove the key's holder is who they claim to be, nor that the signer understood or consented to the content in any legally meaningful sense. "Proof of existence" is exactly that — existence, not validity.

Why the narrowness is a feature

Systems that overclaim get dismissed when the overclaim fails. A timestamped commitment is genuinely useful — for priority disputes, plagiarism cases, archival integrity — precisely because its guarantee is small enough to be airtight. Vossen describes its records in those narrow terms deliberately: we would rather our proofs be modest and unbreakable than impressive and contestable.

The seed phrase made one heroic assumption: that ordinary people can durably secure a high-entropy secret with no recovery path. A decade of drained wallets, lost fortunes, and phishing kits says otherwise. Security that humans cannot operate is not security; it is liability transfer.

The emerging stack replaces the single secret with device-bound passkeys (private keys living in a phone's secure hardware, unlocked by biometrics) wrapped in smart accounts that allow recovery: a guardian set, a time-delayed reset, a second device. No phrase to write down, nothing to phish with one paste.

The honest ledger of trade-offs

Recovery paths are attack paths — whoever can help you recover can, in some configuration, help an attacker too. Guardians can collude; platform-synced passkeys reintroduce a platform. The design question is not "is there a trusted party?" but "is the trust explicit, divided, and time-delayed enough to be survivable?" That is a better question than the seed phrase ever let us ask.

In 1991, Haber and Stornetta published a scheme for timestamping digital documents by chaining hashes — each certificate including the hash of the previous one, so backdating any record would require rewriting everything after it. Their company even published periodic hashes in a newspaper's classifieds, using print circulation as a tamper-evidence layer. If chained hashes plus public witness sounds familiar, it should: their papers are among the few citations in the Bitcoin whitepaper.

What Bitcoin added was not the chain but the incentive to maintain it — a decentralized set of parties paid to keep extending and guarding the history. Every subsequent step, from early proof-of-existence services to NFTs to the Ethereum Attestation Service, is a refinement in cost and expressiveness of the same 1991 idea.

Why the lineage matters

A Base attestation is a Haber–Stornetta timestamp with global witnesses and a fee measured in fractions of a cent. Recognizing the continuity is an inoculation against both hype and dismissal: the idea is older and sounder than its critics assume, and less novel than its promoters claim. Vossen is, in the most literal sense, a newspaper classifieds section that grew up.

The optimistic model posts state and opens a challenge window — typically seven days — during which anyone can submit a fraud proof demonstrating an invalid transition. Security rests on one honest watcher existing; the cost is the waiting period on withdrawals through the canonical bridge.

The validity model proves every state transition cryptographically before it is accepted. Nothing needs to be watched and exits are fast, but generating the proofs requires heavy computation, and the proving systems themselves are young, complex artifacts whose bugs are subtle in ways fraud-proof code is not.

The pragmatic reading

"One honest verifier in seven days" versus "this circuit and its implementation are correct" are different bets, not a ranking. The two families are also converging — optimistic stacks are adding validity proofs to shorten windows. For users of Base today, the seven-day window applies to the canonical bridge; for readers of Vossen, an attestation is final the moment its batch settles, because no one withdraws a fact.