Initial thoughts
The PRIMARY project is designed to be a monolithic new undertaking instead of reusing already existing solutions in the space. As PRIMARY is using the EOS network for their main public blockchain infrastructure, there are numerous stable coins and decentralized exchanges being born there, like EOS native stable coins, and EOSFINEX, EOSDEX and newly incoming FINDEX for decentralized exchanges.
The PRIMARY token utility model is sound, however, the 4.5 section of the whitepaper describing rewards needs clarification, and the PRIMARY token itself is subject to be considered as an investment security. However, not setting the hard cap and maximum supply of the PRIMARY token raises questions about the possibility of uncontrolled hyperinflation. What guarantees the value of the PRIMARY token after it is being sold out in the ICO and then placed in the market? What are the conditions of expanding the PRIMARY token’s existing supply? These questions are not answered in the whitepaper.
Tokens based on EOS also cannot be compliant to ERC20 standard as EOS actions do not support case-sensitive names. Balance retrieval is also not a getter method but rather a query to the EOS network with table query parameters. It looks like at the moment of writing the whitepaper nobody from the project's tech team had their hands on any information about EOS smart contract development, just external statistical numbers which were far off the reality as well.
Concerns about Smart Contract Implementation
The technical implementation of a smart contract to a user interface is completely left out from the whitepaper. How will users interact with these smart contracts? How will the events of ENERGY acquisition for participation in the network events be registered to the users? For example, when 1000 people attend a conference and there is a physical check-in during the conference to ping each registered participant (a feature described in the whitepaper) how will these users actually perform that check-in?
We have to assume they all will have their EOS account, and phone on them which will be charged and turned on, and no one will experience any technical glitches (which never happens in the real world). Then all these mobile users would need a working EOS wallet on their smartphone or mobile device with the ability to sign transactions of not native EOS functionality (no such wallets are in existence yet as of August 2018), there still will need to be a way to physically interface with them without inconvenient disturbance to the event itself.
Plus, if there will be no physical identity recognition, what will prevent users from checking in remotely? EOS has no interface to the physical world so there is no possibility to determine how and where the transaction was signed.
Conclusion
I think PRIMARY should focus on the specific problem they have set out to solve, and then add features as they develop post-launch. Do research on EOS development and update the whitepaper accordingly. And try to leave out anything related to real life policing as it will not work due to the nature of physical to digital interface through human input.