FIP: Live Activity Status

[rishavmukherji]

Abstract

This proposal introduces a new UserDataType — USER_DATA_TYPE_LIVE_AT — that lets a user signal they are currently participating in a live activity (an audio space, a livestream, a broadcast event) by writing a single canonical URL to their identity. The slot is last-write-wins: an authorized signer writes the activity’s URL on join and clears it on leave. Clients read the slot to render presence wherever a user surfaces — profile, feed, avatar dot, in-feed strips, channel pages — without indexing per-provider.

The protocol delta is small:

• One new constant in the UserDataType enum.
• One added validation rule on the value.
• No new message type, no new store, no new permission model, no new RPC surface.

Motivation

App-agnostic live presence

Live audio rooms, video streams, and event broadcasts are an increasing share of activity on social networks, but there is no Farcaster protocol primitive for “this user is in a live experience right now.” Clients that support this today today (e.g. Juke) cannot surface presence in other Farcaster clients.

The right shape for this signal is a single bounded slot on the user’s identity — written by the app the user has authorized, read by every client without coordination, and small enough to be cheap to query alongside the rest of the user’s profile.

Why not existing primitives

• Cast with embeds: [{ url: spaceUrl }]. Posting a “live now” cast and removing it on end works, but it is ephemeral on the feed and mixes a property of the user with property of the cast. Clients have to read user’s casts to know whether the user is live.
• Link. LinkBody.target_fid is FID-only; the protocol has no URL-targeted link.

UserData already models “facts about the user that are true now” — pfp, bio, display name, location, twitter, github. “Currently live at” is a clean addition to that category and reuses every piece of machinery already in place: storage, signing, delegated keys, consensus, indexing, prune rules, and the public HTTP/gRPC read API.

Specification

New UserDataType value

enum UserDataType {
  USER_DATA_TYPE_NONE                          = 0;
  USER_DATA_TYPE_PFP                           = 1;
  USER_DATA_TYPE_DISPLAY                       = 2;
  USER_DATA_TYPE_BIO                           = 3;
  USER_DATA_TYPE_URL                           = 5;
  USER_DATA_TYPE_USERNAME                      = 6;
  USER_DATA_TYPE_LOCATION                      = 7;
  USER_DATA_TYPE_TWITTER                       = 8;
  USER_DATA_TYPE_GITHUB                        = 9;
  USER_DATA_TYPE_BANNER                        = 11;
  USER_DATA_TYPE_PRIMARY_ADDRESS_ETHEREUM      = 12;
  USER_DATA_TYPE_PRIMARY_ADDRESS_SOLANA        = 13;
  USER_DATA_TYPE_LIVE_AT                       = 14;  // NEW
  USER_DATA_TYPE_PROFILE_TOKEN                 = 15;
}

The wire format of UserDataAddBody { type, value } is unchanged. A user writes the slot by submitting a signed MESSAGE_TYPE_USER_DATA_ADD with type = USER_DATA_TYPE_LIVE_AT and value set to the canonical URL of the live activity. A user clears the slot by writing the same message with value = "".

LIVE_AT is activated by the Snapchain protocol feature gate LiveAt in engine version V17. Validators running a version before V17 reject USER_DATA_TYPE_LIVE_AT as unsupported.

Value format

The value field is a UTF-8 string subject to the following rules:

• Empty string ("") — semantic meaning “not currently live.” Clients must treat the empty string as equivalent to the field being unset.
• Non-empty string — the canonical URL for the live activity. Non-empty values MUST be valid https:// URLs. Hub/client validation helpers enforce URL parseability and the https: scheme; Snapchain consensus validation enforces the final protocol feature gate and the UserData byte-size bound.
• Length — bounded by the existing UserData value cap (256 bytes). Values exceeding 256 bytes are rejected at validation time.

Clients determine whether the URL refers to a live activity by resolving the URL — specifically by checking for Farcaster-specific meta tags (fc:live=1) and an optional signed manifest endpoint (see the companion FIP: Live Activity Manifest). Examples: https://broadcast.app/space/abc123 (audio session URL of a live activity), https://app.example/active (generic presence URL).

Last-write-wins semantics

Per existing UserData rules, only the winning USER_DATA_ADD for a given (fid, type) pair is retained. Ordering is last-write-wins by Farcaster message ordering: highest timestamp wins, and same-timestamp ties are broken by the lexicographically higher message hash. Clearing the slot is a write of value = "" that wins this ordering over the previous write. There is no USER_DATA_REMOVE; value = "" is the canonical “not live” state.

Liveness and freshness (off-protocol convention)

Snapchain has no native message-level TTL, and this proposal does not add one. The slot persists at its last-written value until overwritten or pruned. To approximate ephemeral semantics, this FIP specifies two off-protocol conventions:

1. Heartbeat from the writer. The application writing the slot on the user’s behalf MUST re-write the same value at a regular interval — RECOMMENDED every 1 second, MIN 1 second, MAX 5 seconds — for as long as the user is in the activity. Each rewrite advances the message timestamp on the slot.
2. Freshness check by the reader. Clients reading the slot SHOULD treat a LIVE_AT value as stale and not render it as “currently live” if the message timestamp is older than a freshness threshold — RECOMMENDED 10 seconds.

Clients that want to display “was live 3 hours ago” can ignore the freshness threshold and render historical data — the message timestamp is retained regardless.

Cooperative writing convention

Multiple apps may have permission to write LIVE_AT on the user’s behalf simultaneously (e.g., the user has Farcaster and Juke both authorized). To avoid wasted writes and lost activity URLs, apps writing LIVE_AT SHOULD follow this convention:

1. Before each scheduled write, read the user’s current LIVE_AT value and message timestamp.
2. If the slot is empty, or the message timestamp is older than the freshness threshold (RECOMMENDED 10 seconds, matching the reader-side rule), the app MAY write its own value (presence URL or activity URL).
3. If the slot is fresh and the URL was written by this app, the app SHOULD continue heartbeating to keep it fresh.
4. If the slot is fresh and the URL was written by a different writer:
   • Activity writers (apps reporting the user is in a specific live activity, identified by the URL serving fc:live=1 meta tags per the companion FIP) MAY still overwrite a presence-only URL, since activity is the more informative signal. Activity writes preempt presence writes.
   • Presence-only writers SHOULD NOT overwrite a fresh non-self URL — the user is already being represented as active by another writer, and there is nothing additional for a presence writer to contribute.

The net effect: one writer “owns” the slot at a time, activity writes preempt presence writes, and presence writers cooperatively yield when any writer is keeping the slot fresh. This also materially reduces LIVE_AT rate limit consumption — only one app heartbeats at a time, rather than every authorized app writing in parallel.

Risk: misbehaving clients. This convention is a SHOULD, not a MUST — the protocol cannot enforce it. A client that ignores the convention and heartbeats unconditionally will clobber activity URLs the user is trying to surface (for example, a presence-only app overwriting an audio space URL, making the space disappear from LIVE_AT-driven render surfaces despite the user still being in it). The mitigation is social: users will notice when a live activity they are participating in disappears from feeds and avatar pills, identify the misbehaving client as the cause, and either ask that client to fix it or stop using it. Apps that consistently violate the convention pay an organic UX cost.

Single-valued

The slot holds exactly one URL. A user simultaneously present in two live activities writes the URL of whichever they want to surface; the URL’s manifest can declare cross-posting if relevant. The protocol does not model multi-activity presence. This also models human behavior where humans are unlikely to be live in two places at the same time. If agent behavior is different in the future, this can be modified as needed.

Validation flow

A MESSAGE_TYPE_USER_DATA_ADD with type = USER_DATA_TYPE_LIVE_AT is validated identically to other UserData writes, with the following additional semantics:

1. Verify the LiveAt protocol feature is active (EngineVersion::V17 or later). Reject as unsupported before activation.
2. Verify len(value) <= 256 bytes and that value is valid UTF-8 as required for UserData strings.
3. If value == "", accept as the canonical clear/not-live value (subject to existing UserData rules).
4. If value != "", hub/client validation helpers MUST require a parseable URL with scheme https:.
5. Apply existing UserData write rules (signature, FID validity, signer authorization, storage limits).

No fetching, no URL scheme allowlist beyond https:, and no manifest validation is performed as part of message validation.

Storage and pruning

The slot occupies one record in the per-FID UserData store. The default storage unit allots approximately 800 UserData records across all UserDataType values combined; under last-write-wins semantics, repeated writes to LIVE_AT overwrite in place rather than accumulating, so steady-state cost is one record per active UserDataType regardless of write frequency.

This proposal does not change UserData storage limits.

Rate limit

USER_DATA_TYPE_LIVE_AT writes have a separate rate limit budget from the existing per-FID general message budget. LIVE_AT writes do not count against the general budget, and other writes do not count against the LIVE_AT budget. This separate budget is sized to support the recommended 1-second heartbeat without consuming the user’s general tx budget.

The implemented budget is 5000 writes/hour per storage unit for LIVE_AT, using the user's current storage-unit count. A user with zero storage units has zero LIVE_AT budget and their LIVE_AT writes are rejected by the mempool rate limiter. Storage changes invalidate the cached LIVE_AT limiter for that FID so quota reflects the updated storage-unit count.

This is the one protocol-level rate-limit change required by this FIP. Without it, a single live user heartbeating every second would exhaust their entire general tx budget within ~8 minutes of being live, blocking casts and other writes for the rest of the hour.

Client interpretation

Clients reading LIVE_AT interpret it at two fidelities:

• Presence (green dot, online indicator). A non-empty value whose message timestamp is within the freshness window means the user is currently active on Farcaster. No URL fetch is required for this render. The semantic is “this user is reachable right now,” and it is true regardless of which app or activity is writing the slot. Surfaces like DM lists, contact rosters, and profile pills typically need only this.
• Activity (rich card, in-feed strip, app pill). Clients that want to render what the user is doing resolve the URL using the contract defined in the companion FIP: Live Activity Manifest: the URL is the audio session location, served by the activity provider, with Farcaster-specific meta tags (fc:live=1, fc:live:hostFid, etc.) carrying dynamic state. The host's identity is bound to the URL by a JFS signature served at a manifest endpoint linked from the URL; trust-sensitive surfaces verify it. Chat is the reply tree of a cast referenced by the URL's fc:cast meta tag.

Clients SHOULD combine the lifecycle signals from the URL's meta tags (e.g., fc:live:endedAt) with the message-level freshness rule above and treat the slot as stale if either signal indicates the activity has ended.

The URL written to LIVE_AT does not have to be a live activity URL. An app reporting a user as merely active can write any URL it controls; clients will still light the green dot from freshness alone. The richer activity render only kicks in when the URL serves the meta tags + manifest contract.

The protocol FIP and the activity FIP are independent. LIVE_AT can ship before the activity contract is finalized; the activity contract can ship later or in parallel without revisiting this protocol-level change.

Design rationale: an opaque URL, not a structured payload

The slot value is intentionally a single URL with no companion fields — no LIVE_KIND to declare activity type (audio / video / event), no LIVE_TITLE, no LIVE_HOST_FID, no listener count. Everything beyond “where” is delegated to the resource the URL points to (an OG-style manifest, a Frame, or any HTTP response the client can dereference). This is a load-bearing design choice and an explicit non-goal to expand:

• Single source of truth. A second slot — LIVE_KIND, say — must be kept in sync with LIVE_AT under independent last-write-wins semantics per UserDataType. Interleaved or partial writes produce inconsistent states (a user with LIVE_AT = audio-room-url and LIVE_KIND = video) that the protocol has no way to reconcile.
• Manifest fetches are required regardless. Every meaningful render surface — in-feed strip, profile card, avatar pill, channel page — wants more than a category: title, host, listener count, art. The client is going to fetch the URL anyway. Pulling a single field (kind) into a protocol slot saves zero round-trips while doubling protocol surface area.
• Premature taxonomy. Hard-coding audio / video / event into a protocol enum locks the network into today’s view of “kinds of live experiences.” Listening parties, live coding, AR sessions, classroom sessions, gameshows, watch-alongs — each new category would require a FIP and a validator upgrade. The URL’s manifest evolves at app speed without protocol coordination.

If a future use case genuinely cannot be served by the URL+manifest pattern, that is a strong signal to reopen this design at that time.

Discoverability (informative)

Live activities are identified by the audio session URL — see the companion FIP: Live Activity Manifest for the meta tags, signed manifest, and cast conventions that make it renderable. LIVE_AT points at this audio URL; speakers and listeners share the same value.

Chat is the reply tree of a cast (created by the host's client when the activity starts) that references the audio URL as an embed. The audio URL's fc:cast meta tag points back at this cast. Space chat behaves like normal replies, naturally placed in whatever social context the cast lives in (channel, thread, top-level feed).

Implementation in Snapchain

Key changes

• Add USER_DATA_TYPE_LIVE_AT = 10 to the UserDataType enum in the protobuf schema.
• Extend the UserData validation path: when type == USER_DATA_TYPE_LIVE_AT and value != "", parse value as a URI and reject on failure.
• Index UserData records by (type, fid) as today; no new index required.
• Surface the new type through the existing UserData HTTP and gRPC read endpoints alongside pfp, bio, etc.
• Implement a separate rate limit budget for MESSAGE_TYPE_USER_DATA_ADD writes with type == USER_DATA_TYPE_LIVE_AT (RECOMMENDED 5000/hour per storage unit), independent of the general per-FID rate limit.

What doesn’t change

• No new message type.
• No new store, no new prune rules.
• No new gRPC or HTTP endpoint.
• No change to delegated signer permissions; an app key already authorized for MESSAGE_TYPE_USER_DATA_ADD can write LIVE_AT. Granular per-UserDataType permissions are out of scope here and can be found in this [FIP separately](FIP: Snapchain Signers #266).

Performance

The change adds one enum value, one validation branch, and a separate rate limit budget for LIVE_AT writes. Validation cost is negligible; the meaningful cost is the throughput supported by the new rate limit. With 1-second heartbeats, a single active live user produces ~3600 writes/hour, so validator capacity scales with the number of concurrent live users on the network. Pruning behavior is unchanged — under last-write-wins, repeated LIVE_AT writes overwrite in place rather than accumulating storage.

Privacy Considerations

Disclosure is opt-in

Writing LIVE_AT is a deliberate act by the user — directly or via an app key the user has authorized. Apps SHOULD NOT write LIVE_AT for token-gated, private, or otherwise non-public activities unless the user has explicitly opted in.

Backwards Compatibility

This is an additive change. Clients unaware of USER_DATA_TYPE_LIVE_AT = 14 receive the record from existing UserData APIs and either ignore it or render the raw value as a string of unknown type. No existing message becomes invalid; no existing field changes shape.

Adoption requires a coordinated Snapchain release that recognizes the new UserDataType value in the validation path. Validator nodes running an older release, or running before the LiveAt protocol feature is active in engine version V17, reject USER_DATA_ADD messages carrying USER_DATA_TYPE_LIVE_AT as invalid/unsupported. Once a release containing this change is adopted across the validator set and the feature is active, blocks proposed under the new rules are accepted by the upgraded quorum and the new type flows through the existing UserData read APIs. The upgrade path is the same as for any prior protobuf enum addition (e.g., LOCATION, TWITTER, GITHUB).

References

• Snapchain whitepaper- consensus, storage units, pruning model
• UserData API reference - current UserDataType enum
• Messages datatype reference - MESSAGE_TYPE_USER_DATA_ADD spec
• Discussion #266: Snapchain Signers - FIP authoring conventions

[CryptoExplor]

Excellent proposal — the protocol-level approach to live presence is exactly right. A few thoughts on the design and some edge cases to consider:

Strong Points

1. Minimal protocol surface area:
The "one new enum value, one validation rule" approach is perfect. Reusing UserData semantics (last-write-wins, existing storage model) avoids adding complexity while enabling a powerful new primitive.

2. Separation of concerns:
Keeping the protocol layer opaque (just a URL) and delegating rich metadata to the manifest pattern (FIP #269) is the right abstraction. This prevents protocol lock-in to today's "audio/video/event" taxonomy.

3. Cooperative write convention:
The activity-preempts-presence rule is smart — it naturally prioritizes the more informative signal without requiring protocol enforcement.

Edge Cases & Considerations

1. Heartbeat Failure During Long Sessions

If a user is in a 3-hour audio space and their client loses network connectivity for 10 seconds (exceeds freshness threshold), their presence disappears from all clients even though they're still in the space. When they reconnect:

• Current proposal: Client re-writes LIVE_AT on reconnect, presence reappears
• Risk: Intermittent connectivity (mobile networks, spotty WiFi) causes frequent presence flicker

Suggestion: Consider a client-side grace period where readers don't immediately hide presence when freshness lapses — e.g., show a "connection unstable" indicator for 10-15 seconds before fully removing presence. This is an off-protocol convention but worth documenting.

2. Rate Limit Budget Contention

The 5000 writes/hour budget supports 1-second heartbeats (~3600/hour) with headroom. But if a user is simultaneously:

• In a live space (1/sec heartbeat)
• Using a presence-aware client (1/sec background heartbeat)
• Has multiple devices authorized (each heartbeating independently)

They could hit the budget ceiling. The cooperative write convention mitigates this, but only if all clients follow the SHOULD guidance.

Suggestion: The rate limit budget should be per-storage-unit (as proposed) but also document that clients SHOULD implement exponential backoff if they receive rate-limit rejections, rather than retrying at a fixed 1-second cadence.

3. URL Validation: HTTP vs HTTPS Redirect Chains

The spec requires https:// URLs. But what if:

• User writes https://space.example/abc
• That URL 301-redirects to http://legacy.example/abc (downgrade)

Current validation: Protocol only validates parseability and https scheme at write time — no fetch, no redirect following.

Risk: A client resolving the URL for activity metadata could hit an insecure redirect chain, potentially leaking the user's request to an HTTP intermediary.

Suggestion: Document that clients SHOULD refuse to follow redirect chains that downgrade from https to http, and SHOULD NOT render activity metadata if the final resolved URL is not HTTPS.

4. Empty String Semantics & Zombie Presence

The spec states value = "" is canonical "not live." But there's a race condition:

1. User joins a space → app writes LIVE_AT = "https://space.app/xyz"
2. User's app crashes before they explicitly leave
3. App never writes value = "" to clear presence
4. User's LIVE_AT persists indefinitely (or until pruned)

The freshness check (5 seconds) prevents zombie presence from being rendered, but the data persists on-chain.

Mitigation already in place: Heartbeat requirement + freshness check means stale presence naturally becomes invisible.
Potential enhancement: Clients could show "last active" timestamps for stale LIVE_AT values (e.g., "was live 2 hours ago"), similar to Discord's offline-with-timestamp.

5. Multi-Device Scenario: User in Space on Desktop, Browsing on Mobile

User is:

• Desktop: In a live audio space (app heartbeating LIVE_AT)
• Mobile: Browsing Farcaster feed (not in any live activity)

Both devices have authorized signers. If mobile client is presence-aware and wants to report "online but not in activity," it would write a presence-only URL. But per the cooperative convention, presence writers SHOULD NOT overwrite a fresh activity URL.

Result: Mobile client suppresses its heartbeat, desktop's activity signal is preserved. ✅ This works correctly.

Edge case: What if the desktop app crashes (stops heartbeating) while user is still browsing on mobile? After 5 seconds, the activity signal goes stale. Mobile client could then write its presence-only URL — but the user might not be aware the desktop signal died.

Suggestion: Clients could expose a "currently live on another device" indicator when they detect a fresh LIVE_AT they didn't write, so users can manually clear stale activity if needed.

Implementation Notes

Storage Pruning & Historical Queries

The proposal states LIVE_AT overwrites in place, so no storage accumulation. But hub operators might want to surface "user was live N times in the past 7 days" analytics.

Question: Will hubs retain historical LIVE_AT writes in prune-protected storage (like they do for cast deletion tracking)? Or is the expectation that analytics layers query real-time and cache externally?

Suggestion: Document that historical live activity tracking is out of scope for the protocol layer — apps/indexers that want "user was live 5 times this week" should cache this data off-chain.

---

Alignment with Companion FIP #269

The URL + manifest pattern is the right design, but the two FIPs have a tight dependency:

• FIP FIP: Live Activity Status #268 (this one): Ships the protocol primitive (USER_DATA_TYPE_LIVE_AT)
• FIP FIP: Live Activity Manifest #269 (manifest): Ships the contract for URL resolution (meta tags, signed manifests)

Deployment sequencing:
You noted these can ship independently. But in practice:

1. If FIP: Live Activity Status #268 ships first, clients can write LIVE_AT but have no standard way to resolve URLs → fragmented implementations
2. If FIP: Live Activity Manifest #269 ships first, there's no protocol slot to write to → no adoption

Suggestion: Coordinate a simultaneous activation (same Snapchain release) or at minimum, publish both FIPs together so client implementers can build against the full stack.

---

tl;dr: This is a minimal, well-scoped FIP that reuses existing protocol machinery elegantly. The edge cases above are mostly client-side concerns (grace periods, rate limit backoff) that don't require protocol changes — just documentation in implementation guides. Strong support for shipping this.

[basetrackxyz]

FIP: Agent Access Payment Protocol (AAPP)

Author: presdency.eth (FID 1079922)
Status: Draft
Category: Agent Infrastructure
Created: 2026-05-06

---

Abstract

This proposal introduces a standard for autonomous AI agent access to gated web resources via microtransactions on Base. An agent encounters a paywall, pays a fixed microfee (e.g. $0.01 USDC) to a site-controlled wallet, receives a signed access token, and proceeds — with no human input required. This turns the open web into a permissionless economy where sites earn passively and agents operate freely.

The protocol delta is small:

• One new interaction pattern for agents: detect → pay → access
• One new signing standard for sites: publish payment requirements in a manifest
• No new message type, no new store, no new permission model on Farcaster
• No API keys, subscriptions, or human approval steps

---

Motivation

Agents can't access the web autonomously

AI agents are increasingly operating on behalf of humans — reading content, pulling data, executing tasks. But the moment they hit a paywalled or gated resource, they stop. They have no native mechanism to pay and proceed.

Current workarounds:

• Pre-loaded API keys — requires human setup per site, doesn't scale
• OAuth/session auth — built for humans, not machines
• Scraping — violates ToS, bypasses site revenue entirely
• Skipping the resource — agents return incomplete results

There is no primitive today for: "this agent needs access, it will pay for it now, autonomously."

Sites have no passive income layer for agent traffic

Agent traffic is already a significant and growing share of web requests. Sites currently earn nothing from it — agents don't click ads, don't subscribe, don't convert. They just consume bandwidth and return nothing.

AAPP gives every website owner a revenue stream from agent traffic with zero integration overhead.

The right shape for this

The solution is a single bounded interaction — a payment manifest that sites publish, and a payment flow that agents execute. Small enough to be cheap. Fast enough to be invisible. Open enough to be permissionless.

---

Why Not Existing Primitives

• x402 Protocol (Coinbase): x402 is the foundational inspiration and infrastructure for this proposal. AAPP builds on top of x402 but extends it specifically for the Farcaster agent ecosystem — adding identity binding (FID), cast-level attribution, and a Farcaster-native manifest format so agents operating within the Farcaster graph can carry verifiable identity into web access flows.

• API Keys: Static, human-managed, per-site. Cannot scale to thousands of sites an agent may need to access dynamically.

• Subscriptions: Designed for recurring human access. An agent accessing a resource once per task doesn't need a monthly subscription.

• Free tiers: Sites cannot sustainably support agent-scale traffic for free. Agents make far more requests than humans.

---

Specification

Site Manifest: /.well-known/agent-access.json

Every site that supports AAPP publishes a manifest at a standard path:

{
  "version": "1.0",
  "payment": {
    "amount": "0.01",
    "currency": "USDC",
    "network": "base",
    "recipient": "0xSITE_WALLET_ADDRESS"
  },
  "access": {
    "duration_seconds": 3600,
    "scope": "read"
  },
  "manifest_signed_by": "0xSITE_SIGNING_KEY"
}

Agent Flow

1. Agent requests resource
2. Server returns HTTP 402 + manifest URL
3. Agent fetches /.well-known/agent-access.json
4. Agent constructs USDC transfer on Base
5. Agent submits payment + signed FID proof
6. Site verifies payment onchain (or via facilitator)
7. Site returns signed access token (JWT or signed hash)
8. Agent accesses resource with token in header

Agent Identity Header

Agents operating within Farcaster carry their FID as identity:

X-Agent-FID: 1079922
X-Agent-Sig: <EIP-712 signed payload>
X-Payment-Tx: <Base transaction hash>

This allows sites to:

• Attribute traffic to specific agents/operators
• Build reputation layers for agents
• Offer tiered pricing based on agent trust score

Access Token Format

Sites return a minimal signed token:

{
  "granted_to_fid": 1079922,
  "resource": "https://site.com/resource",
  "expires_at": 1746000000,
  "tx": "0xPAYMENT_TX_HASH",
  "sig": "0xSITE_SIG"
}

Token is passed in subsequent requests:

Authorization: Bearer <access_token>

---

Value Format

• Amount: Any positive USDC value. Suggested floor: $0.001. Suggested standard: $0.01.
• Duration: Access window in seconds. Sites set this. Agents cache tokens and reuse within window.
• Scope: read, write, or full. Sites define what each scope permits.

---

Facilitator Option

Sites that don't want to run blockchain infrastructure can delegate verification to a facilitator:

{
  "facilitator": "https://facilitator.praxisprotocol.xyz/verify"
}

The facilitator verifies the payment onchain and returns a signed confirmation. Site trusts the facilitator. This mirrors x402's facilitator design.

Praxis Protocol will operate an open facilitator on Base for any site to use — free tier for the first 1,000 verifications/month.

---

Agent Operator Responsibilities

Agents operating on behalf of users:

• MUST disclose their FID when making paid requests
• MUST NOT share access tokens across different agents or users
• SHOULD cache tokens for the full duration before re-paying
• SHOULD report failed verifications to the facilitator

---

Economics

Actor	Action	Outcome
Site owner	Publishes manifest	Earns USDC per agent visit
Agent operator	Pays per access	Gets content without human auth
Facilitator	Verifies payments	Earns small % fee
End user	None required	Agent completes task autonomously

At 1 million agent calls per day across the ecosystem at $0.01 each:

• $10,000/day flows to site owners
• Facilitator at 1% = $100/day in protocol revenue

---

Security Considerations

• Replay attacks: Access tokens are bound to a specific tx hash. Reusing a token requires reusing the transaction — impossible.
• Token theft: Tokens are FID-bound. A stolen token from FID A cannot be used by FID B without a valid signature.
• Overpayment: Manifests specify exact amounts. Agents should reject manifests requesting unusually high amounts before paying.
• Fake manifests: Agents should verify manifest_signed_by against the site's onchain identity before paying.

---

Open Questions

1. Should access tokens be revocable mid-duration if site detects abuse?
2. Should the protocol support streaming payments (pay-per-request within a session) or only session-level access?
3. Should FID be required or optional for agents not operating within Farcaster?
4. Who audits facilitators? Is a facilitator registry needed?

---

References

• x402 Protocol — Coinbase
• EIP-3009: Transfer With Authorization
• FIP #268: Live Activity Status
• Praxis Protocol — Base

---

Copyright

This FIP is released into the public domain under CC0.

[rishavmukherji]

comments are not for introducing new FIPs. create a new FIP as a new discussion as needed. comments are for giving feedback on the current FIP.

[i001962]

How about USER_DATA_TYPE_CURRENTLY instead of LIVE_AT

Covers cases like 'is away', 'is watching', 'is crying over spilled milk', 'is flying to farcon'

[rishavmukherji]

Interesting idea. Thought about this but don't think it's the right call. If you think of MSN Messenger or Slack style apps - the green presence dot and the status message are different fields. Conflating them increases complexity where you have to infer green available state on a client from the status message which can be quite non trivial.

This FIP is for the green dot equivalent indicator which shows your presence / live status. We could have a separate FIP in the future for a status field that does what you're asking above

[schoolkamsergj]

Hey! I'm a Base L2 game developer working on Base Invaders (Phaser 3 + Base mainnet) and wanted to share a real-world use case for live activity from a game dev perspective.

With the new Farcaster Snaps, I built an example showing how on-chain game devs can:

Embed a "Play Now" button directly inside a Farcaster cast via a Snap endpoint

Pass Farcaster FID to Base MiniKit on Snap load

Trigger a Base mainnet transaction (start game session, mint score NFT) from the cast

Display results back inside the cast

Full working example (PR): builders-garden/base-minikit-starter#1

How this connects to FIP #268 (live activity):
For real-time games we need the cast to stay "alive" — updating scores, reacting to on-chain events. Live activity would allow:

A game session Snap that updates in real-time as players submit scores on-chain

Cross-client support (Warpcast, Juke, etc.) for game tournaments happening on Base

Would love feedback on whether the current proposal covers on-chain game session use cases, or if there are specific fields to consider for transaction-driven live updates.

[rishavmukherji]

Two updates to the FIP, noting here so it's clear when they were made

1. "The URL validation happens at the client layer, same as USER_DATA_TYPE_URL." - was missing earlier, added
2. "freshness threshold — RECOMMENDED 10 seconds." - this was 5s earlier, updated to 10s

[schoolkamsergj]

Thanks for the updates! The 10s freshness threshold makes more sense for on-chain use cases — game sessions on Base can have block confirmation delays, so 5s would've been too tight. Good to see URL validation staying at the client layer too, that keeps the Snap integration flexible

[tybook]

Snapchain implementation: farcasterxyz/snapchain#899

[tybook]

Updated the FIP text to match the implementation that has now landed:

• Changed the final enum value to USER_DATA_TYPE_LIVE_AT = 14.
• Added the Snapchain LiveAt protocol feature gate / EngineVersion::V17 activation semantics.
• Clarified LIVE_AT last-write-wins ordering as timestamp plus message-hash tiebreaking for same-timestamp writes.
• Clarified validation semantics: empty string clears the slot, values are bounded to 256 bytes, non-empty values are expected to be parseable https: URLs by hub/client validation helpers, and message validation does not fetch URLs or validate manifests.
• Updated the dedicated LIVE_AT rate-limit section to the implemented budget: 5000 writes/hour/storage-unit, with zero storage units rejected and storage changes invalidating cached LIVE_AT limiters.
• Updated backwards-compatibility wording to refer to enum value 14 and pre-V17 unsupported behavior.