Validator Metadata DApp Auto Running of POPA DApp

DISCLAIMER: (Google Doc LINK) Please READ First (

The other day in the Core Telegram Channel an idea came up that I initially thought, “yeah - we ought to do that”. That idea centered around the notion that when a validator uses the POA DApp for Proof-of-Physical-Address ( then perhaps the validator’s metadata ( should then be automatically updated. Basically:

POPA → Metadata

Again, at the time, I was all for this. But it was late at night and I think that everyone was/is keen on removing points of friction. As I can only speak for myself, I’ll refer to only myself from now on.

I am now suggesting that the better route would be:

Metadata → POPA

And as we know from studying if/then statements in school - direction matters.

Backing up a bit. I love to optimize systems. I’ve been known to spend weeks of effort to effectively shave off a few clock cycles - basically, I’m an idiot (I’ve been fortunate never to have been employed in CIS so I am afforded this insanity.) So when the initial idea was presented, I loved the idea of saving ‘time’ at all cost. Then I woke up the next day and while brushing my teeth realized an error of logic.

Firstly, what exactly are we trying to do and, more importantly, why? Validators are staking their identity and one component of this is an address. NOTE: the term “address” is complex and beyond the scope of this posting, so we will use a working definition: You can get a postcard.

When a validator presents an ‘address’, there is no “trust but verify” - rather there is “verify”. One of the duties of the validating set is to ensure all of other validators have provided an address that is ‘correct’ (again the exact nature around type of address is beyond the scope of this post).

So the goal under consideration for this post is the staking of an address.


The value of POA Network (again I’m only speaking for myself) is not as a cryptocurrency but rather as an Enterprise ready DApp platform. Basically, the network’s true value is in making stuff (other DApps) work. Why would someone select us over others? Because we offer a link connecting two worlds together: blockchain and traditional legal frameworks. Companies understand the latter and would like to explore the former. So being able to explain to the various levels of a corporation that actual human beings are tied to the running of a “blockchain based platform” gives them the assurance and comfort in taking those beginning initial baby steps. This is how this technology wins, slow and steady. (Again all of this is my own views - and no one else’s potentially). So we need to communicate to all that actual humans are doing this work, and human exist somewhere - with this ‘somewhere’ typically referred to as an ‘address’.

But isn’t POPA enough?

Well, no. Firstly, what does this DApp do? It creates a link between a key and an address. The idea being that it is trying to establish a control relationship between these two ‘things’. I.e. someone claiming to be “Jeff” controls this key which is linked to physical control of a mail receptacle in which to receive a postcard.

I will be assuming that the third party service/API that actually generates the postcard is ‘secure’. I’m also assuming that the mail delivery chain is also ‘secure’. Again, in any scientific inquiry there will be assumptions - you may or may not agree with these. I do believe that this could be itself another post. But for the purposes of this post, let us make this working assumptions.

Did we prove that Jeff lives at (and staked) an address?

Ans: No. (Hence the quotes around Jeff)

We have only demonstrated that a cryptographic key is associated with someone at said address.

This is significant in its own right, but this is not the original goal. I.e.: Jeff staking an address. We need to get “Jeff” into this equation.

This is where governmental attestation and the critical thinking/work of the entire validator network comes into play. Ideally for me (Jeff) to show that I have some address, I demonstrated more than simple physical access to a mail receptacle.

POA Network seeks to solve this issue through the requirement that all validators are Public Notaries. To become a Public Notary, ideally you will have had to show proof to a governmental agency of sorts. This attestation mechanism is the way that trust is built up. If you ‘trust’ that a governmental agency created a procedure on becoming a Public Notary and ‘trust’ that this process was followed by all parties, then said individual can be afforded this level of ‘trust’. Recall the transitive property from algebra.

A = B and B = C, then A = C

Trust Chain: Govt = Notary Process and Notary Process = Individual, then Gov’t = Individual
(Where we are tracking an acceptable level of trust.) I am grossly over simplifying … but I think we can understand.

So governmental attestation is a necessary condition. Is that enough? No. We now have the whole problem behind oracles - or rather: how to get information from the real world into a blockchain.

This is where the other validators come in. If you believe that the majority of the validators, beginning with the first three were/are legit then we can leverage them in a sort of law of large numbers manner. I’m going to be adding this too my list of working assumptions…

This now trusted set of validators can take in information from a trusted source (that whole gov’t attestation) and ensure that this has been information has been correctly entered into the blockchain. The entering of the data into the blockchain is exactly what the metadata DApp is for. Then it requires two validators (at the time of this posting) to verify this information by polling a governmental source (such as a governmental website listing all known notaries, their commision number, and address of record.)

So we have demonstrated the following set: (Jeff, Address)

This being the meat and potatoes that a corporate user would like to be assured of. These organizations typically understand how to send a subpoena should they feel strongly enough about a potential issue.

But what about that “key”? Though this is important, the POPA DApp isn’t setup at present to require any verification from the other validators. And again, it is this outside verification - using the other validators as oracles.

Put another way, we can think of POPA as the cherry on top. This DApp provides us with the following set: (Key, Address)

Using a generous helping of working assumptions we are finally in a position to perform the following:

(Jeff, Address) & (Key, Address) -> (Jeff, Key, Address)

We now have an association that spans the person, an address, and a voting key.

Since there is no verification for POPA outside of the physical control of a mail receptacle, the heavy lifting is performed by the metadata DApp. Therefore, I do think we could maybe have it that once a person has correctly used the validator DApp and all the information has been checked out by other validators using outside sources, then perhaps the whole postcard thing of the POPA is automatically run.

Of course this would require significant work to implement, as these DApps are not presently set up like this.


An idea to save time was to automatically update a validator’s metadata once they ran the POPA DApp; however, this is not correct. Perhaps though once the validator metadata DApp has been run, then the POPA DApp could be automatically called upon. This would require work to be performed on these DApps.

1 Like

Thought provoking post, Jeff! I’ll join in with an interpretation and additional point of view. The following outlines only activity after a person has become a Valdiator. This post does not attempt to cover the process and possible steps involved in becoming a Validator.

  1. Validator is elected via on-chain ballot. The first responsibility of Validator once their node is in place and successfully processing blocks is to fill in MetaData (an associated address) that can be verified by agents of the State of their Active Notary Public status. This is usually the Secretary of State, Clerk of Court for State or County, or similar governmental arm.
  2. To be clear, all Validators must be in compliance with Notary Public statutes of their State of Residence. All States have different rules, some similar and some quite different. Regardless of individual State rules, addresses submitted to the State in question are subject to statue. Falsifying information to the State is at least a criminal misdemeanor and often much more serious crime, along with possible federal crime for interstate fraud; there is significant incentive for strict compliance on the part of Validators.
  3. Validators must use an address that can be verified by their State as legal and legitimate. Therefore, the Proof of Physical Address (POPA) DApp when used as a verification method for Validators should ONLY be used (sent) to the address listed in Validator MetaData.
  4. While there are legitimate use cases for POPA to verify control over an address, the POPA DApp as a Validator verification tool is only useful once a Validator has been elected and has posted their legally verifiable data. At this point, the Validator has staked not only their reputation and identity, they have given their legally binding oath to the State that this information is true.

As outlined above, the work on the POPA DApp is complete, as long as other Validators or other people interested in using the POPA DApp understand that it is their responsibility to verify with the authoritative governmental agency that the address information listed in MetaData is actually associated with the Validator or person presenting that address as demonstration of validity.

Thanks again for the interesting subject and post, Jeff. Discussions like this help provide clarity to why Proof of Authority Consensus can be extremely efficient and trustworthy.

1 Like

Agree with all points. Again:

A Validator must be vet’ed by the Validating set (all the others) and elected. Then their information is put on Blockchain via DApp. The really important bit - the other validators need verify the information using ‘trusted’ channels.

These trusted channels could be visiting a gov’t website that publishes this information, calling said agency, or even dropping in (if possible). But it must be something that does not require trusting information from the individual.

I like the POPA DApp - but it really is just a “cheer on top” in my view. After all of this has been done, seeing a little green check is nice.

1 Like