Authorization¶

Introduction¶

The Bulletin Chain has no token balance for storage. You cannot "pay for storage" the way you pay a transaction fee on a typical chain. Instead, every account that wants to write to Bulletin needs an explicit authorization: an on-chain record that grants a quota of transactions and bytes, with an expiration block.

A write attempted without authorization is rejected at the boundary. This page is the reference for how authorizations are shaped, how they are checked, and what happens when they expire.

What an Authorization Records¶

An authorization is a per-account on-chain record stored in the Authorizations storage map of the transaction-storage pallet. It records, for the account it covers:

• Remaining transactions: How many storage extrinsics the account may still submit before the quota is exhausted.
• Remaining bytes: How many bytes total the account may still write across those transactions.
• Expiration block: The block at which the authorization expires. Unused capacity is not refunded when this block passes.

A Product can verify an account's current authorization by reading the Authorizations storage map for that account through the standard chain client.

What a Write Costs¶

Each storage submission decrements both counters:

• The transaction counter decrements by one per extrinsic.
• The byte counter decrements by the payload size.

The transaction counter is the one most Products will hit first. Even a small upload that uses chunking (because the payload exceeds the per-transaction byte limit) consumes one transaction per chunk; large files consume the corresponding count.

Expiration¶

Authorizations are time-bounded for a reason: storage on the network is finite, and an unexpiring authorization would let an inactive account hold reserved capacity indefinitely. When the expiration block passes:

• Any remaining transaction and byte quota in that authorization is forfeited (not credited to a new authorization, not refunded to the user).
• Subsequent storage attempts return an authorization error until a new authorization is provisioned.

A Product whose users store data over time needs to think about authorization renewal as a first-class concern, not a once-at-onboarding step.

Provisioning on TestNet¶

On TestNet today, authorizations are provisioned through a faucet built into the Bulletin Chain Console. The Get TestNet Tokens guide walks through requesting an authorization for a paired account.

Where to Go Next¶