# Litepaper (draft version) Polyzoa website: [www.polyzoa.xyz](https://polyzoa.xyz/) X: Telegram: API: ### Table of content ## Contents Tokenomics (work in progress) Tech Architecture Poly-graph ML ## 1. Project Overview ## The problem The Web3 ecosystem and its stakeholders continually find themselves in the crosshairs of various types and scales of criminal activities. Despite claims of increasing safety and reliability, the reality often reflects a mere "crypto winter" lull, where the decline in on-chain activity corresponds with a temporary drop in victim counts. As the market heats up again with another bull run, the incidence of crypto-related crimes, including scams and fraud, is not only surging to new heights but also shows no signs of abating. A stark reality within the Web3 space is the limited economic incentive for the growth of security projects, as the majority of initiatives are more concerned with safeguarding their own funds and liquidity. A significant chunk of security services, financed by DApp builders and blockchain ecosystems, revolves around smart contract audits and protection against attacks targeting liquidity, such as flash loan attacks, miner extractable value (MEV) exploits, or sandwich attacks. While these security challenges are crucial and somewhat more straightforward to tackl, often based on recognizable patterns that heuristic logic can easily identify, they typically offer one-off protection rather than continuous security. Before-launch security measures, including testing and audits, are essential but insufficient for identifying all potential risks and exploits. The delayed response to attacks and the rise of zero-day vulnerabilities exacerbate the damage. Transaction-based crimes like social engineering, scams, phishing, or money laundering pose unique challenges, demanding a deep understanding of the crime's off-chain context. Hence, the critical need for comprehensive system scanning for threat detection and prevention, widely referred to as runtime security, on smart contracts is ever more apparent to mitigate risks and prevent losses. In many instances, early threat detection and swift response mechanisms could have significantly reduced or even prevented losses, offering users enhanced protection by alerting them to potential threats in time to take preventive action. While many security solutions capitalize on high-profile scams for PR and marketing, the reality is that these scams are often identified post-factum. Few existing "real-time" solutions can guard against nascent threats that haven't yet captured widespread public attention, leading to a false sense of security and an ineffective response to crypto crime. The overdependence on centralized security services and solutions in the Web3 ecosystem presents formidable obstacles to the development and scaling of decentralized applications. These "black box" solutions fail to deliver fresh and relevant risk data, often providing conflicting information that leaves significant security gaps. With 99% of blockchain security solutions unable to offer up-to-date and pertinent risk data, builders are forced to invest heavily in black-box security measures that rely on human intelligence, rudimentary algorithms, and outdated databases, all without verifiable proof of their efficacy. To align with Web3 principles, the paradigm must shift towards security tools that are decentralized, reliable, and scalable, ushering in a new era of blockchain application development rooted in these core values. ## Polyzoa solution Polyzoa addresses this critical issue with its permissionless risk assessment platform, ensuring developers can build by leveraging the maximum available and trustless security. Polyzoa builds a decentralized risk protocol that is focused on assessing risks and detecting scams and fraud within the blockchain ecosystem. As the number of blockchain applications and projects continues to grow, the need for a secure and reliable system to identify and verify potential risks has become increasingly important. Polyzoa aims to address this challenge by leveraging its decentralized nature and advanced algorithms to provide accurate and unbiased risk assessments. Polyzoa serves as a focal point for risk data providers, validators, and consumers. ## Key Principles and Values in Polyzoa's Security Ecosystem ### Permissionless Risk Assessment for Enhanced Security in Web3 Polyzoa is pioneering the effort to democratize access to risk assessment, envisioning a future where developers can effortlessly integrate a "by default" security layer into the core of their products across various blockchains. Polyzoa’s mission is to build essential security infrastructure for developers aiming to create safe, customer-centric decentralized applications with real-world utility, ready to provide high-scale security for the mass market. ### Openness and Incentivized Participation The Polyzoa ecosystem is designed with openness at its core, welcoming everyone to participate as a data provider and offering rewards for valuable contributions. This system ensures that only validated and unique data submissions are acknowledged and compensated, fostering a competitive environment among providers. Such competition motivates participants to deliver their data swiftly, ensuring the Polyzoa system remains constantly updated in real-time. This approach not only enhances the platform's efficiency and accuracy but also democratizes the process of data validation, making it a collective effort that benefits the entire community. ### Consensus Judgment for Maximum Result Objectivity Polyzoa aims to eliminate any single point of judgment regarding the risk level of an address. It establishes a consensus layer that acts as a collective mind to decide on the risk associated with the address. By encouraging and rewarding every player in the ecosystem to join the consensus, and by implementing strict penalty principles, it ensures that bad actors cannot manipulate or counterfeit results and the database. This structure means that actors producing invalid results lose any economic value by violating system rules. On the other hand, a good actor with high performance is incentivized to contribute more and maintain the quality and speed level of data at the highest level. By creating an open-door system for data producers, Polyzoa does not rely on a single security technology or source of data. This approach helps to find the best possible response for any current threat. ### Open-Source and Developer-Friendly Ecosystem Polyzoa’s design principles focus on openness and developer empowerment, offering seamless access to security data and risk assessments through a flexible, modular structure. This open structure ensures that security data is not only consumed but also provided and validated in a decentralized way, ensuring full unbiasedness and reliability. ### Tokenomic Model to Foster Innovation and Community Growth The increase in blockchain data production and the growing need for data storage highlight the necessity for a scalable and efficient tokenomics model. Polyzoa's tokenomics is crafted to leverage this growth, enhancing the network's value through expanded data storage, risk assessment, and community engagement. By offering incentives to data providers and validators via rewards and staking mechanisms, Polyzoa seeks to significantly lower the costs of risk assessment, thereby promoting security and trust within the Web3 ecosystem. Built on the principles of openness, data integrity, accessibility, and rewarding contributions, the Polyzoa ecosystem motivates community involvement with token rewards. This approach boosts the risk assessment process's efficiency and efficacy while providing a sturdy and dependable solution for the Web3 community. Encouraging active participation, Polyzoa solidifies its role in advancing a safer, more transparent decentralized economy. ### Decentralized Risk Protocol for Enhanced Security As decentralization is a core principle of the Polyzoa ecosystem's activity, let's clarify its definition. Polyzoa aims to decentralize security in several areas: * **Risk Data Storage**: It's crucial to have permissionless and fault-tolerant availability of risk data. That's why Polyzoa shards the storage among many Node providers, enabling maximized performance and availability. * **Data Production**: Polyzoa does not rely on a central point of judgment; instead, it decentralizes the decision-making on the risk level of a given entity. By building fair governance logic, Polyzoa provides only a weighted average decision by aggregating responses from many data providers based on their performance and speed. * **Risk Analysis**: Polyzoa's ML algorithms are set to be built, trained, and run in a decentralized manner. Any ecosystem player can set up their own Polyzoa ML node and provide risk assessments for rewards. Since data aggregation and training are also computationally costly procedures, they will be designed for open participation and contribution. Polyzoa distinguishes itself as a decentralized risk protocol focused on identifying and mitigating scams and fraudulent activities within the blockchain space. Its unique approach leverages decentralized oracles and advanced algorithms to provide accurate risk assessments, enhancing security and transparency across the Web3 landscape. ## 2. Key Polyzoa Services Polyzoa leverages its decentralized oracle network for blockchain risk assessments, identifying potential scams and fraudulent activities. It focuses on several critical services: ### Unlimited Threat Detection Functionality The Polyzoa protocol significantly enhances threat detection capabilities by allowing anyone to contribute information about new and previously unseen threats to the protocol, disseminating this vital data throughout the entire network. A robust consensus mechanism ensures the validity of the submitted data, allowing only verified information to be propagated. This open contribution model fosters a collective defense strategy, empowering the community to contribute to the ongoing enhancement of security measures and ensuring that the Polyzoa ecosystem remains at the forefront of threat prevention. Polyzoa acts as a security intelligence hub, continuously learning from a wide array of sources and adapting in real-time to emerging threats. From its inception, it has been designed to offer proactive protection, beginning with industry benchmarks and constantly refining its accuracy to achieve unparalleled levels of reliability in identifying risks. ### Real-Time Address Assessments Polyzoa is capable of conducting real-time assessments for even previously unknown addresses, thanks to its proprietary ML technology. Along with other network data providers Polyzoa’s ML nodes dynamically examines fund flow routes, captures each address's unique footprint, and compares it against an extensive database of on-chain threat patterns. As Polyzoa progresses, it plans to integrate more participants into its protocol for real-time address checks, ensuring a thorough and impartial risk assessment process. Through vigilant monitoring of on-chain activities and transactions, Polyzoa is adept at spotting patterns that signal scams, including rug pulls, phishing attempts, drainers, money laundering, and more. Its ability to discern these patterns enables it to safeguard the community against a wide spectrum of fraudulent schemes. ### Coverage Across Ethereum Mainnet and Major EVM Chains Polyzoa maintains an extensive database of fraudulent addresses within the EVM ecosystem and possesses the capability to dynamically identify unknown threats across all major L2 EVM chains. Looking ahead, there are plans to expand its reach to include more L1 chains and develop chain-specific solutions for detecting unique and genuine threats, thereby enhancing its comprehensive security coverage. ### Consumer Node For Locally Stored Risk Data Polyzoa allows anyone to become a private node holder. Such a node holds the full scope of Polyzoa's risk data and can be accessed locally at any moment. It maintains a constant connection with the network and is updated immediately. A Polyzoa private node offers unprecedented flexibility and speed of protection to infrastructure providers and node operators, even offering the possibility to install Polyzoa under the system firewall. ## 3. Risk logic at the smart contract level One of the biggest constraints in implementing security tools is the Web2 approach that the majority of security providers take. The requirement to integrate centralized APIs into the backend makes the project more complex and heavyweight. With such integrations, it becomes impossible to build a lightweight on-chain solution without off-chain dependencies. Polyzoa aims to solve this challenge, enabling dApp developers to build decentralized and legally compliant solutions simultaneously. Polyzoa makes it possible to incorporate security logic and flexible risk thresholds directly into smart contract execution. This allows builders to block fraud, money laundering, or other malicious transactions purely on-chain, without disrupting transaction execution or needing to call the backend. ## 4. Decentralized ML: The Core of Polyzoa's Innovation Machine learning, with it’s ability to predict attacks based on subtle (learned) transactional patterns, has opened new doors for protection against threats in the web3 universe. A well-trained machine learning model can capture the nuanced relationships and characteristics of different attack types, facilitating more accurate and insightful alerts. The landscape of web3 attacks is too complex for a single prediction model; instead, tailored models are needed, considering specific threats and associated labels, such as anti-money laundering regulations for DEX and concerns about [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack) for node providers. Despite diverse modelling needs, most applications can utilize the same graph structure in transaction networks, allowing for model creation with varying input variables and training algorithms. The PLZ-prediction toolkit, centered around a universal "threat graph" structure, facilitates ML customization for web3 by providing developers with open-source tools to train precise models tailored to individual threats, leveraging custom labels, tech-stacks, and hardware configurations to combat attacks effectively. Poly-graph, part of Polyzoa's decentralized machine learning network security, empowers nodes to create and utilize specialized models while incentivizing high-quality model development through token payments and rewarding feature developers whose contributions are incorporated into models, with models meeting accuracy requirements eligible for adoption and rewarding, ultimately contributing to the growth of the Poly-graph chain. The heart of Poly-graph is its provisioned machine learning (ML) engines, serving as both data providers and validators, where labels generated by Poly-graph's predictions are redistributed as alerts, and newly contributed alerts from the community are integrated into future models through a continuous training cycle to ensure their ongoing relevance and accuracy. ### **5. Ecosystem** The Polyzoa ecosystem is designed to act like a collective mind, leveraging the synergy of different Web3 security and protection approaches and services to combat cybercriminals. It offers multiple roles, allowing anyone to contribute while ensuring high accuracy, data validity, and availability. Polyzoa aims to deliver risk data directly to the core of blockchain architecture, whether on-chain or off-chain, where it is most needed by data consumers. Our network encourages anyone joining to become a data provider and earn rewards for valid contributions. We strive to unite Web3 security efforts and consolidate fragmented risk data into a single decentralized storage, accessible and verifiable by anyone. The data producer role is a key contributor position that can be filled by a wide variety of Web3 companies, organizations, and individuals. Risk data can be supplied by compliance agencies, country authorities, Web3 security solutions, DApps, and individual researchers. The Polyzoa protocol rewards all valid contributors and penalizes those who violate rules or supply false data, promoting ecosystem players based on their activity. | NAME | ROLE | | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Data consumer | A data consumer accesses data from node operators. A data consumer must have a sufficient amount of $PLZ in their balance and pay in $PLZ for every data request. A data consumer may become a full node provider. | | (Private Node consumer) | Private Node consumer maintain the entire Polyzoa security data set for their own purposes and to serve other data consumers. To be eligible for full node operator status, customers must pay a subscription in $PLZ. | | Node Operator | Polyzoa Nodes play a crucial role in the Polyzoa network, acting as intermediaries between collected and analyzed risk data and the smart contracts of decentralized applications (dApps), ensuring a stable and reliable data stream. Each Node stakes a certain amount of $PLZ tokens as collateral, guaranteeing reliable, honest, and high-quality performance. | | Node providers must guarantee data availability and are responsible for adhering to rules against data manipulation. | | | Data provider |

Data providers contribute their analysis data to the network. There are two types of data providers:

  • Simple Data Provider (SDP) acts as a data supplier, pushing new data when available, and gets rewarded in case of data validation. SDPs do not have the rights to participate in validation (Consensus layer).
  • Full Data Provider (FDP) has two-way communication with the Polyzoa network and must be able to provide risk status on demand. A Full DP must stake $PLZ to meet the trust threshold and is punished for rule violations. Each Full DP may act as a part of the consensus layer. Every submission of scam and threat data is validated by consensus, and after verification, is distributed throughout the network
| | Consensus layer | Consensus layer is a collective role that determines the validity of data received from Data Providers. | # Litepaper (draft version) Polyzoa website: [www.polyzoa.xyz](https://polyzoa.xyz/) X: Telegram: API: # Poly-graph ML Machine learning has significantly advanced protection against web3 threats by utilizing learned transactional patterns to predict attacks, leading to well-trained models adapted to Ethereum's intricate network structure (shown below).

The local neighborhood of a single address (center). The richness and complexity the transaction network is well captured using “graph” geometry of nodes (vertices) corresponding to address and their features, and connecting lines corresponding to transactions. The colorization of nodes corresponds to address type, e.g. smart contracts are shown in blue.

Accurate attack detection models provide significant time and resource savings to financial institutions through automation. Yet despite extensive academic research in machine learning focused on web3 security, the industry faces unique challenges that such academic research often overlooks, such as the need for efficient, real time analysis. Additionally, there's a tradeoff between usability and accuracy, where generic models prioritize broad applicability over precision. Generic models often get stuck prioritizing broad applicability over precision, leading to a large number of “false positives”. As a first line of defense, the industry has relied on the construction of blacklists (BLs), which are a primitive form of model called a filter. The BL idea is simple: create a registry of threatening entities and check potentially dangerous actors against it. While simple, BLs have several drawbacks. For one, they fail to provide real-time protection. As such, they are always one step behind new threats. In addition, from the perspective of web3, there are several intrinsic problems with the conventional BL approaches due to centralization. In a centralized threat registry like a BL trust is bestowed to aggregators, holders, and distributors of the data. If the labels are not meticulously validated along with their sources, such centralized blacklists quickly get corrupted and/or outdated and their usage becomes limited. Instead of centralization with BLs, we propose a distributed community effort, with data producers, validators, and a consensus mechanism to confirm the predictions. These key components generate in part the crucial data labels which get used in the machine learning engine, the details of which we describe below. The remainder of this section is outlined as follows. First, we present and describe an open source utility, called `feature-beast`, which allows ML inclined devs to construct new customized models and discuss how these models function in general. We then give a quick overview of our provisioned models that are benchmarked for accuracy and performance. Next we elaborate on how the components outlined in the tech architecture fit into the ML prediction sector. Lastly, we discuss how nodes can contribute their prediction models and the use of zero-knowledge proofs for verification of the standards/requirements contributions must meet for accuracy.

Show are pairs of phishing (left and leftmost) and benign transaction (right and rightmost) networks. The “jellyfish” geometrical patterns indicative of phishing are learned by prediction models, such a graph neural networks though a process called embedding, which uses mathematical representations of the historical transaction data.

### Feature Beast: Open Source ML Toolkit ML implementations for address classification come in many forms. In particular, graph neural networks (GNNs) excel in address classification due to their ability to learn geometric representations of hack, phishing, and money laundering patterns involving large sub-networks, instead of relying on “shallow” statistics involving one address and its senders and recipients. At the end of this section we also review a blueprint for future graph neural network implementation, as guided by the geometric deep learning program. In general, to build a trained address classification model, such a graph neural network, for generalized fraud prediction, one follows these steps: 1. **Data Preprocessing**: Collect transaction data from the Ethereum blockchain, representing nodes as accounts and edges as transactions between them. 2. **Feature Engineering**: Extract features such as transaction amounts, frequencies, and types, and encode them into node and edge attributes. 3. **Graph Construction**: Build a graph structure from the preprocessed data, where nodes represent addresses and edges represent transactions. 4. **Model Design**: Design an architecture tailored for classification tasks, in the case of GNNs incorporating message passing, convolutional, or attention layers to aggregate information from neighboring nodes and edges. 5. **Training**: Train the model using labeled data, optimizing the parameters to minimize a suitable loss function, such as cross-entropy loss. 6. **Evaluation**: Evaluate the model's performance using metrics like accuracy, precision, recall, and F1 score on a hold-out validation set. 7. **Prediction**: Apply the trained model to new transaction data to predict the likelihood of fraud for each target account, identifying suspicious activities for alert broadcast candidates. Once the architecture for the model is created it can be refined and tuned to new data labels as the arise through the implementation of a “training cycle” which keeps the model up to date. The a simple round of a training cycle process is illustrated in the diagram below.
Due to the diverse nature of web3 attacks, a singular prediction model proves ineffective, necessitating the utilization of tailored models aligned with specific threats, exemplified by the differing requirements between a DEX subject to AML regulations and a node provider concerned with Sybil attacks, although most applications can leverage the common graph structure of transaction networks, albeit with varying input variables and training algorithms. Polyzoa `PLZ-prediction-toolkit`, centered around the universal "threat-graph" structure, serves as the cornerstone for crafting customized prediction models tailored to individual threats within web3 transaction networks, providing developers with an accessible toolbox designed for this purpose. It allows ML developers to leverage their labels, individual tech-stacks, and hardware configurations to combat attacks in precise ways that would impossible with a generic broad spectrum prediction code. The `PLZ-prediction-toolkit` comprises the following essential components: an aggregator for efficiently harvesting transaction data, a groomer dedicated to cleaning and preparing the data with the labels, a sophisticated "feature beast" designed specifically for constructing intricate statistical features essential for modeling, and models used for predictions themselves. *Feature-beast: An open source feature construction tools* The f*eature-beast* component of the toolkit facilitates model construction by aiding feature generation. Polyzoa `feature beast`, a Python package, specializes in time series feature extraction to develop custom model variables, or "features," tailored for web3 security use, extracting statistical features from transaction history. It utilizes a unique mechanism that leverages blockchain data to characterize attacks and exploits within specific sectors, allowing for the creation of heuristic filters or model construction for phishing, ice-phising, AML, etc.
### Poly-graph: Decentralized Modeling Poly-graph is Polyzoa’s decentralized implementation of machine learning based network security. It gives autonomy to participating nodes to develop and use specialized models. Development of high quality models is incentivized by payment of tokens to contributors. Feature developers can contribute their features to a shared registry, the Polyzoa Feature Store, for evaluation. The features having the highest importance, as determined through their mathematical weights, may be incorporated into the provisioned models provided certain accuracy requirements are fulfilled (see below). Furthermore, as incentive, the developers are rewarded with $PLZ tokens, the amount of which is outline by the detailed tokenomics. ### *Poly-graph, the distributed network of prediction models* Deployable containers submitted to the community model registry, the Polyzoa Model Store, hold a distinct significance. Subject to content standardization, these models can be contributed for widespread adoption by validator nodes in exchange for rewards. Models meeting an accuracy requirement of 70% precision and 50% recall are eligible for adoption and subsequent rewards. Once adopted, broadcast models announce predictions as alerts for consensus evaluation, with validated predictions recorded into the "risk classification ledger," further expanding the Poly-graph chain constituents (see architecture section). ### *Provisioned Models* Polyzoa will offer a diverse range of pre-trained models, covering fundamental attack types, accessible to the community via a git repository. Additionally, Polyzoa will provide a stable release of benchmarked prediction models, known as `gr-eth**`, specifically designed for out-of-the-box address classification, catering to immediate prediction requirements and validator roles. Provisioned models come in two basic forms: heuristic and trained. *Logic-Condition Models (Heuristic Filters)* Heuristic filters enable rapid prediction with minimal computational burden, functioning through logical conditions aimed at identifying the most probable candidates efficiently. These filters serve as an initial screening mechanism to identify suspicious transactions for further investigation. Types of heuristic filters include: * **Anomalous Volume**: Flag transactions with unusually large or small amounts compared to the typical transaction volume for a particular account or network. * **Frequency Thresholds**: Identify accounts or transactions with abnormally high frequencies within a given time period, suggesting potential bot activity or spam. * **Blacklists**: flagging transactions involving known addresses associated with suspicious activities. Additional heuristic filters can be designed in particular using the plz-prediction-toolkit’s `feature_beast`. *Trained Numerical Models* Trained numerical models are those built using the 7 steps outlined above. We provide a trained phishing prediction model for Ethereum network addresses, the *gr-eth* classifier, deployable on any participating node to predict phishing and ice-phishing actors based on transaction history. Its features were constructed using labeled data from multiple sources and include: `X = {address, min sent, avg sent, min received, max received, txn cnt, unique received cnt, eff balance, amt received, time active, avg time bw sent txn, avg time bw received txn}.` The prediction algorithm employs extreme-gradient boosting and ensemble learning for both speed and accuracy, optimized through 5-fold cross-validation to minimize log-loss, while future iterations will feature a graph-neural-network predictor incorporating message passing and local aggregations between nodes. The associated training dataset will be released along with model to facilitate benchmarking etc. ### *Accuracy Criteria, Contributed Labels, and Distribution of Training Information* With the establishment of a distributed data set, or *threat-graph,* ML scientists and engineers to build prediction models which are in line with the philosophy of web3. As outlined in the consensus protocol sections, address scores are broadcasted to the validators for confirmation before being inserting into the threat-graph database. To recap, when a model prediction is finished, a prediction result message is broadcasted throughout the poly-graph network. Once the threat level has been verified by the consensus mechanism outlined in Sec.?, the participating Library nodes re-sync their registries and update their threat-graphs with the new information. Addresses having a validated prediction score which exceeds a preset threshold risk value of 0.65 are broadcasted as a generalized alert. In addition we also let participants who want to run their own nodes, the so-called eagles, set their threshold based on their false positive rate requirements, but the (sentry) nodes running the shared models must conform to certain requirements of accuracy to avoid missed cases and to minimize false positives. ### *Monitoring* In addition to the threat-graph being updated with the prediction, newly formed label information is tagged with metadata about the model, date, etc, and then added to a data lake by the Librarians (see Tech section) to be kept to monitor the models for prediction skew. The monitoring helps counteract slippage between the training data and the actual predictions from new incoming data, and thus keeps the models, and therefore also the sentry nodes, up to date with the latest threats. ## Appendix: ### Terminology *Supervised Classification* Supervised classification uses labelled records which are seen during training. An example of supervised learning is a scam token classifier, which identifies characteristics associated with scam and benign tokens in order to categorize them. With sufficient labelled data, supervised classification algorithms can learn to predict a variety of behaviors including phishing/ice-phishing, malicious contract code, ransomware activity, scam token distribution, spam airdrops, etc. *Heuristic Filtering* Heuristic filtering uses simple rule of thumb logic evaluations, usually “yes” or “no”, to narrow down the pool of threat candidates to those which are most likely to attack. The design of the heuristics is part art and part science, as it takes a sleight of hand to derive the best results. The filters are usually designed empirically based on observed transaction patterns of malicious entities and/or, in more sophisticated forms, using the training weights (feature importances) in pre-existing models. Usually, a feature importance (weights) assessment from a supervised learning model gives the most accurate heuristics, but often at the expense of interpretation. *Unsupervised Classification (anomaly detection):* The term *anomaly* detection in transaction networks \*\*refers to the problem of finding exceptional patterns in transaction traffic that do not conform to the expected normal behavior. These “nonconforming” patterns or values, often referred to as anomalies, outliers, exceptions etc., arise as deviations from the “mean behavior” in the time-series transaction history of single or groups of addresses or in the entities themselves taking extreme values. Thus, to provide an appropriate solution in network anomaly detection, one needs a concept of “normality” and a concept of “distance” from normality. Performance measures: For generic predictions models, there is a tradeoff between *precision*, or ability to avoid false alarms, and *recall*, which is penalizes the failure to catch positive cases. The best models form a compromise of the two. To avoid a large number of false positive reports, a confidence threshold for classifying positive cases must be determined by the threat model on a case by case basis. # Tokenomics (work in progress) N.B.: This is an approximate tokenomics and is subject to future revisions. No Polyzoa tokens have been launched yet! 1. Token Distribution: A carefully designed token distribution plan is essential for the long-term sustainability and success of a blockchain project. With a total token supply of 2 billion, it's critical to allocate these tokens in a way that aligns with the project's goals, incentivizes the network's participants, and encourages widespread adoption. The team proposes a balanced approach for distributing the 2 billion token supply, taking into account factors such as network incentives, team allocation, community engagement, and future development. Proposed Token Distribution: The total token supply for Polyzoa is capped at 2 billion tokens. These tokens will be distributed gradually over a four-year timeframe, ensuring long-term sustainability and a steady release of tokens into the market. This gradual distribution aims to prevent excessive inflation and promote stability in the token's value. * Network Incentives (25%): Allocate 500 million tokens (25% of the total supply) to network incentives, rewarding validators, node operators, and other network participants. This allocation supports the network's long-term sustainability by incentivizing participants to maintain the security and reliability of the ecosystem. * Team Allocation (25%): Allocate 500 million tokens (25% of the total supply) to the project's team, including developers, researchers, scientists, and other staff. This allocation motivates the team and covers operational expenses. * Public Sale and Private Sale (25%): Allocate 500 million tokens (25% of the total supply) to public and private token sales, with 20% for early investors through several investment rounds and 5% for a public sale. This provides funding for initial development and establishes a diverse user base. * Community Engagement (5%): Allocate 100 million tokens (5% of the total supply) to community engagement initiatives, such as airdrops, bug bounties, and grants. This encourages active community participation and collaboration. * Ecosystem Development Fund (5%): Allocate 100 million tokens (5% of the total supply) to a fund supporting future partnerships and collaborations, ensuring project growth. * Reserve Fund (15%): Allocate 300 million tokens (15% of the total supply) to a reserve fund, serving as a safety net for unforeseen circumstances. 1. Token Utility * Fee Token: $PLZ is the primary fee token within the Polyzoa ecosystem, used by users to access security data. * Staking for Node Operations: To become a Polyzoa node operator, individuals must stake $PLZ as collateral, ensuring the integrity of services. * Rewards for Data Providers and Validators: $PLZ rewards those who provide relevant security data and validators who ensure data accuracy. 1. Market Demand and Token Value * Demand for Decentralized Oracles: The growing need for reliable security data in blockchain applications drives demand for Polyzoa's services and $PLZ tokens. * Value Creation: Polyzoa's value lies in its decentralized risk assessment and real-time security data provision, fostering a secure and economically viable ecosystem for all participants. * Value Growth: The tokenomics of Polyzoa incentivize community involvement and efficiency in risk assessment, increasing the value of $PLZ tokens. * Community Rewards: Polyzoa rewards community members who contribute to improving the network, enhancing its fraud detection capabilities. Polyzoa's innovative approach and tokenomics offer a promising solution for scam and fraud detection within the blockchain ecosystem. By promoting community involvement and leveraging advanced algorithms, Polyzoa aims to ensure a safer and more transparent decentralized economy. 1. Token flows 2. Token Distribution: A carefully designed token distribution plan is essential for the long-term sustainability and success of a blockchain project. With a total token supply of 2 billion, it's critical to allocate these tokens in a way that aligns with the project's goals, incentivizes the network's participants, and encourages widespread adoption. The team proposes a balanced approach for distributing the 2 billion token supply, taking into account factors such as network incentives, team allocation, community engagement, and future development. Proposed Token Distribution: The total token supply for Polyzoa is capped at 2 billion tokens. These tokens will be distributed gradually over a four-year timeframe, ensuring long-term sustainability and a steady release of tokens into the market. This gradual distribution aims to prevent excessive inflation and promote stability in the token's value. * Network Incentives (25%): Allocate 500 million tokens (25% of the total supply) to network incentives, rewarding validators, node operators, and other network participants. This allocation supports the network's long-term sustainability by incentivizing participants to maintain the security and reliability of the ecosystem. * Team Allocation (25%): Allocate 500 million tokens (25% of the total supply) to the project's team, including developers, researchers, scientists, and other staff. This allocation motivates the team and covers operational expenses. * Public Sale and Private Sale (25%): Allocate 500 million tokens (25% of the total supply) to public and private token sales, with 20% for early investors through several investment rounds and 5% for a public sale. This provides funding for initial development and establishes a diverse user base. * Community Engagement (5%): Allocate 100 million tokens (5% of the total supply) to community engagement initiatives, such as airdrops, bug bounties, and grants. This encourages active community participation and collaboration. * Ecosystem Development Fund (5%): Allocate 100 million tokens (5% of the total supply) to a fund supporting future partnerships and collaborations, ensuring project growth. * Reserve Fund (15%): Allocate 300 million tokens (15% of the total supply) to a reserve fund, serving as a safety net for unforeseen circumstances. 1. Token Utility * Fee Token: $PLZ is the primary fee token within the Polyzoa ecosystem, used by users to access security data. * Staking for Node Operations: To become a Polyzoa node operator, individuals must stake $PLZ as collateral, ensuring the integrity of services. * Rewards for Data Providers and Validators: $PLZ rewards those who provide relevant security data and validators who ensure data accuracy. 1. Market Demand and Token Value * Demand for Decentralized Oracles: The growing need for reliable security data in blockchain applications drives demand for Polyzoa's services and $PLZ tokens. * Value Creation: Polyzoa's value lies in its decentralized risk assessment and real-time security data provision, fostering a secure and economically viable ecosystem for all participants. * Value Growth: The tokenomics of Polyzoa incentivize community involvement and efficiency in risk assessment, increasing the value of $PLZ tokens. * Community Rewards: Polyzoa rewards community members who contribute to improving the network, enhancing its fraud detection capabilities. Polyzoa's innovative approach and tokenomics offer a promising solution for scam and fraud detection within the blockchain ecosystem. By promoting community involvement and leveraging advanced algorithms, Polyzoa aims to ensure a safer and more transparent decentralized economy. # Tech Architecture ## Modules Polyzoa’s scope is to create a distributed database and make the data Polyzoa and other produces freely available for web3 actors to use.
Polyzoa solution involves different layers. 1. **Producer Layer**: produces the data to be distributed in the network; data producers could use different sources and techniques to produce the data; data will be propagated on the network when a quorum is reached on the validity of the data itself (more to follow) 2. **Data Storage**: the overall bulk of data will be stored in a traditional database, with the possibility to have distributed back-ups in different systems; from this database, data are distributed to the distribution layer. 3. **Distribution layer**: it is responsible for make the data available across the network and also to keep them up to date. 4. **Consumer layer**: handles the access to the distributed system to various registered consumers 5. **Governance**: it will keep track of queries and updates, and charge, reward or discipline actors, either producers, operators or consumers. 6. **Oracle:** handles all the request coming from smart contracts, allowing the data to flow into the chain; each supported chain will have its own oracle system Below a vision of how the overall system will look like in its final form. Each layer is composed of different components: ### Data producer Each data producer analyses and publish data about a particular address or family of addresses; each producer can use any techniques or methodologies for analysis; this data are then passed to the network for validation. Data producer can either: * produce data using their own model/heuristic (eagle nodes) * produce data using Polyzoa model (gargoyles nodes) * produce data using and training Polyzoa model (wizards nodes) Data produced must adhere to a common schema wen producing results. A producer will be rewarded for the data produces and sanctioned if it produces low quality data. ### Validator It collects the data produced by the producers and validates the correctness of it; to evaluate correctness a quorum mechanism will be used: a data is considered correct if a majority of the producers reach the same results within a given errors; results outside of the error windows are discarded. More regarding the validation mechanism can be found in the appendices. Once a results is accepted as valid, it is written in a database and propagated by the distributor to the network. ### Distributor The distributor is responsible for * registering new distribution nodes into the system * removing distribution nodes from the system * creating data patches to be distributed to the various nodes; it is responsibility of each node to retrieve the patch and update its local database. ### Operator Nodes The nodes are at the core of the distributed database. Each node must stake an amount of token as proof of acceptance of the network protocol rules, and will be rewarded based on the traffic it handles. Each node has it is own database, and it is its responsibility to keep the database up to date and to handle the queries sent to them by the gateway. A node is not responsible to produce data and it is anchored on the content of the database. It is its responsibility to keep the database up to date. The nodes will be organised in shard's groups. Each shards group will give access to a particular subset of data. ### Gateway The gateway it is the interface between the consumers and the nodes. It contains the routing tables to propagate a query to the relevant node's group and to redistribute the results. When a consumer query the gateway, it will select a node that will receive the query and provide a response for the consumer. A node is selected based on its availability and its previous performance history. It is responsibility of the gateway to select nodes in a way to balance performance and fairness. The gateway will also collect statistics about the queries submitted to each node, the number of nodes actually online and the availability and performance of each of them. These data will be provided to the governance to decide rewards and sanctions. ### Real-time producer nodes In general producers calculate the risk score of an address and submit it for validation before the score end up in the global database. For special cases, we can need the score to be immediately available. For this purpose, special producers can be selected to provide such data in real-time without need to submit them to validation **before** distribution. The data are sent to the network as they are but they will be included in the network database only after the validation. ### Governance Governance will take care of the consumers and nodes, charging the first for usage and rewarding or sanctioning the seconds. All governance will be on-chain and the governance smart contract will have access to the logs generated by the distributors (i.e. patches made available) and by the gateway (i.e. nr of queries). Consumers will be charged for the number of queries they performs, either simple or batch queries. Nodes will be rewarded for the number of request they serve, according to different measurement and service level agreements, such as: * idle time / availability * performance * number of query served Nodes will be sanctioned if they: * fail to be available for a long period of time * fail to update the database, so providing obsolete data * … ### Oracles Oracles can distribute data directly in the network. In such a case, the oracle will be accessed through a special token implementing ERC677 (transferAndCall), so to collects fees from the consumer contracts directly. Oracles are deployed for each supported network and will serve a network of special nodes that will react to the event produced by them. ## Tech Road Map Phases ### Phase 1
Initially there will be a simple networks, with one single producer and a few nodes that will serve the consumers. While this network is small, it still maintain the same features described above. This network will allow us to fine tuning the system in order to achieve the better balance for the distribution network. ### Phase 2
We will introduce the oracles in one selected network, and create a distribution system able to work seamlessly between off-chain and on-chain network. The new network will use the existing one for accessing the data and make them available to smart contracts to reduce the impact of malicious address directly within a transactions. ### Phase 3
In phase 3 we will open the network to multiple external producers. In this phase, we will define the protocol that will govern the producers' network and that producers have to adhere to. As we plan to work wit multiple entities, we plan to make this job a collective one. In order to smooth the process, we will need to approve a schema that would make sure we have the right data at the right place. Also we need to make sure that each producer is able not only to accept request for handling address but that is also able to propose unknown address to the network. ### Phase 4
In the latest phase, we will enhance the network with real-time producers. In order to be a real-time producer, one have to have a record of successful discoveries, and this will be possible only if we have an history from which to grab the data and analyze them. A real-time data producer will make their discovery directly available to the network when the needs arise, without need for previous validation. In such a case, the produced data are not stored but passed to the consumer directly. The produced data will still be subject to validation, but this will happens before they will be accepted in the network database. In order to achieve this, we need to strengthen our trust in the producers. # Toward a fully decentralized security layer In the light of the recent development of Web3, it appears as a proper security layer is missing, leaving the blockchain exposed to different kind of scam and malicious behavior.

Fig. 1 Layers

Polyzoa's goal is to provide such layer. The layer will be acting in all respects as a separate blockchain, with a consensus mechanism and different node types, each of them participating in the overall ecosystem.

Fig. 2: a proposed architecture

In figure 2 we have not specified which network is responsible for the execution of a transaction, as the system should be chain agnostic. Of course, the nodes could change their check algorithm and tailor it to a specific chain. In figure 2 above we can identify: 1. **Operator nodes:** scope of operator nodes is to check if a transaction is safe to be propagated to the executing network; to do so, they will use data coming from the Archive nodes and processing coming from the Generator nodes; the operator nodes can also, if enabled, submit unknown data to the generator nodes for real-time processing 2. **Archive nodes:** they just serve historical records of data already processed; they will be updated once new data become available 3. **Generator nodes:** these nodes are responsible for processing transactions and generating new data when those are not available in the archive; each new processed data will be submitted to a consensus mechanism before they can be accepted in the archive nodes; each generator node can act as a validator. 4. **Consensus node:** responsible for orchestrate the consensus between the different validators. All data entering the system will be subject to approval by a consensus mechanism, similar to the one happening in a blockchain. Each generator node acts as a validator: new data entering the system will be broadcasted to all the validators, each of them will validate the data and the result sent to the consensus node for approval. {% hint style="info" %} **Validation:** when we talk about validation, we are actually talking about calculating the risk score of a transaction and of all the addresses involved in the transaction itself. {% endhint %} When the consensus node has collected all the score data, its algorithm will select with data are secure to be accepted in the system and become parts of the system itself, in a mechanism similar to the one described in the operation part. A consensus mechanism is necessary to prevent bad actors from introducing bad data into the system. ### What we achieve with that TBD ### A possible roadmap

Fig. 3: Roadmap

# Operations ### Consumers ### Registration Each consumer needs to be registered in the system and approve a minimum amount of Polyzoa tokens to be able to pay the fees.
### Request
When a consumer submit a request, it will be charged the fee after a successful response is sent back. If the consumer has not enough tokens approved for the fee, the request is rejected. ### Distribution Nodes ### Registration
To register a new node, operators must register themselves in the system. An operator can also act as a consumer once it has been registered in the system. When a new node is registered by the operator, the distributor will create a new node, configure it and notify the gateway of its presence. The node will be active and deemed ready to accept requests when: * has staked funds in the Stake Contract * has updated its database with the latest patch ### Serving requests **Off Chain**
When a request is sent to the gateway, the gateway will identify the consumer and then forward it to a node to serve the request. In order for the gateway to know which nodes are active at a give time, the node is requested to send a heartbeat regularly. Nodes that fail to send the heartbeat will be considered down and deactivated till a new heartbeat is received.
The selected node will receive the request and provide a response. In order to make the response safer, the node will be requested to sign the response with the associated address, in order to verify the identity of the node and protect the system. **The consumer will be charged only if the address being checked is known to the system.** Address that are unknown to the node are sent to a queue for further processing in the background, and made available on the next round of updates. **On Chain**
In case on an oracle, the request is generated from a contract. The request includes a callback function signature and is sent to a Token that forwards it to the relevant oracle. The oracle will check if the response is already stored on-chain. If the response is immediately available, the response is directly sent to the original requester using the callback signature. Otherwise, new data are requested off-chain. When the new date are available, they are sent to the requester. ### Update When new data are releases, the distributor will create patched for the new data and distribute across the active nodes. Each node will then update its own database and notify the distributor of the latest update. Node that fails to notify the distributor will be considered down and deactivated until the database has been update with the latest data.
### Data Production
An address is sent to a queue that distributes the address to all available data producers: * by the distributor nodes when the address is not found in the list of known addresses * by the data wrangler Each data producer produces a score for the address and send it to a validator. The validator collects all the scores, and determine which score is acceptable according to this algorithm: * Scores are aggregated in clusters according to risk thresholds. * Cluster with the majority of scores will be selected as most likely candidate. * The median or the average score is calculated for the cluster (TBD) In the figures below, we can see the scores produced by 20 data producers. In the figure A the majority of scores falls **above** the `0.75` threshold (red line), so the scores in the area above the line will be selected; the overall score will be the median between the scores, `0.86` In the figure B the majority of scores falls **below** the `0.45` threshold (orange line), so the scores in the area below the line will be selected; the overall score in this case is `0.30`
Case Achart_(5).png
Case Bchart_(6).png
If a quorum is reached, then the address with its score is propagated to the database and distributed across the nodes. If no quorum is reached, the address is promoted to manual check Producers that fail to produce scores or produce scores that are consistently different from the rest (several standard deviations from the mean), will be sanctioned or deactivated. # Bot / API