The referendum description can also be found in this document: https://docs.google.com/document/d/1mxCdEUmb05nQXDrh1m_-vV-QapTFHTbvQV6Q0J26MM8/edit?usp=sharing

PCF owns and publishes the Polkadot App under #1082 and #1573.

This referendum enables the last on-chain parameters needed for username registration in the Polkadot App. Approving this referendum also confirms PCF as the operator of the onboarding service.

When a new user joins through the App, they choose a username. Behind the scenes, the onboarding service does two things:

• registers the user as a lite person on the People chain;

• reserves the user's .dot name on Asset Hub.

  A lite person is a light form of personhood on the People chain. In this case iIt shows that an account comes from an app installation the onboarding service has verified and attested, not that it belongs to a unique human. It lets the user claim small fee-free allowances, such as for messaging and app storage, anonymously through a membership ring. On-chain it records only the user's account and a public membership key: no real name, email, or other personal details. The username the user picks is public, as every .dot name is.

Both systems already exist on Polkadot. What is missing today is the allowance and routing setup that lets the onboarding service use them. Until those values are set, new registrations remain pending.

This proposal sets those values and grants three base app names used by the Polkadot App. It does not upgrade any runtime, deploy new code, or request Treasury funding.

At a Glance

What Voters Are Approving

The referendum contains four existing calls, bundled together and executed with Root through the Whitelisted Caller track.

The main parameters are:

An allowance is not a transfer of funds. One unit is consumed only when one user is onboarded, and each attestation is visible on-chain.

This referendum does not:

• upgrade any runtime;
• deploy new contracts;
• move Treasury funds;
• register the three app names by itself;
• give the attester control over user funds;
• give PCF a general right to grant additional names.

It only sets the parameters listed above.

Accounts and Custody

There are two important accounts in this proposal: the attester, which handles user onboarding, and the names owner, which holds the three base app names once they are registered.

Attester

The attester is:

15sDLj4T9NnCtT665koDMxBs1PZw3rzDc6wcz9tN9kKTQ2zj

It is a pure proxy, so no private key exists for the attester account itself. It was created in Asset Hub extrinsic 21514129-2.

To onboard users, the service signs as the attester with the onboarding service key:

12jrwPAgzi1iTCSxxbdjzmLitdeKB87xh8yeriV2ihWH8vBt

That key is held by the PCF.

If the signing key were compromised, the holder could register lite people and reserve names for accounts of their choice, up to the remaining allowance on each chain. They could also act as the attester account itself, including over its own funds and delegates.

They could not touch user funds, other accounts, the names owner, or the dotNS contracts.

The response path is clear:

• PCF can replace the signing key with one multisig action. The attester account and its allowances stay the same, so no referendum is needed.
• Governance can stop further onboarding at any time with clear_attestation_allowance on either chain, through Whitelisted Caller or Root.

Lite people already registered would remain registered. Removing them would require a separate governance action.

Names Owner

The names owner is:

0xA5C4c241985D77A0296a0FB83E0FA5905e9E39De

This maps to the Asset Hub account:

13oaSihqaoZ8zprCpbnuqdQqi9zLw99rwkSk3zG2hbzxU3ke

The mapping is on-chain:

Revive.OriginalAccount(0xA5C4c241985D77A0296a0FB83E0FA5905e9E39De) = 13oaSihqaoZ8zprCpbnuqdQqi9zLw99rwkSk3zG2hbzxU3ke

The account is also a pure proxy. It was created by PCF's 4-of-6 multisig in Asset Hub extrinsic 20362133-2, and that multisig is its only delegate.

It has the on-chain identity "PCF" and owns the live dotNS contracts listed in the dotNS v1.0.0-pcf.1 release.

Why the Allowance Is 1,000,000

Each new user consumes one allowance unit on each chain:

• one on People to become a lite person;
• one on Asset Hub to reserve their .dot name.

An allowance of 1,000,000 on each chain therefore covers about one million new users.

PCF considered a smaller first tranche, such as 100,000, with later top-ups. The trade-off is that each top-up would require another full governance process. If the allowance runs out while a top-up is pending, new users cannot finish onboarding.

The larger allowance is bounded in several ways:

• it moves no funds;
• each unit is used only by onboarding one user;
• every registration is a public on-chain event;
• the remaining allowance is readable from storage at any time;
• governance can clear the allowance on either chain at any time.

When the allowance eventually runs low, PCF would request a top-up before onboarding pauses. If the Fellowship or the community prefers a smaller first tranche, PCF is open to that.

Base App Names and Storage

The three granted names belong to base apps published for the Polkadot App:

dotNS reserves names of five characters or fewer for governance. That is why these names need a governance grant instead of being registered directly.

The app files themselves are stored on the Bulletin chain. PCF pays for that storage without any governance grant.

PCF registers lite personhood for itself with PeopleLite.register_with_fee, a one-off fee of 75 DOT. Each lite person can then claim about 10 MiB of Bulletin storage every 14 days with Resources.claim_long_term_storage. Claims and uploads pay no transaction fees.

Data on Bulletin is kept for 14 days, so each app is stored again every 14 days. The files are the same, so the address the .dot name points to does not change. New releases use the same storage flow.

In total, this is about 225 DOT once for the three apps, with no recurring cost beyond running the re-stores. This assumes each app stays under about 10 MiB.

Prior Review and Changes

PCF first discussed this request publicly with the Technical Fellowship on the Polkadot Forum and in the Fellowship open channel.

The first version had five calls. After Fellowship feedback, PCF made three changes:

• Removed the Bulletin storage authorizer. App storage on Bulletin can be bought without governance through paid lite personhood on People, so a governance-granted storage budget is not needed.
• Fixed the enactment block. The referendum will not enact before 22 October 2026, even if it passes earlier. The Fellowship whitelist must reach Asset Hub by relay block 33525098, about 21 October 2026, 09:00 CEST.
• Published everything needed to reproduce the call. The call data, hashes, decoded calls, preflight checks, dry runs, and rehearsal are all in the release.

How to Verify It

The verification release includes the call data, decoded call breakdown, and the reports used to check the proposal.

It covers three types of checks:

• Preflight on live state: confirms that both allowances are currently empty, no dispatcher is set, and the three names are open and unregistered.
• Dry runs on live state: runs every call with the origin it will have at execution time. The referendum currently fails only with CallIsNotWhitelisted, as expected, until the Fellowship whitelist lands.
• Full rehearsal on a fork of live Polkadot: enacts both referenda through the scheduler and confirms the final state: each allowance moves from 0 to 1,000,000, the dispatcher is set, and the three names move from open to granted.

To reproduce the checks:

git clone https://github.com/Polkadot-Community-Foundation/pcf-refs
cd pcf-refs
npm ci
npm test
npm run decode
npm run preflight
npm run dry-run
npm run rehearse

The proposal README explains each call, what each check proves, and how to compare this referendum with Fellowship referendum #639 at the byte level.

Known Trade-Off

The Fellowship raised one important limitation, and PCF agrees that it should be stated clearly.

The dotNS gateway calls the dispatcher with Root origin. The dispatcher is an upgradeable contract owned by PCF. If PCF upgraded that contract with an illegitimate version of the source, the new code could call other contracts that trust Root origin, such as the dotNS name whitelist.

That does not give system-level Root access. It cannot upgrade the runtime, spend from other accounts, or act as Root over XCM. Still, it is a real trust assumption until the next fix lands.
The necessary changes have already been notified to both parity and the fellowship such that a future runtime version can own the contracts in this referendum:

• https://github.com/paritytech/individuality-community/issues/195
• https://github.com/polkadot-fellows/runtimes/issues/1326

Until the improvements are enacted, any upgrade would also be a public on-chain event. If the community wants a stronger interim guarantee, PCF can place dotNS ownership behind a public time delay that a referendum can veto.

Governance Keeps Control

Everything this referendum changes can be reversed by governance.

Once a name is registered, it can no longer be revoked this way. dotNS names do not expire, so a registered name stays with its owner unless the owner transfers it. If governance later prefers a different holder for any of the three names, PCF will transfer it.