| Report Date | Date of submission 2026/02/24 |
| Submitted by | George Pisaltu |
@george.pisaltu:parity.io128pmEUBSGjGeXZXNaAmomAJgVn77L74YT7Zdjd3fP63HWNP22024/08/162026/01/23Proof of Personhood, System Parachains, FRAMEI have been part of the fellowship since August 2024 and I have been working on Polkadot technology since July 2023. During this time, I have continuously expanded my knowledge on everything substrate and FRAME and contributed to multiple layers of the stack. I have also designed and implemented new functionality to existing pallets, creating the Polkadot experience of tomorrow for our users through my contribution in leading the Proof of Personhood development. I am applying here for a fast promote to rank 3 and hope existing Fellows agree with me that my existing contributions are sufficient in breadth, depth and complexity to justify rank 3 in the Fellowship.
The rank 3 requirements in the manifesto state:
Either played a supporting role in the ideation and a primary role in the formalisation of a major protocol component; or played a supporting role in the code-design and a primary role in the implementation of a major protocol component.
I have been working on Proof of Personhood for 2 years now and we have already made public the first
piece of the puzzle: The People
Registry, as defined in
pallet-people, and its adjacent structures. Since then, the ring management logic in
pallet-people has been abstracted away into a members pallet, which is currently live on a Paseo
parachain for users to interact with, soon to be open-sourced. I am the technical owner of the
project and I am responsible for the technical design and implementation of all of its elements: the
people registry, DIM1, DIM2, people incentive schemes, free transactions and the delivery of all of
this to the Polkadot People chain, with more components planned and in the specification drafting
phase to be delivered in the future.
From the rank 3 expectations in the manifesto:
becoming a Fellow indicates the individual has enough knowledge and skill to build substantial protocol components (i.e. all but the major protocol components, e.g. a pallet or 2-10,000 line crate) alone and with high expectations that they will be completed correctly and to a high standard
I am the core contributor of the people registry, member set, DIM1, people incentive scheme. I am also the main contributor and advocate for the free transaction model through my work in Extrinsic Horizon. I led the effort to develop both DIM1 and was heavily involved in the design of DIM2, imminently available for general use with the launch of the Polkadot app. The DIMs' specifications will be made public with their introduction in a People chain runtime upgrade and, as such, I cannot go into the technical implementation and details in this letter. The DIMs have been released on a Paseo parachain for users to interact with before the source code was made open-source.
A rank 3 member is expected to show:
Demonstrable presence of knowledge sharing within the ecosystem.
I have been holding internal knowledge sharing sessions with people working on current and future Polkadot core protocol elements as well as people building future applications on the core PoP technology. These discussions have not been public due to the reason mentioned above, but I have had multiple talks on:
The People registry is kept in pallet-people, which stores and manages identifiers of individuals
who have proven their personhood. It tracks their personal IDs and their associated cryptographic
keys, and allows them to use contextual aliases through authentication in extensions. The People
registry uses the new pallet-members as a service for the management of the rings in which
people's keys are included. The system also grooms the rings through defragmenting and ensures
members are onboarded in batches to preserve privacy.
The People pallet implements an interface allowing any DIMs to recognize and suspend personhood. I created a dummy DIM to act as a control panel wherever the People registry is deployed in test environments, and will be extended to become a production ready tool for governance to easily interact with the people set.
The expectations of a rank 3 member are:
Occasionally innovative in API & code design, adapting/importing/inventing ideas that lead to effective solutions
People are identified through a new cryptographic primitive, as defined in the
verifiable crate. People get the privilege of running
free transactions for supported calls through new TransactionExtension implementations and custom
origin types. I was a crucial contributor to the design and implementation of the member ring
solution using ring VRF cryptography, mitigating member privacy risks when onboarding a ring while
avoiding stalls in the onboarding queue.
When transactions include cryptographic proofs of belonging to the people set, the pallet's transaction extension verifies these proofs before allowing the transaction to proceed. This enables other pallets to check if actions come from unique persons while preserving privacy through the ring-based structure. I played a critical role in the design and reference implementations of the extension model we use to provide free transactions for recognized people.
I designed and implemented an incentive mechanism for people who participate honestly and consistently in the activities available in the first Proof of Personhood release, from taking part in the recognition process themselves (going though the DIMs) to facilitating other people's application process (i.e. people fulfilling the role of oracle for candidates' evidence in DIM1). All of the rewards will be handed out periodically on-chain through payment rounds and distributed to participants proportional to their contribution to the system.
As the rank 3 expectations in the manifesto state:
The individual should by now be thinking in a very much in a security-conscious, game-theoretic way, understanding that the systems whose design they are increasingly a part of must function adequately even with a modest minority of malicious users.
The incentive provided to people is to always contribute, but especially so when there is low activity, since the reward share of a single participant will be greater. The pallet allows a privileged origin to set a certain amount as a reward for the ongoing payout round, so participants do not know ahead of time how much one vote is worth. This system avoids two distinct scenarios which lead to fewer votes (and less confidence in the outcome):
Initially, the rewards were available to participants only through a privacy voucher mechanism leveraging the existing ring architecture to ensure that whoever is withdrawing a reward preserves their privacy. This has been superseded by coinage, a UTXO-like private payment mechanism to which I contributed in the design phase. Unlike the privacy voucher mechanism, coinage is open to permissionless use.
The origin system was designed to allow authorized entities to run free transactions in certain contexts. In addition to allowing all on-chain activities to be performed for free by proven people and candidates for DIMs, entities which have an authority's backing as being reasonably unique (through a less strict mechanism than the DIMs) will also get a lesser amount of weight allocation to submit their transactions for free (i.e. send funds to another account, for free). This will enable the Polkadot app to provide UX which is at least as good as traditional services, which allow people to send money to each other within the app for free.
I played an active role in developing, designing and improving core features of the
TransactionExtension interface to polkadot-sdk, phase 1 of Extrinsic
Horizon. The main purpose of the new
interface is to allow for custom origin authentication and mutation before dispatching a call in a
transaction. This, in turn, provides the machinery in substrate to enable free transactions, i.e.
valid transactions run by users without funding an account with the existential deposit or any funds
to pay for transaction fees. This is a huge development in substrate-based chains, which previously
could only function on signed or unsigned transactions, heavily relying on the account model.
I oversaw the delivery of
TransactionExtension with all that it
entailed. While I discussed the TransactionExtension effort before in greater detail, I will
summarize the technical contribution as:
TransactionExtension operations and introduced benchmarks and weights for
existing extensionsThe implementation in phase 1 of Extrinsic Horizon paved the way for a clean implementation of
phase 2, which was designed to use the custom
origin authentication in TransactionExtension to replace unsigned transactions and
ValidateUnsigned with a custom origin specific to each pallet which would bypass the fee and nonce
transaction extension checks. I contributed the design of this feature and I was involved in the
discussions behind its implementation as well as the reviews.
For more information about the TransactionExtension contribution and its impact, please refer to
this long-form semi-technical forum
post where I explain the
feature to the community.
While Proof of Personhood has been and remains my main focus, I have contributed in other ways to substrate and FRAME and I wish to continue to do so. Aside from reviews, my other notable contributions are in the identity pallet, where I pushed a refactor to decouple usernames from identities, along with a migration for existing instances of the pallet, and support for personal usernames, which are system allocated usernames for recognized people.
While I have been contributing to Polkadot core protocols or components for more than two years now, I was late to officially join the Fellowship, therefore showing a shorter tenure on-chain and applying for the fast promotion.
Most of the components of Proof of Personhood are now publicly available on testnets such as Paseo, but the source code will be open-sourced at a later date. I accept that the arguments which could be made in this letter may be incomplete, but I will support my case to fellows before this argument is put to a vote and answer any and all questions regarding my contributions.
The launch of the project live on the Polkadot people chain is imminent. When that happens, I believe that the Fellowship will need a member of rank3+ as an owner and main contributor of these features, as I believe is the case concerning all other core protocol features. I have been in the position to lead the development of this project and wish to continue to do so and extend my role and my responsibilities in the Fellowship as a rank 3 member. This can only happen on the fast promotion path and I hope that the evidence I present in this letter justifies this.
TransactionExtension| Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
| I | 90% | N/A | ||
| II | 80% | N/A | I have voted on 0 out of 0 referenda in which I was eligible to vote (i.e 0 % voting activity). | |
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Question(s):
Concern(s):
Comment(s):
Threshold