This referendum substitutes referendum #1955 with a reduced scope. It keeps only the onboarding parameters, the attestation allowances and the dispatcher, and leaves the base app names for a separate proposal later, so that each decision can be voted on by itself. Its Fellowship whitelist, Fellowship referendum #664, also removes the call of #1955 from the whitelist, so #1955 can no longer take effect.
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 it 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. It does not upgrade any runtime, deploy new code, or request Treasury funding.
| Track | Whitelisted Caller |
| Requires | Fellowship whitelist in Fellowship referendum #664 |
| Substitute for | Referendum #1955 |
| Can enact from | Relay block 33698272, about 2 November 2026, 09:00 CET. Fellowship referendum #664 was proposed before relay block 33583072, so its whitelist reaches Asset Hub before then |
| Inner call | 0x33ed6c42bb4078327a29bf59f8cb34c9df2f93703c3c624e47dc967b4a4af03f (118 bytes) |
| Preimage | 0x681f287489eea7db8bf4a37c03d4f8f861fa69565c313aa5e45dbf1a6ff29325 (120 bytes), noted on Asset Hub |
| Verification release | pcf-refs release |
The referendum contains three existing calls, bundled together and executed with Root through the Whitelisted Caller track.
| Call | Result |
|---|---|
DotnsGateway.increase_attestation_allowance(attester, 1,000,000) on Asset Hub |
Allows the attester to reserve up to 1,000,000 user names through the dotNS gateway. |
DotnsGateway.set_dispatcher_address(0xA06d1CB1e3FedFF7b5dFa779b4Cc61703F8A46A1) on Asset Hub |
Points the gateway to the dotNS PopController from the live dotNS release. |
PeopleLite.increase_attestation_allowance(attester, 1,000,000) on People, sent from Asset Hub |
Allows the attester to register up to 1,000,000 lite people. |
The main parameters are:
| Parameter | Value |
|---|---|
| Attester | 15sDLj4T9NnCtT665koDMxBs1PZw3rzDc6wcz9tN9kKTQ2zj |
| Allowance | 1,000,000 on Asset Hub and 1,000,000 on People |
| Dispatcher | 0xA06d1CB1e3FedFF7b5dFa779b4Cc61703F8A46A1 |
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.
.dot names; It only sets the parameters listed above.
There are two important accounts in this proposal: the attester, which handles user onboarding, and the owner of the dotNS contracts, which can upgrade the dispatcher.
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 dotNS contracts owner, or the dotNS contracts.
The response path is clear:
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.
The dispatcher is an upgradeable proxy. Its 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, 12mD2ibwcFiVNiDrzcjXHvsz7aDhgkCdY1Do8wUyhzSX6S9a, 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.
Each new user consumes one allowance unit on each chain:
.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:
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.
PCF first discussed this request publicly with the Technical Fellowship on the Polkadot Forum and in the Fellowship open channel.
The request first had five calls. After Fellowship feedback, PCF removed the Bulletin storage authorizer (app storage on Bulletin can be bought without governance through paid lite personhood on People), fixed the enactment block and published everything needed to reproduce the call. That is the currently proposed version: referendum #1955, whitelisted by Fellowship referendum #639.
This substitute makes two changes:
0x90640a174e1d62b5645f31cb053d562e95a63881fd1e0f9197edbbcf83e21fad) from the whitelist in the same step that whitelists this one. After that, #1955 can only enact without effect, so the allowances cannot be granted twice.The enactment block is fixed again, so the referendum does not enact before relay block 33698272, about 2 November 2026, 09:00 CET, even if it passes earlier. Fellowship referendum #664 was proposed before relay block 33583072 (about 25 October 2026, 09:00 CET), so even with its full 7-day decision period its whitelist reaches Asset Hub before then. If this referendum is approved after 2 November, it enacts 10 minutes after its approval, until its 28-day decision period ends.
The verification release includes the call data, decoded call breakdown, and the reports used to check the proposal.
It covers three types of checks:
CallIsNotWhitelisted, as expected, until the Fellowship whitelist from Fellowship referendum #664 lands. 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 #664 at the byte level.
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:
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.
Everything this referendum changes can be reversed by governance.
| Change | How governance can undo it |
|---|---|
| Attestation allowances | Call clear_attestation_allowance on the relevant chain. |
| Dispatcher address | Call set_dispatcher_address with a different address. |
This is a vote to turn on the settings that let new users join the Polkadot App.
.dot name on Asset Hub..dot names granted.This referendum substitutes referendum #1955 with a reduced scope. It keeps only the onboarding parameters, the attestation allowances and the dispatcher, and leaves the base app names for a separate proposal later, so that each decision can be voted on by itself. Its Fellowship whitelist, Fellowship referendum #664, also removes the call of #1955 from the whitelist, so #1955 can no longer take effect.
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 it 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. It does not upgrade any runtime, deploy new code, or request Treasury funding.
| Track | Whitelisted Caller |
| Requires | Fellowship whitelist in Fellowship referendum #664 |
| Substitute for | Referendum #1955 |
| Can enact from | Relay block 33698272, about 2 November 2026, 09:00 CET. Fellowship referendum #664 was proposed before relay block 33583072, so its whitelist reaches Asset Hub before then |
| Inner call | 0x33ed6c42bb4078327a29bf59f8cb34c9df2f93703c3c624e47dc967b4a4af03f (118 bytes) |
| Preimage | 0x681f287489eea7db8bf4a37c03d4f8f861fa69565c313aa5e45dbf1a6ff29325 (120 bytes), noted on Asset Hub |
| Verification release | pcf-refs release |
The referendum contains three existing calls, bundled together and executed with Root through the Whitelisted Caller track.
| Call | Result |
|---|---|
DotnsGateway.increase_attestation_allowance(attester, 1,000,000) on Asset Hub |
Allows the attester to reserve up to 1,000,000 user names through the dotNS gateway. |
DotnsGateway.set_dispatcher_address(0xA06d1CB1e3FedFF7b5dFa779b4Cc61703F8A46A1) on Asset Hub |
Points the gateway to the dotNS PopController from the live dotNS release. |
PeopleLite.increase_attestation_allowance(attester, 1,000,000) on People, sent from Asset Hub |
Allows the attester to register up to 1,000,000 lite people. |
The main parameters are:
| Parameter | Value |
|---|---|
| Attester | 15sDLj4T9NnCtT665koDMxBs1PZw3rzDc6wcz9tN9kKTQ2zj |
| Allowance | 1,000,000 on Asset Hub and 1,000,000 on People |
| Dispatcher | 0xA06d1CB1e3FedFF7b5dFa779b4Cc61703F8A46A1 |
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.
.dot names; It only sets the parameters listed above.
There are two important accounts in this proposal: the attester, which handles user onboarding, and the owner of the dotNS contracts, which can upgrade the dispatcher.
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 dotNS contracts owner, or the dotNS contracts.
The response path is clear:
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.
The dispatcher is an upgradeable proxy. Its 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, 12mD2ibwcFiVNiDrzcjXHvsz7aDhgkCdY1Do8wUyhzSX6S9a, 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.
Each new user consumes one allowance unit on each chain:
.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:
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.
PCF first discussed this request publicly with the Technical Fellowship on the Polkadot Forum and in the Fellowship open channel.
The request first had five calls. After Fellowship feedback, PCF removed the Bulletin storage authorizer (app storage on Bulletin can be bought without governance through paid lite personhood on People), fixed the enactment block and published everything needed to reproduce the call. That is the currently proposed version: referendum #1955, whitelisted by Fellowship referendum #639.
This substitute makes two changes:
0x90640a174e1d62b5645f31cb053d562e95a63881fd1e0f9197edbbcf83e21fad) from the whitelist in the same step that whitelists this one. After that, #1955 can only enact without effect, so the allowances cannot be granted twice.The enactment block is fixed again, so the referendum does not enact before relay block 33698272, about 2 November 2026, 09:00 CET, even if it passes earlier. Fellowship referendum #664 was proposed before relay block 33583072 (about 25 October 2026, 09:00 CET), so even with its full 7-day decision period its whitelist reaches Asset Hub before then. If this referendum is approved after 2 November, it enacts 10 minutes after its approval, until its 28-day decision period ends.
The verification release includes the call data, decoded call breakdown, and the reports used to check the proposal.
It covers three types of checks:
CallIsNotWhitelisted, as expected, until the Fellowship whitelist from Fellowship referendum #664 lands. 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 #664 at the byte level.
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:
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.
Everything this referendum changes can be reversed by governance.
| Change | How governance can undo it |
|---|---|
| Attestation allowances | Call clear_attestation_allowance on the relevant chain. |
| Dispatcher address | Call set_dispatcher_address with a different address. |