Frequency

Deep Dive into the Technology Behind Frequency

Expand your expertise and master the Frequency blockchain. Whether you're a beginner or an experienced developer, our resources will guide you through the intricacies of the Frequency Ecosystem. Gain the skills you need to innovate and build the next generation of decentralized applications.

Begin Your Learning Journey

Become a Provider Frequency Developer Gateway Single Sign-on Frequency Core

.01

Become a Provider

What is a Provider?

In the Frequency ecosystem, a Provider is an entity (often an application or service) that interacts directly with the Frequency blockchain on behalf of users. Providers handle transactions, manage user delegations, and facilitate various operations within the Frequency Ecosystem.

From a Developer's Perspective, Providers

Manage Delegated Tasks: Users delegate specific permissions to Providers, allowing them to perform only those specified actions on the user's behalf in a secure and transparent manner.
Create and Update User-Generated Content with Permission: Providers publish new content or modify existing content on behalf of users, such as posts, comments, and other social interactions, after obtaining the user's consent.
Maintain the User's Social Graph: Providers manage and update users' social connections on Frequency, (based on a user’s direction and consent) such as following or unfollowing other users, and maintaining friend lists. These actions ensure that the user's relationships are accurately represented on the blockchain.
Store User-Generated Content and Write Links to It on Frequency: Providers store user-generated content files (e.g., media files, documents) and publish links to the content on chain or batched metadata in The InterPlanetary File Service (IPFS). This enables decentralized access and verification. Providers have many options for user-generated content file storage including decentralized storage like IPFS.
Simplify User Participation: By handling transaction complexities and fees, Providers make blockchain applications more accessible to end-users who may not possess sufficient technical knowledge or hold tokens.
Enhance User Experience: Providers may offer intuitive user interfaces and seamless interactions, so users don’t need to experience or understand the underlying blockchain mechanics.

How You Can Become a Provider

Step 1: Generate Your Keys

There are various wallets that can generate and secure Frequency compatible keys, including:

This onboarding process will guide you through the creation of an account and the creation of a Provider Account which will be required for many different transactions.

Step 2: Acquire Testnet Tokens

Taking the account generated in Step 1, visit the Frequency Testnet Faucet, and follow the prompts to get Testnet tokens (called XRQCY tokens).

Step 3: Create a Testnet Provider

Visit the Provider Dashboard to set up your official Provider account on the Frequency Testnet.
On the Provider Dashboard, you will be asked to select which network you would like to join from the dropdown. You may select among the available networks: Mainnet, Testnet on Paseo, Localhost, or Custom. Select Testnet on Paseo.
Select your account Id from the dropdown. (This is the Application Account you created in Step 1.)
Select Create an MSA and approve the transaction popups.
Enter a Provider name. You should enter the name you wish register under as a Provider (typically a company or application name).

NOTE: Once registered as a Provider, your Provider MSA Id can not be removed from the chain in order to maintain transaction verification integrity.

Step 4: Gain Capacity

Capacity is the ability to perform some transactions on Frequency without token cost. All interactions with the chain that an application does on behalf of a user can be done with Capacity.

Step 5: Done

You are now registered as a Provider on Testnet and have Capacity to do things like support users with Single Sign On.

You can also use the Provider Dashboard to add additional Provider Account Control Keys for safety.

Ready to move to production? Become a Provider on Mainnet.

Become a Provider Today

.02

Frequency Developer Gateway

Why Frequency Developer Gateway?

Frequency Developer Gateway provides simple blockchain integration for your applications–bridging the gap between your app and the decentralized web.

Gateway offers a suite of tools and services hosted by you that make it easy to connect your applications to the Frequency blockchain. This allows your development team to focus on building outstanding user experiences without managing the complexity of blockchain interactions.

What is Frequency Developer Gateway?

Frequency Developer Gateway has a simple API to interact with the Frequency social layers (including identity, Universal Social Graph, user-generated content, and more). It includes a suite of self-hosted tools you can select from to build the best applications for your users.

Key Features:

Decentralize with Web2 API Simplicity:

Build Your Applications Faster: Accelerate development with familiar Web2 tools and interfaces.
Own Your Infrastructure: Deploy and manage your own services for greater control and customization.
OpenAPI/Swagger Out of the Box: Utilize comprehensive documentation and standardized API definitions for seamless integration.
Automated Deployment with Docker: Deploy services quickly using optimized Docker containers.

Customize for your users:

Add Authentication and Onboarding Workflows: Integrate secure user authentication with ease.
Connect Your Users with Their Universal Social Graph: Access and manage user relationships across the Frequency Ecosystem.
Read, Write, and Interact with Social Media Content: Enable rich social interactions within your application.

How Can I Integrate Frequency Developer Gateway?

Frequency Developer Gateway is composed of independent, self-hosted, standalone microservices, allowing you to use only those components you need. These microservices include simple APIs for interacting with various aspects of the Frequency Ecosystem.

Key Microservices:

1. Account Service

The Account Service enables easy interaction with accounts on Frequency. Accounts are defined with an msaId (64-bit identifier) and can contain additional information such as a handle, keys, and more.

Account Service Docs

Features:

Account Authentication and Single Sign-On: Simplifies user onboarding with Sign-In with Frequency (SIWF).
Delegation Management: Manages permissions and actions delegated by users.
User Handle Creation and Retrieval: Creates and manages unique, user-selected user handles on Frequency.
User Key Retrieval and Management: Accesses and securely manages user cryptographic keys.

The Graph Service enables easy interaction with social graphs on Frequency. Each graph connection can be private or public and can be unidirectional (a follow) or bidirectional (mutually opted-in friend connection).

Social Graph Service Docs

Features:

Fetch User Graph: Retrieves a user's social connections and relationships.
Update Delegated User Graphs: Modifies social graphs on behalf of users with their permission.
Watch Graphs for External Updates: Monitors changes in the Frequency Ecosystem to keep user data up to date in your application.

3. Content Publishing Service

The Content Publishing Service enables the creation of new content-related activities on Frequency. Content metadata is either published to Frequency or linked to content metadata in IPFS. User-generated content can be stored using IPFS or other systems.

Content Publishing Service Docs

Features:

Create Posts to Publicly Broadcast: Publishes links to content metadata to the chain.
Create Replies to Posts: Facilitates conversations by allowing users to publish responses to user-generated content.
Create Reactions to Posts: Enables users to react to user-generated content.
Create Updates to Existing Content: Modifies or enhances previously published user-generated content.
Request Deletion of Content: Manages the content lifecycle by publishing lists of content identifiers that the Frequency Ecosystem should delete.
Store and Attach Media with IPFS: Allows Provider to utilize InterPlanetary File System (IPFS) links for decentralized media storage.

4. Content Watcher Service

The Content Watcher Service helps your application process content from the Frequency Ecosystem by registering webhooks that are triggered when relevant activity is found on Frequency.

Content Watcher Service Docs

Features:

Parse and Validate Frequency Content: Ensures content is well formed and complies with network standards.
Filterable Webhooks: Receive notifications based on specific filters.
Scanning Control: Manage how and when the service scans Frequency.

Start Using Frequency Developer Gateway

.03

Sign-in With Frequency (SIWF) allows Providers to enhance their apps with secure Identity by integrating seamless and secure user authentication. With (SIWF), Providers can present their users with an identity solution that puts them in control of their data, thus enhancing trust and security within the app while embracing the future of user authentication.

Sign-in With Frequency (SIWF) provides tools and documentation to integrate an easy-to-use single sign-on identity solution for users of Frequency, currently supporting Frequency Access for key management. SIWF simplifies the authentication process, allowing users to access the entire Frequency ecosystem effortlessly while maintaining control over their personal data.

By leveraging Frequency Access, Providers can offer users a seamless experience, making it easier for consumers to engage with applications without confronting the complexities of blockchain technology. Additionally, developers benefit by receiving verified emails, enhancing security and trust within your application.

Key Features

Easy Integration:

Utilize developer-friendly documentation and tools to quickly add SIWF to your applications.
SIWF streamlines the setup process, allowing Providers to integrate authentication and identity management with minimal effort.

Secure Authentication:

SIWF works with Frequency Access to verify users and manages the signing of requested payloads, ensuring a secure authentication process.
Developers can receive emails that Frequency Access has previously verified to enhance communication and security within their applications.

Universal Identity and Authentication:

Offers users a familiar and standardized sign-in experience with a consistent sign-in button.
Allows users to effortlessly claim their user handle and establish their unique identity across the Frequency ecosystem.

User Control:

Ensures users maintain control over their own data as they grant specific delegations and credentials to providers.
Provides transparency and trust between applications and their users.

Reduced Onboarding Friction:

Offers a familiar sign-in process that allows users to effortlessly take control of their accounts.
Reduces barriers to entry, encouraging more users to engage with your application.

Integrate SIWF with Your App

.04

Frequency Core

Frequency is a purpose-built Layer 1 public blockchain designed to fulfill the promise of the Decentralized Social Networking Protocol (DSNP). Frequency delivers essential infrastructure to create the next generation of social networking apps that give individuals more control over their data and agency to participate in the evolving digital economy. It provides scalable message discovery designed to operate at global scale, flexible state storage that can be used for social graph and identity data, and includes primitives for cost-shifting and delegation of authority that allow applications to provide familiar and intuitive user experiences to their audiences while maintaining control of their personal data and online relationships. In addition to token-based transactions, it provides an alternative economic model based on Message Batching and staking tokens for recurring network capacity. These approaches are extensible to other protocols that may have similar needs in the future. The native coin for Frequency is named FRQCY.

This section provides a detailed description of Frequency, the core data structures and operational primitives it supports, and the different ways that users and applications can interact with and transact with the system.

Architecture Identity Management Data Management Delegation Model Tokenomics Governance Glossary

Architecture

Frequency is a Layer 1 blockchain built to support high volume, data-driven applications within a decentralized environment. This section outlines the core components that make up Frequency and the ecosystem in which it operates.

Operational Model Interaction Model Collators Relay Chain

Operational Model

Like most Layer 1 blockchains, Frequency stores chain state and conducts data processing and state transitions on nodes, servers that participate in the Frequency network. Nodes can be configured in different ways depending on their purpose and use cases. These nodes communicate with one another to maintain shared state and contribute to the mempool, the queue of submitted transactions that are available to use to produce blocks. Nodes that form blocks are referred to as Collator Nodes.

Depending on its configuration, an individual node may play various roles. Full nodes maintain the full state of the chain. Light client nodes enable applications (including browser-based applications) to observe all chain events. Archive nodes retain the full history of the state of the chain for all blocks.

The core logic for Frequency is encapsulated in the Frequency Runtime, and uses platform-independent WebAssembly (Wasm) code. Each node runs the same version of the Frequency Runtime, the state transition function of the blockchain. The Frequency Runtime can be upgraded with new functionality or changes as approved by Frequency Governance. The Frequency Runtime defines the set of extrinsics (transaction types) that the blockchain is capable of processing, the types of events those transactions represent, and the format and data structures that constitute the blockchain's state. Each node also runs a copy of the current Relay Chain Runtime WASM, for coordination and interaction with the Polkadot Relay Chain.

Like many blockchains, there are multiple deployments of Frequency. The production system, referred to as Mainnet, uses the validators of the production Polkadot Relay Chain. A separate system for testing and development known as Testnet uses validators on the Paseo Relay Chain for testnets. Data and state on Frequency Mainnet is considered canonical, while data and state on Frequency Testnet is for testing purposes only.

Changes to the Frequency Runtime are typically deployed to Testnet before being submitted to Frequency Governance as upgrade proposals for Mainnet. For the most part, functionality is identical between the two systems (except for new changes on Testnet that are not yet deployed on Mainnet), aside from a few changes that make Testnet simpler to work with for development. Where there are different behaviors on Testnet versus Mainnet, they are noted in the description.

Interaction Model

Frequency Nodes have several points of interaction, including extrinsics, State Queries, Runtime APIs, and Custom RPCs. Extrinsics are used to perform transactions on the chain. Users interact with extrinsics using asymmetric (public key) cryptography. A user's public key, when stored on the blockchain, becomes their account identifier. Users submit transactions for an extrinsic by generating an appropriately formatted payload, and adding a cryptographic signature using the corresponding private key. The blockchain must verify the signature in order to continue processing the transaction. Frequency uses the Schnorrkel/Ristretto x25519 algorithm (abbreviated sr25519) as its key derivation and signature system.

In addition to extrinsics, Frequency has several structures for reading on-chain data from a node. When reading information, it is important that the specific node being used for access is trusted. As Frequency is a public blockchain, anyone can run a Frequency Node to submit transactions and read information securely from it.

State queries directly access the key-value store that holds the state of Frequency. Most libraries provide utilities to make the creation of the correct key and decoding of the data easy, although some storage can be difficult to parse or consume without additional processing, and underlying storage migrations will produce breaking changes.

Runtime APIs provide access to both chain and node information without being tied directly to the key-value store. They may also access running information about the Frequency node such as the version of the binary. These are "Runtime" APIs as they are deployed with the Runtime Wasm upgrades.

Frequency Nodes are also configured to provide a layer of Custom RPCs (Remote Procedure Calls). Custom RPCs are deployed only on the node, so allow for heavy processing, external calls, or other code that is not appropriate for the Wasm runtime execution environment. These RPCs do not upgrade until the node binary is upgraded, but may rely on Runtime APIs that are upgraded. Some Custom RPCs may require additional node configuration.

Collators

Collators are full nodes that additionally are responsible for maintaining Frequency by collecting the transactions submitted to the mempool and producing state transition proofs. They serve to organize and collect valid transactions in order to form blocks.

Frequency utilizes the Polkadot Relay Chain as its consensus mechanism. Collators submit newly formed blocks to the Relay Chain, which contains an extensive, decentralized network of validator nodes. The Relay Chain uses a Nominated Proof-of-Stake (NPoS) algorithm, where a validator node is chosen to process the state transition proofs submitted by Frequency's Collators. This architecture enables nodes on Frequency to focus on the functionality needed for users, while the Relay Chain handles block validation and permissionless security.

To ensure high availability, multiple organizations run Frequency Collator Nodes. In order to operate as a Frequency Collator, the node must meet additional criteria, as described in Collator Incentives.

Parachain & Relay Chain

Frequency is one of a set of blockchains that interoperate via the Polkadot protocol, stewarded by the Web3 Foundation. Blockchains participating in this ecosystem lease blockspace from the Polkadot Relay Chain, allowing them to take advantage of shared services provided by the Relay Chain.

Relay Chain blockspace can be leased on a fixed-price basis, making it ideal for highly scalable operation by allowing individual parachains the flexibility to alter the pricing structure of blockchain transactions for their users. Frequency utilizes these foundational economics to provide cost-shifting functionality for users through its Delegation Model and Capacity system in order to better support a high volume of non-financial transactions.

Polkadot uses the term parachain to describe a Layer 1 blockchain that runs in parallel to the Relay Chain and utilizes it for security and finality. Parachains like Frequency benefit from the pooled security, well-defined governance, and overall scalability made possible by the Relay Chain. By operating within the Polkadot ecosystem, parachains can also communicate securely with one another using cross-chain messaging via the XCM protocol.

Frequency's Collator Nodes maintain a full node on both the parachain (Frequency) and the Relay Chain (Polkadot). Because it operates as a parachain, Frequency requires only one honest Collator in order to operate without interruption. See more details about Collators on Polkadot's Wiki Page.

Diagram from Polkadot wiki on Collators

Learn more about Polkadot's parachain architecture.

Identity Management

Frequency has been designed to serve applications such as social networking that require a discoverable and addressable user identity. Users reference an identity that can be authenticated via the blockchain when communicating.

Frequency, like most blockchains, represents a blockchain account with a public key from a user's key pair. Additionally, Frequency introduces the concept of a long-lived identity, separate from the cryptographic credentials used to access that identity at a given point in time. A User Account is Frequency's term for a blockchain account that is associated with a user's identity. The user’s identity, known as a Message Source Account, or MSA, has its own separate identifier, the MSA Id, which is a 64-bit unsigned integer.

Frequency does not dictate what data should be linked to an MSA, leaving this up to the applications and protocols that use it. However, to facilitate the goal of user communication for social networking applications, Frequency provides a way of ensuring that each identity can have a unique, human-readable identifier referred to as a User Handle.

This section describes these three concepts (Control Keys, Message Source Accounts, and User Handles) in more detail, and illustrates the relationships between them.

Message Source Accounts Control Keys User Handles

Message Source Accounts

Message Source Accounts (MSAs) are unique to Frequency and provide enhanced capabilities distinct from other account systems while still ensuring that data has verifiable authorship.

Users must have a MSA to send Messages and utilize Stateful Storage on Frequency. A user does not need a blockchain account that holds FRQCY to be able to have an MSA; while MSA accounts have a cost to create, they require no existential deposit to be maintained on-chain. In addition, MSAs enable users to broadcast Messages through delegation to a Provider without needing tokens.

MSAs represent what most users of internet applications like social networking would think of as their account. While the User's Account, the cryptographic keys called Control Keys, might change over time, the account itself, and the data it has generated, remain available.

An MSA's identifier, or MSA Id, is simply a unique number permanently assigned to the MSA at creation time.

MSAs can be retired by the user with a valid Control Key. Once an MSA is retired, its corresponding MSA Id can never be reused or referenced in chain transactions that require an unretired MSA. This ensures that no confusion over the source of a Message will occur (as may occur in systems like a telephone network, when phone numbers are reassigned).

This ensures that no confusion over the source of a Message will occur (as may occur in systems like the telephone network, when phone numbers are reassigned).

Control Keys

Control Keys are cryptographic keys of the User's Account that are used to assert control of a user's identity. While an MSA can have multiple Control Keys, a particular Control Key cannot be associated with more than one MSA.

When creating an MSA, the user must submit a signature proving knowledge of the User Account's private key for the associated Control Key. The MSA is linked to the Control Key that was used to verify this signature. Subsequently, users can add and remove Control Keys as needed, provided that at least one Control Key remains linked to the MSA at any one point in time. Users might want different keys signifying access from different devices or wallets, or backup keys used only when needed for account recovery. Users can also delete Control Keys (unlink them from their MSA) if they are no longer needed or become compromised in some way. Currently all Control Keys associated with an MSA have the same set of rights and permissions.

User Handles

User Handles allow Frequency Users to select human-readable names for their MSAs, providing a user-friendly way to interact in application contexts. Each User Handle is unique and is mapped one-to-one with a MSA. Handles are optional, and no aspects of Frequency usage require a handle; Users may choose but are not required to create handles for their MSAs.

Frequency's User Handle system was designed to make it easy to use and integrate handles with existing user interfaces and wallet systems while remaining fully decentralized. User Handles also provide an important usability affordance, allowing users to interact with MSAs without relying on the need to recognize an address or MSA Id digits.

Handle Creation

A User Handle has two parts: the Base (the part of the handle the user selects) and the Suffix (a numerical code assigned by Frequency). The Handle Display is constructed by adding a "." character to the Base, followed by the decimal representation of the Suffix. For example, if a user chooses the Base "AliceInWonderland", her Handle Display might be AliceInWonderland.356, with the Suffix 356 assigned by Frequency. This allows users the ability to claim the Base they prefer without competing with one another for scarce resources, while keeping the Handle Display unique and non-conflicting.

The User Handle Base consists of UTF-8 characters (with certain restrictions), allowing for the full range of languages and character sets to be represented. The Base chosen by the user is additionally subject to a canonicalization algorithm that removes capitalization as well as any homoglyphs (characters that look the same or similar but have different Unicode codepoints) to a single canonical form. This does not affect the Handle Display (allowing users a high level of expressiveness within applications), while ensuring that the same Suffix is not assigned to two Handles that could be deceptively similar. In the above example, if "AliceInWonderland.356" has been allocated, a user requesting "AliceinWonder1and" (or any similar variations) would never get the "356" Suffix. This is intended to prevent users from attempting to impersonate other identities and ensures all Handles can be visually distinguished.

The suffix-generation algorithm serves to make the system resistant to namespace exhaustion and avoid race conditions. It also uses a pseudorandom seed to permute the order in which Suffixes for a given Handle Base will be assigned in order to discourage users from attempting to acquire a specific Suffix for vanity purposes. The range of Suffixes that will be assigned for a given Handle Base is determined by the Frequency Runtime parameters set by governance. At inception, Frequency Governance instituted two-digit Suffixes ranging from 10 to 99. As this namespace becomes more scarce for popular Handle Bases over time, the configuration can be changed to generate three-digit Suffixes, and so on.

Handle Retirement

While a user can only have one Handle at any point in time, Handles can be changed by retiring the old Handle and then creating a new one.

After a Handle is released, that specific unique combination of Handle Base and Handle Suffix cannot be reused. This is intended to prevent confusion that might otherwise arise in a social networking context if the same Handle was used with multiple identities over time.

Data Management

Frequency is designed around the need to enable secure and efficient distribution of high-volume, user-generated data. This data can be stored directly on each node for critical and frequently accessed items, such as a user's social graph, or can be stored off-chain, with Frequency serving as a means of discovery and authentication of items such as a user’s post, reply, or reaction.

This section discusses the different types of data management provided by Frequency, and the tradeoffs of using each in terms of high availability, scalability, and throughput.

Schemas Messages Message Batching Stateful Storage

Schemas

Frequency uses an extensible system of on-chain schemas to define the structure, storage, and semantics of data for protocol related data use cases, such as data defined for supporting DSNP. For these protocol related data items to be stored on Frequency, they must conform to a publicly discoverable schema.

Applications can use Frequency Schemas to properly retrieve, parse, and interpret protocol related structured data. This ensures data correctness, validity, extensibility, and interoperability among services, allowing Frequency to support a variety of data types and be used to implement communication protocols like DSNP between network and service participants.

Schema Registry

The Schema Registry is the on-chain repository for Frequency Schemas, allowing participants of the network to flexibly interact with and exchange protocol related data using Frequency as a source of truth. The unique identifier of Schemas on Frequency is the Schema Id, which is generated when the Schema is created.

Schemas are immutable; once created, they cannot be changed. Schema immutability means that Frequency Schema evolution (adding, removing, or changing fields) must be handled at the application level by registering each new version as a new schema on Frequency.

Schemas are used for two distinct types of protocol related data in Frequency: Messages and Stateful Storage. Messages are indexed by Schema Id and then block number, allowing applications to construct well ordered sequences to represent channels such as social media feeds. Messages lend themselves well to off-chain aggregation, providing high scalability at a low storage cost. Stateful Storage is indexed by MSA and then Schema Id, enabling rapid application access to state associated with a specific account.

Schemas are defined by their Schema Model and Payload Location. Different combinations of these two attributes are used for different scenarios.

Schema Models

Schema Models define the format and structure of the Frequency Schema itself, from which applications can determine how to serialize and deserialize data using the Schema. Frequency supports two model types for data to facilitate a wide variety of data use cases.

Parquet: The Parquet model type indicates that the schema is defined in Apache Parquet format. Parquet is a columnar format and includes options for Bloom filters, allowing files that contain collections of structured data to be queried without retrieving the full file. Frequency recommends Parquet files for off-chain data management due to its advantages when batching multiple user Messages. These highly-compressed files are stored by Message producers in the decentralized IPFS network, and a pointer to that file (its Content Identifier or CID) is stored on Frequency.
Avro: The Avro model type indicates that the schema is defined in Apache Avro format. Avro is a highly compressed row-based format. Frequency recommends Avro over Parquet when the guaranteed availability of on-chain storage is desired, because it is the more space efficient option. However, Avro does not provide the ease of use for batching and built-in Bloom filter functionality possible with Parquet.

Data is always accompanied by its Schema Id so that payload content can be parsed correctly.

Data may be compressed or encrypted before final serialization. Schema creators should register a Frequency Schema that describes both the "outer" (representing the compressed/encrypted data) and "inner" (representing the format after restoring the full plaintext of an item) data formats in these cases to aid in off-chain validation.

Payload Location

A Frequency Schema's Payload Location specifies how data will be stored. Off-chain IPFS Messages offer a lower transaction price and can enable applications to batch many Messages together. On-chain Messages offer increased availability guarantees at a higher price point and with the loss of batching capability.

IPFS: Frequency currently supports IPFS for off-chain data storage. Users store content as a file on the IPFS network. Only the file's Content Identifier (CID) and size in bytes is published to Frequency. The Frequency Schema contains the necessary information to validate and interpret the payload file's contents after retrieving it from IPFS.
On Chain: Data is published directly on Frequency and does not require additional protocol support for retrieval. The Frequency Schema contains the necessary information to validate and interpret the payload retrieved from the chain.

Messages

A Message on Frequency consists of data that must conform to a registered Frequency Schema. Messages are published in the context of a given block, allowing applications that observe events on the chain from finalized blocks to view the Messages for a given Frequency Schema as a well ordered stream of data items.

To submit a Message to Frequency, the submitted transaction must be signed by a Control Key linked to a Message Source Account. However, Frequency's Delegation Model provides options for scenarios where Providers can build a Message Batch (consisting of Messages from any number of users) and submit a single transaction for the entire batch, without sacrificing the ability for downstream applications to authenticate each individual Message within the batch.

Message Ordering

Ordering of Messages on chain is determined by their position within a block. Each Message is assigned a transaction index within its block. From an application perspective, Messages should be ordered by block number and then transaction index.

Message Retrieval

Message metadata, such as Schema Id and, for IPFS messages, CID, is stored on chain and thus always available. Message Payloads may exist either on chain or off chain. On-chain Message Payloads may be fetched for immediate processing. Messages with off-chain payloads contain references to an off-chain IPFS location. These payloads must be retrieved separately using the IPFS protocol.

Message Duplicates

Frequency does not attempt to deduplicate Messages in any way, since two Messages with identical data can still be distinguished by block number and transaction index. The semantics of duplicate Messages are therefore left to the application layer. For example, a protocol might require that applications consuming Messages for a given Schema Id be resilient in the case of duplicate Messages.

Message Batching

The ability to publish off-chain data using IPFS and the Parquet format enables a single blockchain transaction to encapsulate a large number of protocol-specific data items that share the same Frequency Schema. This is referred to as Message Batching. The Parquet type additionally functions to enable the off-chain searching, indexing, and organizing of Messages.

Message Batches allow applications to publish a single on-chain transaction that encompasses large quantities of data off chain, thus reducing transaction fees. Batched Messages also reduce block space requirements, resulting in lower transaction congestion on chain, which is crucial for a high-volume Message ecosystem.

Applications should consider the tradeoffs when assessing how frequently to form batches of Messages. More frequent batches reduce latency, while less frequent batches further reduce transaction fees.

Applications and protocols that use Message Batching can additionally benefit from Frequency's Delegation Model. This enables application providers to aggregate Messages from any set of users that has delegated permission to the application. These delegations can be confirmed against the chain by later consumers of the batch Messages.

Stateful Storage

Stateful Storage on Frequency is designed to allow users to store data with well-defined Frequency Schemas as part of chain state. Stateful Storage is useful for cases where the convenient discovery and retrieval of the current state of a data item should be retrievable by MSA account id, vs the block the transaction occurred in.

Stateful Storage is organized around the concept of fixed-size pages (approximately one kilobyte each) of user-controlled data, which enables Stateful Storage transactions to efficiently interact with the on-chain data store. Stateful Storage expands the definition of Frequency Schemas by adding two additional Payload Locations: Itemized and Paginated. Both forms of storage are data-agnostic, allowing for a full range of data types to be represented. The client application is expected to manage the data within each page or within the itemized model, in conformance with the specified Frequency Schema.

Itemized and Paginated Data

Itemized Stateful Storage allows for an ordered list of data items that is limited in aggregate size to a single page. This is most useful when payloads are composed of many small items that need to be individually addressed and managed. Itemized Stateful Storage Schemas can optionally indicate that users should only be allowed to add new items, and not delete or replace existing ones, via an Append Only setting.

Paginated Stateful Storage is organized as a sequence of pages and is most useful for payloads with larger items or a cardinality of items that would, in aggregate, exceed the capacity of a single page. Users must designate a Page Id when publishing paginated data. Page Ids are allowed to be non-sequential. Users may create any Page Id up to the largest allowable and there may be gaps within the Page Id range, enabling applications to adopt Frequency Schema-specific strategies to minimize the number of writes required to maintain the data for a given Schema.

Stateful Storage items or pages, depending on the type, can be inserted, updated, or deleted, unless the Append Only option is specified by the Frequency Schema.

The Signature Required setting may be applied to Frequency Schemas utilizing either type of Stateful Storage and requires that the payload be signed by the owner as well as the transaction's submitter. This means that even though a Provider may submit the transaction, it must be signed directly by a Control Key of the MSA owner.

This setting is useful for protocols to indicate data types where a user should retain direct control of data. For example, when publishing credentials or identifiers to be used off chain, it may be important to know that the user themself, rather than their Provider, has authorized the data. Users can create an action, sign the payload, and either request that a willing Provider with sufficient funds (token or Capacity) submit it on their behalf, or submit the transaction and pay the relevant transaction fees themself.

Avoiding Race Conditions

Each page of data in Stateful Storage includes a hash generated from the content and a nonce calculated when the page is stored. When submitting updates to the chain, the payload must include the previous hash. If the hash in the request does not match the current content hash on chain, the system will reject the Message as "stale". Thus, clients or apps must ensure that they have the latest state when submitting modifications to the chain. This is used to avoid race conditions and out-of-order state manipulations that may occur, for example when multiple client applications are submitting changes against cached data.

Delegation Model

Typical blockchain solutions exhibit a dichotomy between those that are transparent and decentralized and those that are low friction and thus provide straightforward onboarding and ease of use for users with little to no cost. Low-cost and low-friction solutions tend to be highly centralized, opaque, and offer little to no user controls. In contrast, solutions that offer transparency, decentralization, and user control tend to be complicated and require users to possess both significant domain knowledge and the willingness to acquire a substantial number of tokens in order to participate.

Frequency manages the user’s need for accessibility via its Delegation Model, which shifts most of the complexity and all of the fees for participating in blockchain applications away from end users to Providers: the creators of third-party applications and services directly interacting with Frequency. Users can still choose to interact with the chain using tokens if they wish to avoid third-party providers or participate in chain governance, but the system does not require it. Users can also directly revoke delegated permissions, even if they are Coinless Users.

MSAs allow users to delegate tasks to Providers on their behalf and ensure Messages and Stateful Storage (i.e. non-financial transactions) have verifiable chains of authorship, while maintaining the ability to revoke a delegation at any time without cost.

Providers Mechanics Benefits One-Time

Providers

Providers are the on-chain representation of applications and services directly interacting with Frequency. Providers must have their own MSAs, but a user may delegate to one or more Providers who may then submit data transactions on that user's behalf via delegated permissions. Providers can use the Capacity economic system as an alternative to FRQCY to pay the transaction fees of the users that delegate to them.

Provider Registration

Any entity that controls an MSA and wishes to be a Provider may follow the procedure to do so. Providers must identify themselves by name (distinct from the optional User Handle for their MSA) and go through a registration process.

On Testnet, any MSA can register to be a Provider. On Mainnet, any MSA can submit a request to be a Provider. Currently, the request must be approved by a member of the Frequency Council. Other approval mechanisms may be made available in the future to approve a Provider.

No Provider De-registration

Once an MSA is registered as a Provider, the registration is permanent, and the MSA itself cannot be retired, in order to preserve the ability for applications to verify delegation of past transactions referencing off-chain data.

Delegation Mechanics

A delegation authorizes a Provider to manage specific data on behalf of a delegating user. The user must sign a transaction approving all details of the delegation. The Provider must then submit that approval to the chain to establish the link between the user's MSA and the Provider. The terms of the relationship between users and Providers are not dictated by Frequency, but Provider terms should be specified in the approval request at the time of Provider approval. There is currently no way for these terms to be updated by a Provider. By requiring both parties to sign the transaction, delegation can only occur by mutual consent.

Delegation permissions establish the set of Schema Ids (data and relationship types) for which Providers may publish data on behalf of the delegating user.

All delegations are public and readable by anyone. This ensures accountability, as any interested party can observe Provider actions.

Delegations are unilaterally revocable; either the delegating user or the Provider may terminate a delegation at any time. Again, the terms of the relationship are not dictated by Frequency. Delegation removals are also public, so parties not acting in good faith or honoring their terms can be identified and managed at the application level.

Benefits of Delegation

Frequency's implementation of delegation and the Capacity economic system enable a new class of low-friction "coinless users". Coinless users, as the name suggests, do not need tokens to interact with the blockchain and do not need to cryptographically sign every interaction (such as posting a Message or updating their social graph). Instead, coinless users delegate their needs to a Provider. Coinless users still have MSA accounts with private keys that maintain control of their user information, identity, and delegations on chain. While a coinless user might still interact with tokens for other purposes, they are not required to do so. For more information on Frequency’s economic structure, see the section on Tokenomics.

Providers and coinless users are critical aspects in building decentralized applications for use cases like social networking that require rapid and massive scaling to a large audience with the lowest possible friction. Onboarding becomes straightforward and intuitive to users as they do not need to acquire tokens or cryptographically sign every interaction, reducing both socioeconomic and technological barriers to entry.

Autonomous Users

While the Provider-Delegator relationship has clear benefits, the owner of an MSA can still opt to pay for their own interactions with FRQCY, and can send their own Messages without delegating to a Provider. The user’s Control Key must be associated with the user’s MSA and hold tokens in order to pay for these transactions.

Any users that opt to hold FRQCY may engage in staking, governance, building new Frequency Schemas, and with other systems on Frequency.

One-Time Delegation

Some actions are sensitive and may require direct user approval. These actions may still be delegated and the token or capacity cost of that action paid for by a Provider. Most of these actions are user account-centric instead of user activity-centric like the continuous delegation. Some example actions are Handle changes, adding Control Keys, and creation of delegations. Developers of Schemas may also indicate that a Stateful Storage requires a one-time signature instead of a continuous delegation.

While each one-time approval signature may be processed and secured from replay attacks in different ways depending on the action, the signature has two primary requirements: The data that expresses the action and a mortality.

The data expression of the action being signed means that the user is aware of the details of the action. An example is the act of forming a delegation. The delegation must be agreed to by the user and this agreement is captured in the form of the signature over the data containing the Provider’s identifier as well as the specifics of the delegation permissions.

The mortality time bounds the signature such that the signature is rejected after a certain block. Thus, the user may be certain that the action either has or has not happened after the end of the mortality and there is no risk of an old signature being acted on. Frequency also sets a maximum for the mortality of less than approximately 30 minutes.

Tokenomics

Frequency's economic model has been designed to optimize for the scalability concerns associated with social networking, specifically data focused transactions centered around new Message publishing versus updates to existing data. Like most blockchains, Frequency enables transaction fees to be paid in its native token: Mainnet utilizes a utility token called FRQCY, while on Testnet, the token is denoted as XRQCY. In addition to tokens, Frequency also utilizes a system of impermanent Capacity, a renewing stake-based alternative that allows Providers to perform certain types of transactions.

This section covers the design of the Frequency Incentive Model and key cryptoeconomic elements such as token distribution and the inflation system. The Frequency Incentive Model focuses on the three core actors: Collator Incentives, Provider Incentives, and User Incentives.

Collator Incentives Provider Incentives User Incentives Initial Token Distribution Inflation & Liquidity

Collator Incentives

Collator Rewards incentivize the formation of the blocks necessary to ensure that the chain continues to function. Since Frequency is a Layer 1 chain in the Polkadot ecosystem, the Relay Chain is used for consensus and finality via the parachain leasing mechanism. However, block formation is still a Frequency responsibility that must be performed by Frequency-specific Collators. Public Collators must stake to the network to participate. All Collators participating in block formation activities will eventually begin to receive token rewards, though the details of this mechanism will be finalized as part of the process of launching Public Collators.

Collators are analogous to validators in other proof of stake networks, but the work done by Collators is significantly lower, requiring less computational overhead and lower participation levels, given that consensus and finality occur at the Relay Chain level. Public Collators are currently a roadmap item, and Frequency currently uses Invulnerable Collators that do not receive rewards for block formation.

Provider Incentives

The Capacity model incentivizes participants that are interested in publishing protocol-related data on the blockchain to hold FRQCY. The principal use case for Capacity is Providers acting on behalf of coinless users who have delegated certain permissions to the Providers to act on the users' behalf.

Capacity balances two core goals related to scalability. The first goal is providing a low transaction cost mechanism for Message publishing. Given the volume of Messages generated in social networks, Providers must be extremely cost-conscious about Message publishing costs. The second goal is minimizing spam in a system designed to minimize Message publishing costs. As the cost of Message publishing decreases, the viability of spam Messages increases proportionally. The design of Capacity attempts to balance these two goals.

Capacity Model

While all transaction fees on Frequency can be paid for with FRQCY, certain types of transactions can use Capacity which strikes a balance between Message publishing cost and spam prevention using three core mechanisms: staking, renewal, and unstaking.

Capacity Staking

Capacity is generated by staking FRQCY. There are several mechanics and restrictions involved in Capacity Staking.

The amount of Capacity generated is proportional to the number of FRQCY staked, with the specific ratio being set via Frequency Governance. While the ratio can change over time, changes to the ratio only affect staking done after the change; existing stakes maintain the ratio in effect at the time the stake was made. This incentivizes stakers to maintain stakes with ratios perceived as favorable, generally stabilizing net investment in the network. The roadmap anticipates that the staking ratio will migrate from the current model where it is set by governance to a future model that adjusts the ratio algorithmically based on chain metrics. The initial Capacity Staking Ratio for Frequency is 50:1; 50 FRQCY must be staked for each Capacity unit generated.

When staking for Capacity, the staking account must designate a specific Provider to receive the Capacity. While any FRQCY holder can participate in staking, Capacity can only be spent by a Provider. Capacity Staking is specifically targeted at managing costs for Providers by giving them a mechanism with low price volatility for publishing Messages. This restriction ensures that Capacity Staking focuses on the Message publishing use case, versus other potential derivative possibilities and incentives.

Capacity can only be spent by the Provider who receives it. There is no transfer mechanism for Capacity: only the Provider who receives the Capacity can use it on eligible transactions as an alternative to token fees. This focuses the utility of Capacity on minimizing transaction cost while avoiding a secondary market in Capacity speculation.

Capacity Renewal

Capacity renews on a periodic basis. Despite the staking ratio for Capacity requiring multiple FRQCY to be staked for each unit of Capacity generated, any Provider with recurring Capacity-eligible transactions will quickly find using Capacity more economically efficient than spending tokens.

Capacity Staking has a Capacity Epoch, which is defined as a fixed number of blocks. The number of tokens staked by a given Provider determines that Provider's Capacity Allocation, which may be increased by Provider Boosting. Providers can spend up to their full Capacity Allocation on transaction fees each Capacity Epoch. At the beginning of each Capacity Epoch, the Provider's Capacity Allocation is renewed, allowing the same amount of Capacity to be spent again in the next Capacity Epoch. The initial Capacity Epoch for Frequency is 7,200 blocks (a duration of approximately 24 hours, given Frequency's 12-second block time target). Capacity incentivizes sending Messages by reducing transaction costs. In a social networking context, the utility of the network increases as users communicate more, so Capacity acts to increase overall network utility over time by reducing the transaction cost of Message publishing.

To illustrate the utility of staking for a Provider, given the initial Capacity Epoch length of 7,200 blocks, and the initial 50:1 Frequency to Capacity Staking Ratio, consider two Providers with 50 FRQCY, Provider 1 staking their tokens, and spending 1 Capacity on transaction fees each Capacity Epoch, and Provider 2 spending 1 FRQCY on transaction fees each Capacity Epoch. After approximately 50 days, Provider 2 would be at fund exhaustion, while Provider 1 could continue to spend 1 Capacity each Capacity Epoch indefinitely, preserving the optionality to unstake all staked tokens at some time in the future.

Unused Capacity does not roll over to the next Capacity Epoch. Any unused Capacity remaining in a Provider's Capacity Allocation at the end of a Capacity Epoch is lost. When Capacity renews at the beginning of a Capacity Epoch, it can never be more than 100% of the Provider's current Capacity Allocation. This makes Capacity usage more analogous to time-bound resources such as wireless spectrum or bandwidth than to accumulation-bound resources such as a bank balance. The combination of favorable staking ratios, the fact that the staking ratios are locked at the time of stake, and the fact that Capacity cannot be transferred might incentivize Providers to hold excessive stakes at favorable rates. However, the fact that Capacity cannot be rolled over incentivizes behavior that optimizes Capacity Staking for peak use cases, but not much beyond that, since such stakes provide no extra economic value for the encumbrance of staking.

Capacity Unstaking

FRQCY staked to generate Capacity can be unstaked. However, unstaked tokens are not immediately available, and remain locked for a period of time after unstaking before being otherwise usable by the staker. This delay is referred to as the Thaw Period.

The Frequency Thaw Period is a key anti-spam measure. In a model such as Capacity where tokens can be staked instead of spent to pay transaction fees, there is a risk of creating an environment where there is zero marginal cost for sending spam. Requiring a non-trivial staking ratio and combining that with a significant Thaw Period does not directly increase the cost of spam, but puts the value of the staked FRQCY the spammer acquired at risk, as the effects of any large-scale abusive behavior theoretically have time to be reflected in whatever mechanism the spammer used to acquire FRQCY before the unstaked tokens can "thaw" and become usable again by a bad actor. The initial Thaw Period for unstaking Capacity is 30 Capacity Epochs.

Requiring bad actors to acquire FRQCY to send "free" Messages, but making them wait for the repercussions of their behavior to be reflected in the value of their FRQCY holdings does not eliminate bad behavior. However, it does limit the economically sustainable volume that can be sent without impacting the value of the bad actor’s FRQCY holdings to a greater extent than the value of the Message.

Capacity immediately stops being generated when unstaked, but the staked tokens are only unlocked at the end of the Thaw Period. This lowers the volatility of Capacity Staking Ratio changes. By default, if the staking ratio goes up (requiring more FRQCY per unit of Capacity), existing stakeholders have a strong incentive to retain their existing stake and benefit from the better ratio. However, if the staking ratio goes down (requiring fewer FRQCY per unit of Capacity) there could be strong incentive for large numbers of stakers to unstake tokens and restake at the lower rate, freeing up excess tokens for other use cases or increasing the amount of Capacity they can generate. This could have drastic effects on freely circulating token supply and pricing. The Thaw Period mitigates some of this potential volatility as staking ratio rates decline by requiring those who contemplate unstaking to not only react to the new lower ratio, but also predict that the ratio will still be lower at the end of the Thaw Period, while losing the benefit of generating Capacity during the Thaw Period. The combination of the risk of the ratio going back up and the loss of utility during the Thaw Period further helps balance Frequency's Economic Model.

User Incentives

Frequency incorporates a second form of staking called Provider Boosting. While Capacity Staking solely produces Capacity and is designed to help Providers maximize economic utility for publishing Message transactions, Provider Boosting gives users a mechanism to indicate support of, or withdraw support from, Providers by staking FRQCY. Provider Boosting is still in development, and specific aspects of the design described below may change before a Frequency Governance approved release

Boosting

Provider Boosting also involves staking FRQCY. Staked tokens generate Capacity (like Capacity Staking) and therefore require a Provider to be designated as part of the staking process. In this scenario, a different ratio of FRQCY to Capacity (the Boosting Ratio) is used, which is always less token-efficient than the Capacity Staking Ratio for the amount of Capacity generated. The Token Account that stakes the tokens also receives a reward, paid in FRQCY, to reward the Token Account holder for participating in Provider Boosting and expressing their support for the Provider(s) they chose to receive the Capacity generated by their staked tokens. The reward is distributed at the end of each Reward Epoch, a number of blocks set by governance and initially configured to a duration of approximately 14 days.

Users must maintain their full stake throughout the entirety of the Reward Epoch in order to qualify for a reward. Each Reward Epoch has a fixed number of tokens that can be minted to reward Provider Boosting participants, and those rewards are paid based on the ratio of the user's Provider Boosting stake to all user Provider Boosting stakes across all Providers. Token for rewards are not minted during, or at the end of, the Reward Epoch. Instead, tokens are minted at the time they are claimed by Token Account holder, sometime after the end of the applicable Reward Epoch. However, all rewards are capped at a maximum Annual Rewards Rate set by governance. Given that the reward is paid via new token minting, the reward for Provider Boosting contributes to FRQCY inflation.

Provider Boosting represents a user's approval or support of a Provider by virtue of the user staking tokens that increase the Provider's Capacity Allocation, creating a trackable continuous support metric. To allow the user to react to the behavior and actions of the Provider, the user has the ability to designate a different Provider to support with their stake at any time, without going through a thawing process. This allows a user to change which Providers they support at any time, signaling approval of a newly supported Provider, disapproval of a Provider that loses their support, or both. Changing which Providers they support has no impact on the rewards a user receives for their Provider Boosting stake.

Rewards

Provider Boosting provides rewards and incentives to both users and Providers who participate.

Users have two incentives to participate. The first is the actual token reward received for staking tokens via the Provider Boosting mechanism. The second is the ability to instantaneously and continuously provide or withhold their support or approval of particular Providers in the network in a way that has a direct economic impact on Providers. An on-chain, incentivized mechanism for users indicating support for application participants in the ecosystem is a novel mechanism in the space, and very different from how, for example, social networking applications function today.

Providers also receive value from Provider Boosting. They receive Capacity from users, which can substitute for Capacity they would have otherwise received by acquiring FRQCY and deploying them using Capacity Staking. Depending on user participation levels and Provider popularity, this could represent all the Capacity needs for a Provider. A Provider also gains block-level insights into user reactions to their product offering, policy changes, and other reputational criteria. This ongoing signaling can be a powerful feedback mechanism for a Provider as the set of participating users express their approval on a continuous basis.

A novel aspect of Provider Boosting is that while Providers receive Capacity based on user support, there is no on-chain function or mechanism for Providers to pay users for the Capacity received. Instead, the Frequency chain itself is paying the Reward to users for participating. This changes the nature of the user/Provider interaction involved in Provider Boosting. Instead of Providers "paying" users to support them, as some other cryptoeconomic systems promote, the network incentivizes users to stake, with no specific economic incentive for which Provider they support. This "economically agnostic" choice that Provider Boosting incentivizes users to make can increase the quality and value of the support or approval that Provider Boosting implies; this establishes real economic incentive for Providers to behave in the ways users support or prefer.

Visibility

Provider Boosting, via user staking to support Providers, is also a form of Provider reputation scoring. There are several ways these stakes can be interpreted. For example, rankings can be composed for total tokens staked per Provider, average tokens staked per user, rates of increase or decrease for a Provider, and so on. Each grants valuable insight to users about Providers with whom they may want to start or stop interacting, as well as signals Providers regarding user interest, approval, and support.

Since all Provider Boosting activity occurs on chain, all changes in staking activity are publicly visible. While Token Accounts used for Provider Boosting may or may not be associated with a user's MSA, all Providers in Provider Boosting are directly identifiable. This means there is no way for Providers to suppress visibility around public sentiment as expressed by Provider Boosting. The independent, public and decentralized nature of Provider Boosting is rare in existing platform-based communication channels, and serves as another incentive for users to participate.

Initial Token Distribution

One billion FRQCY were created at Genesis and allocated as follows:

Frequency Network Foundation
- Foundation: 2.0%
- On-Chain Treasury: 53.0%
- Strategic Partners: 5.0%
Amplica Labs
- Investors: 22.0%
- Team: 14.5%
- Treasury: 3.5%

Inflation Rate and Liquidity

Frequency currently has no new tokens being minted. All token-based transaction fees are burned, creating an initial environment that is mildly deflationary. However, as certain features are launched, it is anticipated that Frequency will have a net inflationary token supply. In addition, certain aspects of the chain encourage increases of liquid token supply, while others encourage decreases.

Inflationary Mechanisms

Current contributors to inflation are Collator Rewards and Provider Boosting. Both of these features involve the minting of new tokens. Each feature is anticipated to have a fixed issuance model with chain Governance controlling the specific number of tokens issued per time period, leading to a declining overall inflation rate, as a ratio of minted tokens to total token supply, for the chain over time. Issuance rates will be finalized for Collators when Public Collators launch. Issuance rates will be finalized for Provider Boosting when the feature launches. The aggregate inflation across Collator Rewards and Provider Boosting is currently planned to not exceed 50 million tokens per annum, which would be 5% of the initially minted tokens. Inflation mechanisms and rates will be approved by governance as part of the release process of each feature.

Deflationary Mechanisms

Current contributors to deflation are the burning of transaction fees and slashed governance deposits. Of the two, only transaction fee burning is anticipated to have a significant impact on overall token supply. The entirety of token-based transaction fees are burned. While on some networks this can be very significant, it is anticipated that the majority of transactions on the network will utilize Capacity, rather than pay transaction fees. However, as only some types of transactions can be paid by Capacity, transaction fees constitute an unavoidable reduction in the supply of FRQCY. There are some types of governance actions that require deposits that are burned if the action is denied. However, governance deposits are not anticipated to generate significant reductions in the token supply when compared to transaction fees.

Circulating Supply

Increases in circulating supply can be triggered by distribution of tokens from the on-chain treasury and situations that encourage the unstaking of tokens from Provider Boosting or Capacity Staking, such as a change in the staking ratio or either mechanism. Information about potential increases is generally available for all three of these activities. In the case of on-chain treasury spending, the Governance approval process gives an indication of intent and the voting process allows for some trend analysis. In the case of both staking activities, the Thaw Period of each indicates pending changes in circulating supply in advance of the tokens unlocking.

Decreases in circulating supply are triggered primarily by increased staking activity. Both Capacity Staking and Provider Boosting lower overall token circulation levels as staked tokens increase. However, staking levels don't decrease Providers’ ability to pay transactions fees for certain transaction types, given that both types of staking generate Capacity. Generally, staking models require derivatives like "liquid staking" or they risk decreasing network transactions due to a smaller circulating supply of tokens available to pay transaction fees, which can reduce the value of the network. Frequency is less susceptible to that correlation, since Capacity generated from staking can actually be spent on transaction fees. This means that a lower circulating supply of FRQCY does not necessarily result in a lower transaction volume on chain due to Capacity-related transactions.

Governance

Frequency Governance currently uses Polkadot Governance V1: a tricameral governance structure which includes coordinated governance by three institutions: the Frequency Council, analogous to the Council in Polkadot Governance V1, the Technical Committee, analogous to the Technical Committee in Polkadot Governance V1, and token holder voting, analogous to the Public in Polkadot Governance V1.

Governance Parameters

These are important governance parameters, which may change over time.

Launch Period: Public referendums are opened every 7 days.
Voting Period: Votes are tallied every 7 days.
Emergency Voting Period: The voting period for fast-tracked emergency referenda is 3 Hours.
Minimum Deposit: Proposing a referendum requires a minimum deposit of 100 FRQCY.
Enactment Period: The minimum period for locking funds and the period between a proposal being approved and enacted is 8 days.
Cool-off Period: A vetoed proposal may not be re-submitted within 7 days.

Glossary

Account

An account on the blockchain, represented by a public key. Accounts may hold a token balance, transfer tokens, and pay transaction fees. Not to be confused with Message Source Accounts, which are unique to Frequency and ensure that user-generated data has verifiable authorship. See Identity Management.

Autonomous User

An end user who spends tokens to perform transactions directly on Frequency, in contrast to a coinless user, who delegates to Providers in order to pay transaction fees. See Autonomous Users.

Batch

See Message Batch.

Capacity

An alternate payment mechanism for certain classes of transactions that allows Messages to be sent and on-chain work to occur over time. Capacity allows Providers a rate-limited continuous stream of transactions and provides an alternative to using tokens to perform individual transactions. Capacity is generated via Capacity Staking and Provider Boosting. See Capacity Model.

Capacity Allocation

The amount of Capacity generated for a Provider per Capacity Epoch. See Capacity Renewal.

Capacity Epoch

The number of blocks before Capacity refills. In other words, it is the number of blocks before a Provider may reuse their Capacity Allocation. See Capacity Renewal.

Capacity Staking

A form of staking that allows Providers to use FRQCY as efficiently as possible, optimizing their generated Capacity for serving end users. Capacity Staking generates more Capacity per token staked than Provider Boosting. See Capacity Staking.

Capacity Staking Ratio

The ratio of the number of FRQCY that must be staked per unit of Capacity generated each Capacity Epoch. See Capacity Staking.

Coinless User

An end user who doesn’t use tokens to interact with Frequency. While coinless users maintain User Accounts that enable them to directly control their authentication and authorization data on chain, they delegate transaction handling to a Provider who will in turn manage data transactions (such as sending Messages) on their behalf. See Benefits of Delegation.

Collator

A Frequency Node that generates blocks and submits them to the Relay Chain. Frequency currently operates using Invulnerable Collators, but intends to transition to Public Collators in the future. See Collator.

Collator Nodes

Servers that participate in the Frequency Network and are configured to form blocks. See Operational Model.

Collator Rewards

FRQCY awarded to Frequency-specific Public Collators for staking to the Frequency Network and participating in block formation activities. See Collator Incentives.

Content Identifier (CID)

A unique identifier used with IPFS derived from the content of a file. See Schema Payload Location.

Control Key

The public key of the User's Account used to identify the control an MSA. See Identity Management.

Delegation Model

The mechanism whereby end users can grant permission to perform tasks that require significant blockchain knowledge or token ownership to Providers, reducing friction and enabling Message Batching to improve scalability. Also includes the concept of Revocation, where a user can revoke permission to perform those tasks from a Provider. Revocation does not have any on-chain transaction fees associated with the transaction, ensuring that Coinless Users can invoke it without Provider permission. See Delegation Model.

End User

A user who owns an MSA but is not acting as a Provider. An end user may choose to own tokens to participate in Provider Boosting to support services and participate in on-chain governance with Capacity. See Delegation Model However, end users typically delegate other tasks to Providers who perform actions on the user's behalf. See Coinless Users and Delegation.

Existential Deposit

The minimum token amount an Account that is not associated with an MSA may have and still be considered alive. See Message Source Accounts.

Frequency Council

The set of Frequency accounts that are responsible for certain governance actions, including Provider approval. See Governance.

Frequency Node

A server that participates in the Frequency network. See Interaction Model.

FRQCY

The native coin on Frequency Mainnet, which can be used to pay any Frequency transaction fees, or staked for Capacity. Sometimes referred to as "FRQCY Token" or simply "tokens". Holders of FRQCY are often referred to as token holders. See Tokenomics.

Handle

See User Handle.

Handle Base

The user-selected portion of the Handle Display. See Handle Creation.

Handle Display

A user’s entire User Handle as displayed by the system including the user-selected Handle Base and the system-selected Handle Suffix, separated by a “.” character. See Handle Creation.

Handle Suffix

The system-selected numeric portion of the Handle Display. See Handle Creation.

InterPlanetary File System (IPFS)

A decentralized content-addressed file system protocol. See https://docs.ipfs.tech/ for more detail.

Invulnerable Collator

A collator that cannot be removed without governance action.

Key pair

A matching public key and private key. The private key can be used to generate cryptographic signatures which third parties may verify with the public key. See Identity Management.

Message

A protocol related data item that is indexed by its Schema Id and block number. See Messages.

Message Batch

A collection of Messages, possibly from many different Message Source Accounts (MSAs), that allows Providers to publish a single on-chain transaction that references large quantities of data off chain, thereby reducing the transaction fee. See Batching.

Message Source Account (MSA)

Message Source Accounts (MSAs) are distinct from Token Accounts and unique to Frequency. They ensure protocol related data items have verifiable authorship. End users with MSAs are not required to have FRQCY or Capacity to interact with Frequency, but may instead choose to delegate tasks that require Capacity to Providers. See Message Source Accounts.

MSA Id

The unique 64-bit unsigned integer identifier associated with an MSA. See Message Source Accounts.

On-Chain Message

A Message that has its payload stored on the Frequency blockchain. See Payload Location.

Off-Chain Message

A Message that has its payload stored on IPFS. See Payload Location.

Payload

The data within a protocol related data item. The format of the payload is defined by the corresponding Schema Model. See Schemas.

Payload Location

The attribute of a Frequency Schema that specifies how and where data will be stored. See Schema Models.

Provider

The holder of an MSA that can allow others to delegate to it such as applications and services that use the Capacity economic system. Providers utilize Capacity to serve the end users that delegate to them. See Providers.

Provider Boosting

Provider Boosting allows users to stake FRQCY they hold to support specific Providers. Providers who are "boosted" by end users receive additional Capacity, while Users who "boost" Providers receive a reward (in the form of additional FRQCY).

See Boosting.

Public Collator

A Collator who bonds FRQCY in order to participate in block formation, and receives rewards for participation. Public Collators who behave improperly risk losing their position and their bond. See Collator Incentives.

Reward Epoch

The number of blocks between distributions of Provider Boosting rewards. See Boosting.

Revocation

See Delegation Model.

Schema

Registered data structures for Messages and Stateful Storage items. Frequency Schemas define where Payloads are stored and how end users can parse the data within. See also On-Chain Message and Off-Chain Message. See Schemas.

Schema Id

The unique identifier of a Schema on Frequency. See Schemas.

Schema Model

Metadata about a Frequency Schema that defines the format and structure of the Schema itself, from which applications can determine how to serialize and deserialize data using the Schema. Frequency supports two model types for data: Parquet and Avro. See Schema Models.

Frequency Documentation