Frequency primary sources

Reviewed: 2026-05-15 UTC

Whitepaper / top-level framing

  • https://docs.frequency.xyz/Whitepaper.html
    • Best concise primary framing for this pass.
    • Used to confirm Frequency’s positioning as a purpose-built Layer 1 for DSNP-style social networking, with message discovery, state storage, delegation, and an alternative economic model based on batching plus recurring capacity.

Durable authorship and user-account model

  • https://docs.frequency.xyz/Identity/MessageSourceAccounts.html
    • Best source for the MSA abstraction.
    • Used to confirm that Message Source Accounts persist separately from rotating control keys, require no existential deposit to remain on-chain, support coinless participation, and preserve message authorship even if user keys change.

Delegation model / coinless-user path

  • https://docs.frequency.xyz/Delegation/index.html
    • Best concise source for the basic delegation framing.
    • Used to confirm that Frequency shifts most cost and operational complexity from end users to Providers, while still allowing users to revoke delegation and optionally interact directly with the chain.
  • https://docs.frequency.xyz/Delegation/Mechanics.html
    • Best source for actual delegation semantics.
    • Used to confirm that delegations are mutual-consent, schema-scoped, public, and unilaterally revocable by either the user or the Provider.
  • https://docs.frequency.xyz/Delegation/Providers.html
    • Best source for Provider admission and permanence.
    • Used to confirm that Providers are MSA-backed application identities, that Mainnet registration is currently Frequency-Council-approved, and that Provider registrations are permanent so past delegation references remain verifiable.
  • https://docs.frequency.xyz/Delegation/Benefits.html
    • Helpful source for the intended user-experience rationale.
    • Used to confirm the explicit coinless users framing and the way Frequency positions low-friction onboarding against ordinary token-first blockchain UX.

Structured data and high-volume publishing path

  • https://docs.frequency.xyz/Data/Schemas.html
    • Best source for the schema system.
    • Used to confirm immutable schema IDs, the split between Messages and Stateful Storage, Parquet versus Avro model choices, and on-chain versus IPFS payload-location options.
  • https://docs.frequency.xyz/Data/Batching.html
    • Best source for the off-chain batching mechanism.
    • Used to confirm Parquet/IPFS-based Message Batching, on-chain pointers to large off-chain payload sets, fee and block-space reduction goals, and the explicit link between batching and the delegation model.

Economic control plane

  • https://docs.frequency.xyz/Tokenomics/CapacityStaking.html
    • Best source for the main stake-derived fee abstraction.
    • Used to confirm the provider-designated, non-transferable, renewable Capacity model; the initial 50:1 FRQCY-to-Capacity staking ratio; daily renewal epoch framing; and thaw-period anti-spam logic.
  • https://docs.frequency.xyz/Tokenomics/ProviderBoosting.html
    • Best source for the user-support and reputation layer.
    • Used to confirm that users can stake behind Providers, earn FRQCY rewards from chain issuance, redirect support without thawing, and generate both Capacity and an on-chain reputation signal for Providers.
  • https://docs.frequency.xyz/Tokenomics/InflationLiquidity.html
    • Best source for supply-side effects.
    • Used to confirm fee burning, Provider-Boosting inflation, staking-driven circulating-supply contraction, and the design claim that transaction activity can remain high even when liquid FRQCY supply falls because Capacity itself can pay many fees.

Main takeaways from this pass

  • Frequency is best understood as a social-data chain that separates durable authorship (MSAs), delegated application control (Providers), structured public data (Schemas), and recurring fee abstraction (Capacity).
  • The most distinctive mechanism is not merely gasless onboarding; it is the public, schema-scoped, revocable Provider-delegation system combined with Provider-specific Capacity allocations.
  • Provider Boosting adds a second useful layer by turning user staking into both a Provider support signal and an additional Capacity source, without making Providers directly pay those users.
  • The current system still has meaningful governance choke points, especially Provider admission on Mainnet through the Frequency Council.