Developers Forum for XinFin XDC Network: 11ppm

Proposal for Redesigning KYC in XDC

11ppm — Tue, 07 Oct 2025 15:44:28 +0000

— Toward a Two-Layer Compliance Framework Required for the XDC Network —

Introduction

The Globiance incident has cast serious doubt on the institutional reliability of the XDC Network’s KYC framework. Concerns are spreading that, in practice, masternode reviews may amount to little more than “submit the documents and you’re approved.” If verification remains merely procedural, it does not guarantee trust; rather, it risks overlooking misconduct and inviting significant threats.

The XDC team itself originally described “KYC Enabled Masternodes” as “an additional layer of trust and compliance.” In other words, the system was meant to ensure regulatory adherence and to provide a framework in which enterprises and financial institutions could participate with confidence. (See referenced article.)

In actual operation, however, it has been limited to document checks, diverging sharply from that founding intent. This is precisely why XDC now needs a two-layer architecture—long discussed on xdc.dev—that combines outsourcing to traditional-finance KYC/AML vendors to secure trust at the point of entry, with crypto-asset forensics to ensure transparency of fund flows (off-chain KYC + on-chain monitoring).

This paper organizes why such a structure is necessary and sets out the conclusions and lessons that follow.

(Note)
Although this article has already been published, we plan to make ongoing corrections to typos, as well as add images and content updates where appropriate. The aim is to further enrich the material and make it more useful to readers.

Structure of This Article

The Necessity of a Two-Layer Compliance Architecture
The Limits and Hollowing-Out of the Current KYC
Risk Scoring by KYC/AML Vendors
Past Disclosure of KYC Documents and the Risks It Revealed
The Limits of Formalistic KYC in International Cases
Risk and Responsibility Diversification via KYC Vendor Adoption
Proposals for Rebuilding the KYC Regime

1. Necessity of a Two-Layer Compliance Architecture

What XDC needs is a two-layer compliance architecture that combines two distinct categories of vendors.
　

Layer 1: Trust at the Point of Entry (Traditional-Finance KYC/AML Vendors)

The first requirement is a traditional-finance KYC/AML vendor. Such vendors perform systematic identity verification for individuals and entities; authenticate corporate registrations and licenses; identify ultimate beneficial owners (UBOs); conduct sanctions and politically exposed person (PEP) checks; and screen against adverse media. They also quantify jurisdictional and entity-level trust via risk scoring, thereby safeguarding trust at the entry point to the network.

Representative vendors include:

Layer 2: Transparency of Fund Flows (Blockchain Analytics Vendors)

The next requirement is blockchain analytics vendors. They handle wallet- and transaction-level risk assessment, trace the movement of funds, detect sanctions evasion and money laundering, and conduct cross-chain investigations—thereby ensuring network-wide transparency of fund flows.

Representative vendors include:

The Significance of the Two-Layer Model

Only by integrating KYC/AML to secure trust at the entry point with blockchain analytics to ensure transparency of fund flows does a globally viable compliance regime take institutional shape.

2. The Limits and Hollowing-Out of the Current KYC

So where does XDC stand today?

In May 2025, XDC expanded its integration with Elliptic, advancing the development of Layer 2 (on-chain monitoring). This now covers not only network transaction surveillance but also real-time cross-chain tracing and analytics for RWAs (real-world assets), significantly improving transparency of fund flows. (See referenced article.)

However, Elliptic does not verify the authenticity of off-chain entities—such as the identities of individuals or corporations, their licenses, or their ultimate beneficial owners (UBOs). In other words, Layer 1, which guarantees “trust at the point of entry,” remains missing, leaving the overall framework incomplete.

To fill this gap, traditional-finance KYC/AML vendors are indispensable. They go far beyond simple identity verification, providing validation of corporate registrations and licenses, identification of UBOs, screening against sanctions, PEP, and adverse media lists, and even quantifying each entity’s level of trust through risk scoring—thus forming the very foundation of Layer 1.

In conclusion, the establishment of this Layer 1 is the highest priority. Without it, no matter how robust Layer 2 becomes, the foundation of trust will never be solid.

3. Risk Scoring by KYC/AML Vendors

Traditional-finance KYC/AML vendors provide more than simple identity checks. They also quantify jurisdictional trust differentials and entity-level risk, effectively operating with something akin to a “credit-style” risk score.

Risk Scoring Used by Vendors

Most KYC/AML vendors assign a risk score to each individual or entity, typically combining the following factors (scored or ranked):

　
1. Jurisdiction Risk

Based on the regulatory environment and the strength of AML controls in the country of registration. → Japan and EU countries tend to be low-risk; El Salvador and certain offshore jurisdictions are often treated as high-risk. In making such determinations, vendors and network operators reference evaluations by FATF and the OECD, as well as sanctions-evasion country lists, among other materials.

　
2. Entity Risk

For entities: industry (e.g., casinos or crypto-related businesses are higher risk), licensing status, and the credibility of supervisory authorities.
For individuals: PEP status, prior scandals or litigation history, and whether they appear on sanctions lists.

　
3. Media & External Information

Automated collection of negative media, litigation coverage, and regulatory breaches, with relevance reflected in the score.

　
4. Relationships & UBO Structure

Whether the UBOs are high-risk persons and whether ownership structures lack transparency.

Handling “Jurisdictional Trust”

This approach enables practical differentiation: even if two applicants both call themselves “banks,” Japan versus El Salvador leads to different treatments in practice.

Japan/Singapore → strict supervision by the FSA or MAS → “low-risk jurisdictions.”
El Salvador and some emerging markets → underdeveloped regulation or political instability → “high-risk jurisdictions.”

Consequently, the weight of a banking license differs by country in real-world operations.

How Scores Are Used

Vendors return categorizations or numeric values such as low/medium/high risk. Recipients (banks, network operators, exchanges, etc.) then set thresholds consistent with their risk tolerance. Scales differ by vendor, and re-KYC (periodic refresh) or event-driven reviews are assumed.

Example operational policy:

Decline high-risk (e.g., scores ≥ 80)
Request additional documentation for medium-risk
Approve low-risk promptly

Meaning in a Blockchain Context

For a network like XDC:

Use vendor risk scores to decide whether to approve a node application;
Present those scores to investors and regulators as evidence of entry-point trust.

Because these scores aggregate jurisdictional regulation, industry, PEP/sanctions, and adverse information, they go beyond identity alone and form a fitness criterion for masternode operation. For example, decline high-risk applicants, require supplemental documentation for medium-risk ones—directly supporting practical decision-making.

Moreover, such scores provide a rational basis to explain “why this node was accepted,” serving as reassurance to investors and as a documented risk-management procedure for regulators—thus institutionalizing transparency and accountability.

This is how risk scoring can be realistically applied.

Building Out Layer 1 as the Trust Foundation

Traditional-finance KYC/AML vendors employ credit-like risk scoring that clearly reflects differences in regulatory environments across countries. Thus, even if two applicants both call themselves “banks,” the treatment differs between, say, Japan and El Salvador.

From the outset, XDC embedded KYC in its design to interface with traditional finance and international financial infrastructure—hence it intentionally did not adopt a fully permissionless model like Ethereum, Polygon, or Avalanche (where anyone can run a node), despite being EVM-compatible.

Requiring a substantial stake of 10 million XDC plus KYC submissions effectively gives XDC leverage over who can operate a node. In practice, this means operators are significantly filtered by these conditions.

Yet the operation became overly formalistic. Allowing PDFs uploaded alongside a 10-million-XDC stake to “pass” without thorough examination by personnel with adequate domain expertise entails serious risk. In AML and international fraud cases, document forgery and alteration are basic, common tactics; without the capacity to detect them, KYC becomes hollow.

Therefore, to win international trust, Layer 2 transparency is not enough. Building out Layer 1 is the most urgent task right now.

4. Past KYC Document Disclosure and the Risks It Revealed

How Document Disclosure Exposed Institutional Hollowing-Out

Regarding the PDFs uploaded alongside a 10-million-XDC stake: while they are now fully private, there was reportedly a period during which XDC masternode KYC documents were accessible externally. The exact timeframe is unclear, but since they were later made private following complaints from node operators, XDC should be aware that this occurred.

This episode illuminated several important realities of the KYC process. Of course, external accessibility was itself a serious security risk. What I wish to highlight, however, is how the hollowing-out of the system became visible as a secondary effect.

In practice, submissions showed large regional and individual disparities. One operator attached driver’s licenses and multiple ID copies, while another submitted only a single notarized page—revealing that stringency was not applied consistently.

The Risks of a Single Notarial Certificate and Offshore Entities

What does “a single notarized page” mean? It is merely a document on which a notary certifies, with signature and seal, that “this person is affiliated with the company.” In many jurisdictions, a notary’s role is limited to verifying the signer’s identity and the fact of signing; the truth of the document’s contents is not guaranteed. Functionally, it resembles a sworn statement that still requires independent corroboration for substantive accuracy.

There were also indications that some nodes were registered to offshore companies established in tax havens. Such entities often serve as paper companies with little real business activity, making UBOs hard to identify and enabling asset concealment or money laundering—problems widely criticized internationally. FATF’s Recommendations 24/25 (R.24/25) call on countries to strengthen transparency of beneficial ownership to mitigate these risks.

If approvals could be granted on the strength of a single notarial document, that would hollow out entry-point trust and risk creating a breeding ground for crime. We must not rely on good-faith assumptions; AML and international fraud lessons require that we design systems on the premise of potential abuse, eliminating gaps proactively.

To close those gaps, traditional-finance KYC/AML vendors are indispensable—not only to authenticate registrations, licenses, and UBOs, but also to conduct PEP checks, screen against UN/OFAC/EU sanctions lists, and run adverse-media searches across public records and court filings to detect past misconduct, among other layers of scrutiny.

This is the core mechanism to institutionalize entry-point trust, and it is the foundation XDC needs most urgently. Crucially, the fragility of formalistic KYC is not unique to XDC; it has been exposed repeatedly in international financial scandals.

Below, we review emblematic cases showing how formalistic KYC has hit its limits.

5. Limits of Formalistic KYC in International Cases

The weaknesses of formalistic KYC are not unique to XDC; they have recurred across international financial scandals. More troubling still is when professionals—lawyers, accountants—facilitate such misconduct.

In the 2016 Panama Papers, massive leaks from a Panamanian law firm revealed how politicians and the wealthy worldwide used tax havens for asset concealment, tax evasion, and money laundering. The law firm itself provided company-formation schemes—i.e., legally dubious or outright illicit structures—thereby participating in laundering. In short:

It is not “safe because professionals are involved”; rather, there is a risk precisely because professionals are involved.

The pattern extends beyond the Panama Papers.

In the 2017 Paradise Papers, documents leaked from the major law firm Appleby and corporate service providers exposed large-scale tax avoidance via complex offshore schemes, showing how professionals and large firms actively provided “loopholes.”

In 2018, the Danske Bank money-laundering case revealed that around €200 billion in suspicious funds flowed through its Estonian branch, demonstrating that even a leading European bank can become a conduit when entry-point AML checks are hollowed out.

In 2020, the Wirecard scandal showed that even with audits by one of the Big Four (EY), massive fraud can go undetected—professional assurances do not automatically guarantee trust.

Hence the institutional necessity of independent third-party audits and continuous monitoring. If basics such as verifying registrations and licenses, confirming regulatory registrations, and screening against sanctions and adverse media are missing, KYC becomes KYC in name only. These cases demonstrate that the limits of formalistic KYC are a global issue, and XDC is no exception. The past episode where XDC KYC documents became externally viewable—and thereby exposed vulnerabilities—shows the same problem arises here as well.

6. Diversifying Responsibility by Introducing KYC Vendors

These institutional shortcomings are not merely theoretical. They materialized in practice—namely, in the Globiance incident.

Counterfactually, had an external KYC/AML vendor been engaged at the time of Globiance’s masternode application (or at a functioning re-KYC interval), the authenticity or deficiencies of any banking/exchange licenses, and any presence on regulatory warning lists, might have undergone closer scrutiny. As a result, Globiance may have been flagged early as high-risk, potentially preventing entry into the network’s core.

This also benefits XDC itself.

So long as XDC conducts KYC on its own, responsibility concentrates within XDC. If an independent vendor formally performs the review, XDC can clearly demonstrate reliance on a professional determination, thereby improving procedural propriety and relatively reducing risk (though ultimate governance responsibility still remains with XDC). In this sense, vendor adoption functions not only as risk reduction but also as responsibility sharing.

Thus, the Globiance incident was not a random mishap; it exposed design flaws. The issue is not transient; it indicates structural fragility, which makes reform imperative.

7. Proposals for Rebuilding the KYC Regime

From the design stage, XDC adopted KYC with an eye toward integration with traditional finance and international financial infrastructure. In practice, however, implementation tilted toward paper-based reviews, leaving the checking apparatus insufficient. The result was a de facto reliance on the good faith of masternode operators.

The Globiance incident demonstrated the practical limits of XDC continuing to in-house KYC reviews. Tasks such as verifying registrations and licenses, identifying UBOs, and screening against regulatory lists should be handled continuously and systematically by specialized KYC/AML vendors. It is neither operationally nor from a governance standpoint reasonable for XDC—whose core vocation is blockchain development—to shoulder these as well.

While Globiance is primarily responsible and deserves strong censure, there is also room to acknowledge potential improvements on the XDC side in system design and operation. It would not be surprising if investor perceptions of “network trustworthiness” were influenced, to some degree, by weaknesses in the KYC framework.

Therefore, it is essential to standardize both layers: traditional-finance KYC/AML to secure entry-point trust, and blockchain analytics to ensure transparency of fund flows. With Layer 2 advanced via Elliptic integration, XDC should prioritize completing Layer 1—off-chain verification of organizational and individual authenticity. This two-layer architecture is the shortest path to restoring, and sustaining, trust in the network.

Above all, XDC itself must proactively pursue reform. Leaving defects unaddressed invites recurrence and erodes ecosystem-wide trust. For a project aspiring to connect with international financial infrastructure, allowing KYC to remain merely formalistic is fatal. Reform is not optional—it is imperative.

Let this be a turning point, and let us take the next step forward together with XDC.

11ppm

Repeated Error When Setting Up XDC Node

11ppm — Tue, 14 Jan 2025 11:11:52 +0000

I am attempting to set up an XDC node on a server that was hard reset, but I keep encountering the following error repeatedly. Despite trying various solutions, the issue remains unresolved. I have tested this on two servers, and the result was the same. Additionally, it seems that others are experiencing the same error. I would like the XDC team to look into this issue.

ERROR[01-14|03:10:09] Failed to retrieve block author          err="recovery failed"                                                                number=0 hash=4a9d74…42d6b1
ERROR[01-14|03:10:24] Failed to retrieve block author          err="recovery failed"                                                                number=0 hash=4a9d74…42d6b1
WARN [01-14|03:10:44] Full stats report failed                 err="ping timed out"
WARN [01-14|03:10:44] Failed to retrieve stats server message  err="read tcp 172.18.0.2:39586->45.82.64.150:3000: use of closed network connection"
WARN [01-14|03:10:54] Stats server unreachable                 err="dial tcp 45.82.64.150:3000: i/o timeout"
WARN [01-14|03:11:10] Stats server unreachable                 err="read tcp 172.18.0.2:34086->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:11:30] Stats server unreachable                 err="read tcp 172.18.0.2:37066->45.82.64.150:3000: i/o timeout"
ERROR[01-14|03:11:49] Failed to retrieve block author          err="recovery failed"                                                                number=0 hash=4a9d74…42d6b1
WARN [01-14|03:12:09] Full stats report failed                 err="ping timed out"
WARN [01-14|03:12:09] Failed to retrieve stats server message  err="read tcp 172.18.0.2:36694->45.82.64.150:3000: use of closed network connection"
WARN [01-14|03:12:19] Stats server unreachable                 err="read tcp 172.18.0.2:43042->45.82.64.150:3000: i/o timeout"
ERROR[01-14|03:12:41] Failed to retrieve block author          err="recovery failed"                                                                number=0 hash=4a9d74…42d6b1
WARN [01-14|03:13:01] Full stats report failed                 err="ping timed out"
WARN [01-14|03:13:01] Failed to retrieve stats server message  err="read tcp 172.18.0.2:58750->45.82.64.150:3000: use of closed network connection"
WARN [01-14|03:13:11] Stats server unreachable                 err="read tcp 172.18.0.2:35534->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:13:31] Stats server unreachable                 err="read tcp 172.18.0.2:35760->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:13:51] Stats server unreachable                 err="read tcp 172.18.0.2:52106->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:14:11] Stats server unreachable                 err="read tcp 172.18.0.2:53050->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:14:31] Stats server unreachable                 err="read tcp 172.18.0.2:58428->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:14:51] Stats server unreachable                 err="read tcp 172.18.0.2:54984->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:15:11] Stats server unreachable                 err="read tcp 172.18.0.2:36082->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:15:31] Stats server unreachable                 err="dial tcp 45.82.64.150:3000: i/o timeout"
WARN [01-14|03:15:50] Stats server unreachable                 err="read tcp 172.18.0.2:38446->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:16:10] Stats server unreachable                 err="read tcp 172.18.0.2:49742->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:16:27] Stats server unreachable                 err="read tcp 172.18.0.2:39772->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:16:47] Stats server unreachable                 err="read tcp 172.18.0.2:57710->45.82.64.150:3000: i/o timeout"
WARN [01-14|03:17:07] Stats server unreachable                 err="read tcp 172.18.0.2:38510->45.82.64.150:3000: i/o timeout"

Proposal: Enhancing the Validator Node Rotation System in the XDC Network

11ppm — Fri, 27 Dec 2024 12:22:00 +0000

Introduction

Currently, XDC masternodes are promoted to validator nodes using a round-robin system. This system ensures fairness while assigning validator roles to standby nodes. However, the existing approach has a potential drawback: certain nodes may remain as validators for extended periods, which raises concerns about decentralization.

This proposal aims to address this issue by presenting a refined mechanism to promote decentralization, while balancing fairness and efficiency.

Proposal Details

1. Periodic Rotation of Validator Nodes

Objective:

Prevent any single node from operating as a validator for extended periods and enable more operators to participate.

Details:

Set a maximum tenure of 1 year for validator nodes.
After the tenure ends, the node returns to the standby pool.
Introduce a 3-year cooldown period, during which the node cannot serve as a validator again.

2. Improved Selection Mechanism: Combination of Registration Order and VRF

Objective:

Balance fairness and unpredictability while prioritizing nodes with stable performance.

Details:

Split the selection process into two components:

Registration Order RotationAllocate 50% of slots based on the order in which standby nodes were registered.
Performance-Based VRF SelectionUse Verifiable Random Function (VRF) provided by the decentralized oracle Plugin to randomly select the remaining 50% from nodes with stable performance.

Benefits:

Maintains fairness based on registration order.
Introduces unpredictability via VRF, enhancing security and decentralization.

3. Transparent Performance Evaluation Criteria for Standby Nodes

Objective:

Ensure a transparent selection process and maintain network reliability.

Details:

Establish criteria such as uptime, response times, and historical performance for evaluating nodes.
Nodes failing to meet these performance standards will be excluded from selection.

Benefits of the Proposal

Promoting DecentralizationReduces the risk of network dominance by specific nodes over extended periods.
Improved FairnessCombines registration order and VRF to create a balanced and inclusive selection system.
Enhanced Efficiency and StabilityPerformance-based criteria ensure network-wide reliability.
Encouraging New ParticipantsCooldown periods create more opportunities for new nodes to serve as validators.

Conclusion

This proposal provides a practical and effective approach to improving decentralization and fairness in the XDC network. By enhancing the round-robin system with registration order rotation and performance-based VRF, it ensures the stability and security of the network while enabling broader participation.

Implementing this mechanism will help the XDC network evolve into a more decentralized and sustainable ecosystem, driving its long-term growth and success.

This is merely one proposal, but it represents a realistic and meaningful approach to enhancing decentralization, fairness, and efficiency within the XDC network. By incorporating detailed implementation plans, this proposal can become even more feasible and effective.

This proposal is intended to serve as a starting point for discussion and thought within the community. My goal is not to present a final solution, but rather to raise key questions and ideas that could spark further exploration. I believe that by engaging in thoughtful discussions, we can refine and develop this concept to better suit the needs of the XDC network and its stakeholders.

I look forward to hearing your thoughts and feedback on how we can improve the validator node rotation system, and how we can ensure that decentralization remains at the core of the network's future development.

Thank you for taking the time to consider this proposal, and I’m excited to continue the conversation with all of you!

[Solved] Issue with One-Click Installer Download Availability

11ppm — Tue, 06 Feb 2024 23:05:53 +0000

Hi, I want to test the "One-Click Installer", but I am unable to download it on Windows, Linux, and Mac. Please fix so that the download is available.

[Query] Query on Recent Masternode Snapshot Alterations

11ppm — Mon, 15 Jan 2024 00:38:52 +0000

I have a question regarding the mainnet snapshot of the masternode. Previously, when I unzipped the file, an XDC directory was created in the current directory, containing a large number of ldb files. However, when I try it now, the XDC directory is not created, and a large number of files appear directly in the current directory. Has the handling of the snapshot changed? Previously, after unzipping, I believe the XDC directory that was created was moved to the xdcchain directory.

[Solved] Query about XDC Mainnet Gas Price Post-XDPoS 2.0 Upgrade

11ppm — Fri, 17 Nov 2023 04:42:12 +0000

Hi XDC community,

If there are any developers from the XDC team present here, I have a question regarding XDPoS 2.0. I understand that on the Apothem network, the Gas Price has changed as follows:

Before the upgrade:

Gas Limit & Gas Used By Txn: 21,000 | 21,000 (100.00%)
Gas Price: 0.00000000025 XDC (0.25 Gwei)

After the upgrade:

Gas Limit & Gas Used By Txn: 21,000 | 21,000 (100.00%)
Gas Price: 0.0000000125 XDC (12.5 Gwei)

I would like to know if this change to 12.5 Gwei for Gas Price in Apothem will also be applied to the Mainnet. The reason I ask is that when the Apothem network transitioned to XDPoS 2.0, transactions on the Plugin 2.0 nodes failed to complete because the Gas Price exceeded the set limit. Adjusting the settings resolved the issue, allowing transactions to complete. Since a similar situation could occur on the Mainnet, if the Gas Price is expected to be 12.5 Gwei with XDPoS 2.0 there as well, it might be wise to start setting up validator nodes from now to prepare for this change.

Thanks for your time and insights,
11ppm

[Solved] 502 Error on Apothem Network WebSocket

11ppm — Mon, 11 Sep 2023 11:44:36 +0000

Apothem Network's websocket is constantly giving a 502 error. I would like it to be fixed. If there are any other websockets that can be used, please let me know. Currently, there is only one option: wss://ws.apothem.network/. I would like another one to be provided. Thank you.

(It happened again.)The dissociation between "Current Value" and "Estimated Value on Day of Txn On the Explorer

11ppm — Fri, 21 Oct 2022 15:46:13 +0000

The same issue happened. Please fix it.

https://www.xdc.dev/11ppm/the-dissociation-between-current-value-and-estimated-value-on-day-of-txn-on-the-explorer-49an

The dissociation between "Current Value" and "Estimated Value on Day of Txn On the Explorer

11ppm — Tue, 27 Sep 2022 22:48:05 +0000

On the Explorer the dissociation between "Current Value" and "Estimated Value on Day of Txn" is unusually large . It is clearly wrong, and I would like to have it corrected.

https://explorer.xinfin.network/txs/0x5b7ec19ccc74c36c88a04f7ac44867648da936afb48b5b7882aa02dce370b065#overview