Developers Forum for XinFin XDC Network: Arturo

XDCValidator Contract Upgrade: Modernizing Staking for the Next Era of XDC

Arturo — Tue, 31 Mar 2026 10:03:27 +0000

TL;DR: The XDCValidator contract (0x88) was deployed with Solidity 0.4.21 and has never received a major upgrade. The ecosystem has matured significantly since then. Liquid staking protocols, institutional staking services, and DeFi composability all demand a more flexible validator lifecycle. I'm proposing we use a contract upgrade as an opportunity to modernize the staking/unstaking mechanism, fix accumulated state inefficiencies, and unlock new use cases. Below are three concrete scenarios for community discussion.

Why Now?

The current XDCValidator contract has served the network well, but several realities make an upgrade worth discussing:

Compiler vintage. Solidity 0.4.21 predates significant compiler improvements (SafeMath built-ins, custom errors, overflow checks, ABI encoder v2). Newer Solidity versions offer better gas efficiency, security defaults, and developer ergonomics.
State hygiene. Over the network's lifetime the contract has accumulated storage artifacts (zeroed-out array entries, stale mappings) that waste gas and complicate on-chain queries. A migration is an opportunity for a clean slate.
The "30-day" wall that's actually 35-42 days. The contract uses block-number-based delays set at genesis: candidateWithdrawDelay = 1,296,000 blocks for masternode owners resigning, and voterWithdrawDelay = 432,000 blocks for voters unvoting. These are hardcoded constructor parameters with no governance mechanism to adjust them.

The 2-second block time is a theoretical target, not a guarantee. Real-world data from xdcscan tells a different story:

| Period | Avg block time | Effective owner withdrawal delay |
|---|---|---|
| Theoretical | 2.00s | 30.0 days |
| Last 30 days (Mar 2026) | 2.33s | ~35 days |
| Last 365 days | 2.33s | ~35 days |
| Last 90 days (includes Jan 2026 spikes) | 2.83s | ~42 days |
| Worst days (Jan 11-12, 2026) | 13.6s | Would imply ~204 days if sustained |

In practice, masternode owners resigning today should expect to wait ~35 days under normal conditions, and potentially longer during network congestion events. The block time has never consistently held at 2.00s. The network regularly averages 2.2-2.8s, and periodic spikes (Dec 26: 8.4s, Dec 28-30: 4-5s, Jan 10-12: 5-14s) push the effective delay even further.

For liquid staking protocols, this unpredictability on top of an already long delay is the binding constraint. Protocols must either (a) keep a large idle reserve buffer sized for worst-case timing, (b) force users to wait 35+ days, or (c) route through DEX secondary markets at a discount. All three options erode capital efficiency and hurt adoption.

Important detail: resign() only unlocks the owner's own voter stake, not the full candidacy cap. Other voters who staked on that candidate must separately call unvote() (with a ~12-day effective delay at current block times) to retrieve their funds. withdraw() must be called individually per withdrawal entry (specific blockNumber + index), there is no batch withdrawal.

Ecosystem competitiveness. Other networks have already moved to dynamic or queue-based unstaking:
- Ethereum: epoch-based churn limit (~8 validators/epoch), exit times range from hours to weeks depending on demand
- Polkadot: RFC-0097 introduces dynamic unbonding from 2 days (empty queue) to 28 days (high demand)
- Cosmos: 21-day unbonding with per-block queue maturation
- Avalanche: ACP-273 proposes reducing minimum staking from 14 days to 48 hours

XDC's flat 30 days with zero flexibility is an outlier.

Current Mechanism (Deployed at 0x88)

For context, here's the live on-chain state of the contract, queried via eth_getStorageAt against mainnet RPC and cross-referenced with the verified source on xdcscan:

Contract Parameters (immutable since genesis)

Parameter	Storage slot	On-chain value	Real-world effect
`candidateWithdrawDelay`	`0x0e`	1,296,000 blocks	~35 days at current avg 2.33s/block
`voterWithdrawDelay`	`0x0f`	432,000 blocks	~12 days at current avg 2.33s/block
`minCandidateCap`	`0x0b`	10,000,000 XDC	Stake required to propose a masternode
`minVoterCap`	`0x0c`	25,000 XDC	Minimum vote amount
`maxValidatorNumber`	`0x0d`	18	Genesis relic, consensus layer overrides to 108
Compiler	-	Solidity 0.4.21	No overflow protection, known compiler bugs

Live Network State (queried March 2026)

Metric	Value	Notes
Contract balance	2,580,878,498 XDC (~$80M)	All staked funds held here
`candidateCount`	253	Active candidates registered
`ownerCount`	219	Includes resigned owners who are still counted
`candidates[]` array length	529	Entries ever created (never shrinks)
Active (non-zero) entries	253	47.8% of the array
Ghost (zeroed-out) entries	276	52.2% waste, gas overhead on every enumeration
Consensus active set	108 masternodes	Set by XDPoS v2, not the contract's `maxValidatorNumber`
Current block	~100,783,000	~7.4 years of blocks at avg 2.33s

Withdrawal Flow Today

Owner calls resign(candidateAddress) → isCandidate set to false, owner's own stake scheduled for release at block.number + 1,296,000.
Owner waits ~35 days in practice (1.296M blocks at real-world avg of 2.33s/block, can stretch to 40+ days during congestion spikes).
Owner calls withdraw(blockNumber, index). Must specify the exact block number and array index. No batch withdrawal.
Voters on the same candidate must independently call unvote() → their stake is released after block.number + 432,000 (~12 days actual).

Key Limitations

Block-count based delays, not timestamp-based. The effective wait drifts with block time fluctuations. At the recent 90-day average of 2.83s/block, the owner delay stretches to ~42 days.
No parameter governance. candidateWithdrawDelay and voterWithdrawDelay are constructor-set with no admin function to adjust them.
maxValidatorNumber is stale. Contract says 18, consensus layer uses 108. The parameter serves no active purpose.
ownerCount only increments. resign() does not decrement ownerCount, meaning it includes all historical owners. This inflates the denominator in any governance calculation that uses it.

The Three Scenarios

Scenario A: Three-Tier Exit Queue (Simple & Predictable)

Concept: The withdrawal lock duration depends on how many masternodes are currently pending withdrawal at the time you resign. Three tiers create a clear incentive structure: exits are fast when the queue is light, moderate at normal load, and fall back to the full 30 days only under heavy exit pressure.

Queue depth (pending withdrawals)	Lock duration	Rationale
< 5 nodes	3 days	Low pressure, network is healthy, fast exits are safe
5 - 10 nodes	14 days	Moderate pressure, allow exits but with a buffer
> 10 nodes	30 days	High pressure, full lock to protect network stability

Parameter	Value
Queue model	Real-time count of pending withdrawals
Tier boundaries	5 and 10 (tunable via governance)
Lock assignment	Snapshot at time of `resign()`

How it works:

Validator calls resign().
Contract reads pendingWithdrawalCount (number of validators currently in the withdrawal pipeline).
If < 5 → assign 3-day lock.
If 5-10 → assign 14-day lock.
If > 10 → assign 30-day lock.
Withdraw after lock expires (unchanged).

Why liquid staking loves this: Under normal network conditions, the exit queue rarely has more than a handful of nodes pending at once. A liquid staking protocol operating 20 masternodes could rotate nodes with just a 3-day turnaround, small enough to serve redemptions from a thin buffer without sacrificing yield. When the queue gets crowded, the longer delays kick in automatically, giving the protocol a clear signal to pause redemptions or route to secondary markets.

Trade-offs:

Simple to implement and reason about, just two if checks.
Tier boundaries (5 / 10) need tuning based on network size; could be made governance-adjustable.
Lock is fixed at resign time, so a validator who resigns at queue depth 4 gets 3 days even if 20 more resign in the next block.

Scenario B: Continuous Dynamic Duration Based on Queue Depth (Polkadot-Inspired)

Concept: Instead of hard tiers, the lock duration scales smoothly between a floor and ceiling based on the number of masternodes currently pending withdrawal. Below 5 nodes the lock approaches its minimum; above 10 it ramps toward the maximum; and it caps at 30 days.

Parameter	Value
Minimum lock (0 nodes pending)	2 days
Maximum lock (≥ 10 nodes pending)	30 days
Fast zone	< 5 nodes pending → 2-7 days
Transition zone	5-10 nodes pending → 7-30 days
Scaling curve	Linear between breakpoints (or sigmoid for smoother UX)

Formula:

if pendingNodes < 5:
    lockDays = 2 + (pendingNodes * 1)            // 2d → 6d
else if pendingNodes <= 10:
    lockDays = 7 + (pendingNodes - 5) * 4.6      // 7d → 30d
else:
    lockDays = 30                                  // hard cap

How it works:

Validator calls resign().
Contract reads pendingWithdrawalCount.
Lock duration is computed from the formula above.
Assign lockDuration to this withdrawal entry.
Withdraw after lock expires (unchanged).

Example at current network size (~108 active masternodes):

Nodes currently pending withdrawal	Lock duration	Zone
0	2 days	Fast
1	3 days	Fast
2	4 days	Fast
4	6 days	Fast
5	7 days	Transition
7	16 days	Transition
10	30 days	Cap
15	30 days	Cap

Why liquid staking loves this: In the common case (1-3 nodes cycling out), the lock is 2-5 days. A liquid staking protocol can keep a minimal reserve buffer and serve redemptions almost in real-time. The smooth curve also means there's no "cliff" at a tier boundary. Protocols can forecast lock times with a simple view function call before deciding whether to initiate a withdrawal.

Trade-offs:

Slightly more complex than tiered (requires on-chain math), but still a single storage read + arithmetic.
Lock duration isn't known until the moment of resignation (though a previewLockDuration() view function makes this transparent).
Elegant security guarantee: if many nodes rush to exit, the lock automatically stretches to 30 days, protecting the network without any governance intervention.

Scenario C: Adaptive Churn Limit with FIFO Queue (Ethereum-Inspired)

Concept: Validators enter a FIFO exit queue on resign(). The network processes exits at each epoch boundary, but the processing speed adapts based on queue depth: fast when the queue is short, throttled when it's deep.

Queue depth	Exits processed per epoch	Post-queue lock	Effective behavior
< 5 nodes	5 per epoch (drain immediately)	48 hours	Near-instant: queue clears in one epoch
5 - 10 nodes	2 per epoch	48 hours	Moderate: queue drains over several epochs
> 10 nodes	1 per epoch	7 days	Slow: deliberate pacing + extended lock

Parameter	Value
Queue model	FIFO, processed at epoch boundary
Epoch duration	900 blocks (~30 min at 2s blocks)
Churn rate adapts every	Epoch (re-evaluated based on current queue depth)

How it works:

Validator calls resign() → enters the exit queue with a sequence number. Post-lock duration is assigned at this point based on current queue depth.
At each epoch boundary, the contract reads the current queue depth and processes exits accordingly.
If queue < 5 → process up to 5 exits this epoch. Post-lock for new resignations: 48 hours.
If queue 5-10 → process up to 2 exits this epoch. Post-lock for new resignations: 48 hours.
If queue > 10 → process only 1 exit this epoch. Post-lock for new resignations: 7 days.
Withdraw after post-lock expires.

Note: the churn rate adapts as the queue drains. A queue of 25 doesn't process at 1/epoch the whole time. Once it drops below 10, it speeds up to 2/epoch, then 5/epoch below 5.

Example queue scenarios (traced through adaptive processing):

Queue depth at resign	Post-lock (fixed at resign)	Queue drain breakdown	Total estimated time
0 (you're the only one)	48h	1 epoch (~30min)	~2 days
3 (light traffic)	48h	1 epoch, all 4 clear at 5/epoch	~2 days
7 (moderate)	48h	3 epochs at 2/epoch, then 1 at 5/epoch = 4 epochs (~2h)	~2 days
12 (heavy)	7 days	3 at 1/epoch → 3 at 2/epoch → 1 at 5/epoch = 7 epochs (~3.5h)	~7 days
25 (extreme)	7 days	16 at 1/epoch → 3 at 2/epoch → 1 at 5/epoch = 20 epochs (~10h)	~7.5 days

Why liquid staking loves this: Under normal conditions (1-4 nodes exiting), the entire queue flushes in a single epoch and exit time is just 2 days. The protocol can predict its exact queue position and calculate withdrawal timing deterministically. When exit pressure rises, the system automatically shifts to a more conservative pace, giving protocols a clear signal to adjust their redemption flow.

Trade-offs:

Most complex to implement (requires epoch hooks or a keeper-based trigger + adaptive rate logic).
The dual lever (churn rate + post-lock duration) gives fine-grained control but adds cognitive overhead.
When the queue is deep (> 10), exit times are still dramatically better than the current 30 days, but the 7-day post-lock provides a meaningful security buffer.
Churn rate boundaries (5 / 10) should be governance-adjustable as the network grows.

Additional Upgrade Opportunities

Since we'd be touching the contract anyway, it would be worth bundling other improvements:

Compiler upgrade to Solidity ≥0.8.x (built-in overflow protection, custom errors, gas optimizations)
Array compaction for the candidates list (eliminate zeroed entries, reduce gas for enumeration)
Event coverage for all state-changing operations (currently some paths emit no events)
ownerCount bookkeeping to accurately reflect the active validator set
Withdrawal batching. Currently withdraw(blockNumber, index) requires one call per entry; a withdrawAll() that claims all mature entries in a single transaction would drastically improve UX
View functions for queue position, estimated lock duration, pending withdrawal count, and total exiting stake
Timestamp-based delays instead of block-count, decoupling the lock period from block time fluctuations
KYC flow improvements with proper access control and state management
SafeMath / overflow protection for all arithmetic (native with 0.8.x)

Comparison Matrix

Feature	Current XDC	Scenario A (3-Tier)	Scenario B (Dynamic Curve)	Scenario C (Adaptive Churn)
Min unlock (< 5 pending)	~35d actual (1.296M blocks)	3 days	2 days	~2 days
Moderate unlock (5-10 pending)	~35d actual (1.296M blocks)	14 days	7-30 days	~2 days (queue wait + 48h)
Max unlock (> 10 pending)	~35d actual (1.296M blocks)	30 days	30 days	~7-7.5 days (queue wait + 7d)
Delay type	Block-count (drifts with block time)	Timestamp-based	Timestamp-based	Epoch + timestamp
Voter delay	~12d actual (432K blocks)	Unified with owner	Unified with owner	Unified with owner
Batch withdrawal	No (per-entry)	Yes	Yes	Yes
Predictability	Fixed	Very high (3 tiers)	Medium (continuous)	High (position-based)
Liquid staking friendly	Poor	Good	Very good	Excellent
Implementation complexity	-	Low	Low-Medium	Medium-High
Security under mass exit	Same 30d always	Full 30d fallback	Scales to 30d automatically	Throttled churn + 7d post-lock
Consensus layer changes	No	No	No	Possibly (epoch hooks)

What I'd Like to Hear From the Community

Which scenario resonates most with how you think XDC should evolve?
Are there hybrid approaches? For example, Scenario B (dynamic duration) + Scenario C (churn limit) combined.
What's the right security floor? Is 48 hours too aggressive for the minimum lock? Should it be 7 days?
Upgrade mechanism. Should this be a full contract migration with state transfer, or an upgradeable proxy pattern going forward?
Backwards compatibility. How do we handle existing stakers and pending withdrawals during migration?

The 30-day fixed lock was a reasonable default at launch, but the XDC ecosystem has outgrown it. Liquid staking, institutional staking services, and DeFi protocols all need a more dynamic validator lifecycle. Let's design it together.

References:

Enhancing the XDCValidator Smart Contract: Introducing Smart Contract Ownership, Ownership Transfers, and Automated Rewards

Arturo — Sun, 05 Jan 2025 05:33:07 +0000

https://forum.xinfin.org/t/proposal-for-enhancements-to-the-xdcvalidator-smart-contract/518

XDC Liquid Staking

Arturo — Sun, 22 Dec 2024 12:13:10 +0000

Learn about the XDC Liquid Staking System:

Introduction

Stake Your $XDC. Earn $XDC from Masternodes!

The XDC Liquid Staking System offers an accessible way for XDC holders to stake their tokens and earn rewards from masternodes without the usual barriers, such as high capital requirements, KYC restrictions, or hosting expenses.

How It Works

1- Stake and Receive Liquid Tokens

When you stake 1 $XDC in the system, you receive 1 $pstXDC (Proof-of-Stake XDC) in return. The exchange rate is always 1 $XDC = 1 $pstXDC.

$pstXDC represents your staked XDC and can be freely used across the ecosystem.

2- Vault or Masternode Minting

To stake, you first mint an XDC Vault or an XDC Masternode through the platform.

Deposit your $XDC into the Vault or Masternode. Once deposited, $pstXDC is automatically credited to your wallet.

3- Ecosystem Integration

$pstXDC can be used in DeFi applications, providing liquidity, earning yield, or for trading, all while your staked $XDC continues to earn rewards from masternodes.

Key Features and Benefits

Access to Masternode Rewards:
By staking through the liquid staking system, users earn rewards generated by XDC masternodes without needing to host or maintain the infrastructure themselves.
No KYC or High Entry Barriers:
Traditional masternode participation often requires significant capital (e.g., 10M XDC tokens) and compliance with KYC regulations. The liquid staking system eliminates these hurdles, making it accessible for all XDC holders.
Lower Costs:
Hosting expenses are managed at the protocol level, removing the technical and financial burdens on individual users.
Flexibility with $pstXDC:
$pstXDC acts as a liquid staking derivative, allowing holders to retain liquidity while earning staking rewards. This token can be transferred, used in decentralized applications, or redeemed for the original $XDC at any time.
Decentralized Reward Distribution:
Rewards from masternodes are distributed proportionally and transparently to all participants.

The XDC Liquid Staking System simplifies staking, removes barriers, and unlocks the potential of your $XDC while maintaining flexibility and liquidity. Stake today and put your XDC to work!

Two types of liquid staking:

Guides on the following links:

1- XDC Vaults: Link

XDC Vaults are integral to the XDC Liquid Staking System, providing a secure and efficient mechanism for staking $XDC tokens and receiving staking derivatives ($pstXDC). These vaults simplify the staking process, remove traditional barriers, and unlock new opportunities for XDC holders.

What Are XDC Vaults?

XDC Vaults are on-chain smart contract-based storage solutions where users deposit their $XDC tokens for staking. Upon depositing, users receive $pstXDC, a liquid staking derivative representing their staked $XDC.

[Informative] XDC Docs Update

Arturo — Thu, 11 Jul 2024 15:45:29 +0000

Hi Team,

I hope this message finds you well.

I’ve spent some time reviewing our current documentation, specifically:

Frankly, the current state of our documentation gives an impression of an old or abandoned blockchain. This is a significant concern, as our documentation is often the first touchpoint for new developers and users.

To get a sense of what top-tier documentation looks like, I explored the documentation of some of our competitors:

These platforms showcase up-to-date information, an easy-to-explore interface, and valuable resources that enhance user experience.

To be in the top 1, we must start taking care of the basics. Updating our documentation to match or exceed these standards is a critical step.

Let’s discuss and plan the necessary updates to make our documentation not only current but also highly user-friendly and informative.

Best regards.

XDC.DEV Platform Request

Arturo — Thu, 11 Jul 2024 15:38:28 +0000

Hey everyone,

I hope you're all doing well! I wanted to share an idea that's been on my mind lately. What do you all think about moving our XDC.dev community to the Discourse platform? I've been exploring it, and it seems like it could be a great fit for us. Here’s why:

Why Discourse?
Better User Experience:

Intuitive Interface: Discourse has a super clean and user-friendly interface that’s easy to navigate.

Mobile-Friendly: It works great on mobile devices, so we can stay connected even when we’re not at our desks.

Awesome Community Features:

Advanced Moderation: It comes with powerful tools to help keep our discussions organized and spam-free.
Custom Categories and Tags: We can easily organize topics, making it simpler to find what we’re looking for.

Boosted Engagement:

Real-Time Notifications: Get instant updates on discussions you’re interested in.

Interactive Conversations: Features like @mentions, likes, and rich text formatting make discussions more engaging.

Top-Notch Security and Performance:

Secure: Discourse takes security seriously, so our data will be safe.

Scalable: It can handle a lot of traffic, so it’ll run smoothly even as our community grows.

Benefits of Making the Switch

Simpler Communication: The threaded discussions and real-time notifications make it easier to follow and participate in conversations.

Better Community Management: The advanced tools and analytics will help our moderators keep things running smoothly.

Seamless Integration: Discourse supports integration with the tools we’re already using, so the transition should be pretty smooth.

What’s Next?

Share Your Thoughts: I’d love to hear what you all think about this idea. Please drop your thoughts in the comments below.

Plan the Move: Based on everyone’s feedback, we can come up with a plan to transition to Discourse without causing too much disruption.

Make It Happen: We’ll set up a timeline for the move and make sure there’s plenty of support to answer any questions.

Wrap-Up

I really think moving to Discourse could be a big win for our community. It promises a better experience for everyone and helps us stay connected and engaged. Your feedback is super important, so please let me know what you think!

Looking forward to hearing your thoughts!

BlockChain Explorers on XinFin Network [BlocksScan]

Arturo — Tue, 22 Aug 2023 08:56:38 +0000

BlocksScan XinFin Network

XinFin Network, as a public and open-source ledger, has the ability to provide information and data to network users.

One thing is to receive information in an organized and readable manner, and another is for it to appear all scattered.

It's of no use if I give you a dictionary that's all disorganized; it would be impossible to ﬁnd a single word.
Or if they provide you with a dictionary that hasn't included all the words it should.

The idea of this document is to make a portion of the information ﬂowing within the network visible, which currently the average user would only ﬁnd through the blockchain scanner.
Through this, we perform a comparison with another explorer, where these comparisons will reﬂect suggestions to add to BlocksScan.

For this, we take Etherscan as our reference: https://etherscan.io/

Main Page

Seeker

It would be nice to add the dropdown to perform a more individualized ﬁlter.

(Remove it from BlocksScan Explorer; It is as if my web page says Wordpress.)

Toolbar

Etherscan offers a vast array of sections for searching speciﬁc information about concrete data. We can observe this simply by looking at the section bar on the homepage:

Providing a practical and user-friendly interface to both regular users and developers seeking information while conducting relevant tests on their code is crucial. An example of this could be the dropdown menu under "Developers" or the one under the "More" tab.

APIS

Decent documentation is necessary. The speciﬁcations of the APIs should be included, for instance: a developer needs to know how many requests they can make if there is a maximum limit.
There should be a Gitbook accessible directly from the blockchain explorer. It should contain something like this:
https://docs.xdc.community/
https://docs.xdc.org/build-with-xdc/deploy-smart-contracts-on-xdc-network

If we observe the transition that other major companies are undergoing, we realize that they are moving away from using Swagger. Moreover, for new developers, it can present certain complexities.

The next step to professionalize the APIs in BlocksScan would be to create documents similar to what other companies are doing:

-Alchemy:
https://docs.alchemy.com/reference/api-overview

-Etherscan or Moralis would be good examples too.

XinFin Network is currently quite substantial and is increasingly catching the attention of users due to the rise in Market Cap and the visibility it's gaining at in-person Blockchain events and on social media platforms. Swagger is becoming inadequate for its current scale.

Txns When we access a transaction (Txns), it takes a long time to display the information related to that transaction. Is there a lack of data indexing?

On the other hand, if we access the TxHash of a transaction on Etherscan and go to "Logs," we encounter two things:

A visually appealing interface
The ability to convert hexadecimal values to decoded ones

BlocksScan appearance:

Data connection Data connection with one-page web links that display much more information about that speciﬁc data.

If we click on Gwei:

Leads us to: https://etherscan.io/gastracker

Furthermore, GAS is a piece of data that is not currently tracked on BlocksScan, and it's very important.

It indicates the price we will pay for using the network. In other words, it tells us how much XDC we will use to carry out transactions. Thanks to this, we can determine the minimum we need to pay in fees.

By expressing it in gas units relative to $, we can understand how much we can pay to prioritize our transaction and have it executed faster.

There are other examples:

If we click on ‘’Market cap’’:

Leads us to: https://etherscan.io/stat/supply
We can view detailed information about the types of supply based on rewards. If we click on:

Leads us to: https://etherscan.io/chart/etherprice

Latest Blocks

XinFin:

Etherscan:

If we click on ‘’View all blocks’’:

XinFin:

Etherscan:

We come across large boxes that provide additional information. Moreover, in the transaction concatenation, we have more columns on etherscan.

When searching in the explorer for an address:

-EVM compatible

Connecting the wallet address with other EVM networks that have balances associated with that address could indeed be an interesting feature.

-Balance and assets

In the blockchain, everything is public, including the balance. That's why we can see all the tokens a wallet holds from here.

This way, if, for instance, I published my address, you could know exactly how much I have down to the last dollar.

(etherscan)

https://etherscan.io/address/0xe81e54f36a9e6ee871aa0f2e9991889f7c414bae

Right next to the tokens dropdown, there's an icon of a wallet. If we click on it, it takes us to a unique wallet link.
Here, we can see in detail how many cryptocurrencies it holds and the quantity of each of them.

https://etherscan.io/tokenholdings?a=0xe81e54f36a9e6ee871aa0f2e9991889f7c414bae

NFTs

NFTs are currently one of the major focal points on the XDC network due to Prime Numbers.

On Etherscan, we have a plethora of information about these tokens:

If we click on "Top NFTs," which would be equivalent to XRC721 tokens on BlocksScan, we ﬁnd numerous columns with information about the collections.

XRC721, whereas on BlocksScan, the amount of information is less extensive.

If we enter a speciﬁc collection, we can see that on BlocksScan, it provides us with a series of information.

However, we can see that on Etherscan, there are more sections.

On the other hand, if we look at the rows of data, we come across 'Method' which indicates the executed function based on decoded input data.

The 'Item' column displays a small image of the NFT.

Links:

If we compare an NFT on Etherscan and another on BlocksScan, we discover very interesting information on the Etherscan NFT:

It would be great to have detailed information within the "Properties" section and the "Details" section.

Additionally, expanding the NFT information to include its activity, similar to how the following screenshot displays, would also be beneﬁcial:

Links:

//Post Written by Victor Manero (Prime Numbers Labs- Team)

Update Request of Masternode Interface

Arturo — Wed, 07 Jun 2023 13:19:57 +0000

In the rapidly evolving world of blockchain technology, staying updated is not just an option, but a necessity. As part of our continuous efforts to provide the best user experience, we are planning to upgrade our Masternode Interface. The goal is to make it more "Web3" compatible, thereby ensuring that our platform remains at the forefront of the blockchain revolution.

Web3
By updating our Masternode Interface to a more "Web3" design, we aim to provide our users with a more seamless and interactive experience, while also ensuring the highest level of security and privacy.

WalletConnect Integration
As part of the upgrade, we are also looking to expand our wallet support. We understand the need for our users to have a variety of options when it comes to wallets. Hence, we recommend integrating "WalletConnect" into our platform. WalletConnect is an open protocol for connecting desktop Dapps to mobile wallets using end-to-end encryption. By enabling WalletConnect, we will be able to support a multitude of wallets, thereby providing our users with greater flexibility and convenience.

KYC System
Know Your Customer (KYC) procedures are essential for ensuring the security of our platform and the integrity of our user base. However, we acknowledge that our current KYC system may not be as efficient as it could be. It's time for a change.

We recommend outsourcing our KYC procedures to a third-party provider. These providers specialize in KYC and have the resources and expertise to conduct thorough and efficient identity verification. By doing so, we can speed up the KYC process, reduce the workload on our internal team, and most importantly, provide a smoother and faster onboarding process for our users.

Conclusion
These upgrades represent our commitment to staying ahead of the curve in the blockchain space. We believe that by embracing Web3, expanding our wallet support with WalletConnect, and enhancing our KYC procedures, we can provide a more robust, user-friendly, and secure platform for our users. We look forward to sharing more updates as we embark on this exciting journey towards a more decentralized future.

XDC STAKING by Prime Numbers

Arturo — Thu, 19 Jan 2023 08:11:59 +0000

Message from Arturo:

With this post, I want to show you the final version of the XDC Staking NFTs.
We put a lot of work into this. You will be able to start staking $XDC in around one month.

XDC Staking & NFT Mechanics

Introduction
XDC STAKING NFTs is an NFT collection with a high utility.

First non-custodial and trustless $XDC staking.

These NFTs are like "vaults" where you put your XDC.

Welcome to the explanatory post about how NFTs and XDC staking will work.

The collection consists of 5557 NFTs, of which Prime Numbers make 5542, and 15 have the same aspect as the Prime Numbers Handmade NFTs.

New "MERGE SYSTEM" and "REFUND SYSTEM"

Rewards:
These NFTs are going to get the following rewards:

VARIABLE REWARD: 10% of Prime Numbers Finance Profits

FIXED REWARD: In the first two years, 30% of the funds from the minting will be rewarded to the XDC Staking NFTs.
We will give the 30% of the funds from the minting because Prime Numbers Finance (Lending and Borrowing Protocol) development is ongoing, and we want to start giving rewards.

The 10% of Prime Numbers Finance profits should be higher than the 30% of the minting funds.
All of these rewards will be paid on $XDC.

1- Fixed Reward
30% of the minting funds will be rewarded to the NFTs in the first two years. After these first two years, the non-locked and non-custodial $XDC staking reward will be 10% of the profits from Prime Numbers Finance.

PAYOUT Formula Staking
a= total multiplier of the NFT
a = x +y
x= base multiplier [multiplier per rarity of the NFT]
y= added multiplier [multiplier per level of the NFT]

We have found a way to make the rewards fair for everyone:
b= XDC staked per NFT

HALF XDC REWARD given to "a" -> [Total Multiplier] of the NFTs
HALF XDC REWARD given to (“a” * ”b”) -> [(Total Multiplier)*XDC)]

Current(14-January) Reward Pool: 1,275,000 $XDC
The reward pool depends on the total minted NFTs.

2- Prime Numbers Finance
Prime Numbers XDC Staking NFTs will receive 10% of Prime Numbers Finance profits.

XDC NFT Staking (optional):
When your NFT reaches the MAX LIMIT (100 000 $XDC staked inside the NFT), you will be able to lock this NFT to get an additional 7% APY

The lock period will be one year.
The XDC inside this NFT is used to host masternodes.
The effect of the lock will be confirmed to the NFT once the masternode creation is complete.

The reward will be paid monthly to the NFT.

Example: You have an NFT with 100 000 $XDC. And you lock it.
From the lock, you get 7% of 100 000 $XDC -> 7000 $XDC
And a part of the 10% of Prime Numbers Finance profits and an amount of the 30% minting funds.

Different Rarities:
Prime Numbers Handmade NFTs
The first 15 Prime Numbers consist of handcrafted images from our Art Director.

The owners of these Prime Numbers Handmade NFTs will get the XDC Handmade NFTs airdropped.

Base Multiplier = 2.

XDC STAKING NFTs
1 Plentiful: Base Multiplier: 0.3

https://www.youtube.com/shorts/AHFVu6KoanY

2 Common: Base Multiplier: 0.4

https://youtube.com/shorts/40sOPUIhxxY

3 Uncommon: Base Multiplier: 0.5

https://youtube.com/shorts/dgOJCHaoVaY

4 Rare: Base Multiplier: 0.7

https://youtube.com/shorts/BW9jU2v6bcE

5 Epic: Base Multiplier: 0.9

https://youtube.com/shorts/-BWwHU6ynkg

6 Legendary: Base Multiplier: 1.2

https://youtube.com/shorts/O1FZ2ZhyUJE

7 Mythic: Base Multiplier: 1.5

https://youtube.com/shorts/MehEtkevXdg

8 Godly: Base Multiplier: 1.9

MYSTERY ❤ You will see it on the Reveal.

MERGE SYSTEM

We are happy to show you how our merge NFTs system works.

You can merge 2 NFTs of the same rarity to get one of the following rarities.

Examples:
The merge of 2 common NFTs will make one uncommon NFT.
The merge of 2 mythic NFTs will make one godly NFT.

Godly is the best rarity you can get using the merge system.

When you merge 2 NFTs, these 2 NFTs get burned, and you get 1 NFT of the next rarity.

This makes the NFTs deflationary.

Refund System

Here we show you how our merge NFTs system works.

You can use the "BurnToRedeem" button to get 30 $PRNT (Refund System)

This button breaks the NFT and extracts all the $XDC inside the NFT.
It cannot be reversed; it will burn your NFT and send all the XDC to your wallet. Also, you get 30 $PRNT when you break the NFT.

Examples:
1- If you test and don't like how the staking system or rewards work, you can decide to "BurnToRedeem" the NFT to get 30 $PRNT.

2- You minted and got one low rarity, and you prefer 30 $PRNT; you can also use this system.

3- The 30 $PRNT is more valuable than the NFT, and you decide to "BurnToRedeem" as an investment option.

This makes the NFTs deflationary.

Staking system with NFTs
We present to you our revolutionary staking system featuring NFTs.

To earn rewards with XDC Staking NFTs, you will need to stake your $XDC. This does not happen in an ordinary way; however, when we stake at the Prime Numbers ecosystem, we stake inside the NFTs. This means your staked tokens will give an intrinsic value to the NFT and can be traded along with the NFT on any NFT marketplace as a packaged deal. The tokens can be recovered from the NFT by "Empty NFT," "Withdraw XDC," or "BurnToRedeem."

When we stake our tokens in the NFT, they will gradually level up. You will able to stake as much as you want until the max limit [100 000 $XDC per NFT]

Your share depends on the multiplier of your NFT, which is based on both its level(added multiplier) and its rarity(base multiplier).

The higher your level and the more rarity you have, the more reward you will get.

These NFTs, upon receiving the tokens, will level up from this. The staking airdrop will be factored in based on the amount of $XDC inside the NFT.

Max limit [100 000 $XDC per NFT]
100 000 $XDC is the max amount you can stake, but the NFT XDC balance can go above 100 000 $XDC due de rewards.

The information you can see in the staking interface:
Type: X

Attributes
Global rarity:
Global rarity name:
Base multiplier:

Staking
Total $XDC:
Total Staked $XDC:
Total Rewarded $XDC:
Level:
Stake in level:
Last Stake Time:
Last Month's Reward:
Added multiplier:
$XDC to level up:
Total multiplier:
Locked:

Total Multipliers
You will get a Total Multiplier depending on your Base Rarity and/or level.
Total Multiplier = Base Multiplier + Added Multiplier

Example:

NFT with Base Multiplier 2.0 and level 18 (added multiplier 1.8) will be a total multiplier of 3.8

How to get a $XDC Staking NFT?
Current minting price: 3500 $XDC

We will sell 5300 NFTs in the minting waves.

31 NFTs will be airdropped to the PRNT NFTs Plentiful holders.
15 NFTs will be airdropped to the PRNT NFTs Handmade holders.
1 NFT will be airdropped to the PRNT NFTs Godly Holder.

210 NFTs will be minted for development purposes + marketing.

Important Data:
MAX Number of NFTs: 5557

XDC staking will be released just after the Reveal.

Reveal is when you will be able to see what NFT you received.

How to stake?
The tutorial will come after the minting.

Frequently Asked Questions

When are the staking rewards sent?
Smart-contract send the rewards on the last day of every month.

When a person is in the process of leveling up, and a rewards drop takes place. Since the rewards drop into the NFT, does that help increase the levels?
Yes.

Staking Interface Buttons

"Staking" Button
This button is used for stake inside the NFT.

"Transfer" Button
This button is used for transferring NFTs between wallets.

"Empty NFT" Button
This button takes out the NFT balance.
To use this button, you need the NFT without interactions the previous seven days before trying to use "Empty NFT."
Interaction = Transfer, Stake
Example: Your NFT has 30 000 $XDC; if you press this button, all the staked $XDC will go to your wallet.

"WITHDRAW XDC" Button
This button takes out the chosen NFT balance.
To use this button, you need the NFT without interactions the previous 15 days before trying to use "WITHDRAW XDC."
Interaction = Transfer, Stake
Example: Your NFT has 30 000 $XDC; if you press this button and introduce 10 000 $XDC, 10 000 $XDC from your staked $XDC will go to your wallet.

"BurnToRedeem" Button
This button breaks the NFT and extracts all the $XDC inside the NFT.
It cannot be reversed; it will burn your NFT and send all the XDC to your wallet. Also, you get 30 $PRNT when you break the NFT.
"Merge NFTs" Button
This button merges 2 NFTs of the same rarity to get one of the following rarities.

"LOCK NFT" Button
This button locks this NFT for one year to get an additional 7% APY.
When your NFT reaches the MAX LIMIT (100 000 $XDC staked inside the NFT), you will be able to lock this NFT to get this reward.

Summary
After reading the entire post, we can get the following conclusions:

Due to our level system, trying to achieve the highest level can be very interesting and rewarding. By actively leveling your NFT, you quickly raise in reward multiplier, resulting in a larger slice of the $XDC pie.

Depending on the rarity of the NFT and level, you can get up to +4x in the rewards.

Integration Request

Arturo — Fri, 12 Aug 2022 14:35:38 +0000

Hello! Today I want to request the integration of the XDC network into the following tools.

The first one is https://www.openzeppelin.com/defender

Defender helps developers with a lot of things:

Automate and secure all your smart contract administration.
Build with private and secure transaction infrastructure
Create automated scripts to call your smart contracts
Monitor and respond to smart contract exploits
Quickly implement security best practices

The second one is https://thegraph.com/en/

The Graph is an indexing protocol for querying networks like Ethereum and IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

How to integrate? https://thegraph.com/docs/en/developing/supported-networks/

https://github.com/graphprotocol/graph-node

Bugs / Errors / Wrong Info

Arturo — Mon, 01 Aug 2022 12:08:11 +0000

I want to say that this is my experience and personal opinion, sorry if I sound arrogant. I'm just trying to help.

—----------------------------

Testnet is not working well. Our NFT marketplace smart contract only works on mainnet or other networks.

Due XDCpay being outdated, XDCpay also doesn't work with the following smart contract.
XDCpay is missing some functions that Metamask's last version has.

You have here the smart contract https://xdc.blocksscan.io/address/xdc00000000006c3852cbEf3e08E8dF289169EdE581 we make it free to use for everyone on the xdc blockchain. With this, you can also bridge NFTs from other networks to XDC.

Smart contract: https://github.com/PrimeNumbersNFT/seaport
—--------------------
The main network not working with "String reverts", for example when you have a revert on the smart contract. The network doesn't indicate what revert happened. (This is mandatory to fix it or most of the applications will not work if a revert happens)

`function stake(uint256 tokenId, uint256 amountToStake) public nonReentrant {

    require(_exists(tokenId), "Invalid tokenId");       
    require(amountToStake <= _levels[_nfts[tokenId].level].dailymax, "Daily limit reached");
    require(_nfts[tokenId].laststake == 0 || _nfts[tokenId].laststake + 1 days < block.timestamp, "Daily limit reached");
    require(prnt.allowance(msg.sender, address(this)) >= amountToStake,"Insuficient Allowance");
    require(prnt.transferFrom(msg.sender,address(this),amountToStake),"transfer Failed");

    if (_nfts[tokenId].prnt==0){
        stakeValues.multiplierTotal +=  _nfts[tokenId].nftmultiplier;
    }else{
        stakeValues.totalweight -= _nfts[tokenId].weight;
    }

    stakeValues.totalPRNT += amountToStake;
    _nfts[tokenId].laststake = block.timestamp;
    _nfts[tokenId].stakeinlevel+=amountToStake;
    _nfts[tokenId].prnt+=amountToStake;
    if ( _nfts[tokenId].stakeinlevel >= _levels[_nfts[tokenId].level].tolevelup && _nfts[tokenId].level < 20){
        _nfts[tokenId].level += 1;
        _nfts[tokenId].stakeinlevel = 0;
        stakeValues.multiplierTotal +=  _levels[_nfts[tokenId].level].levelmultiplier;
        if (_nfts[tokenId].level > 1){
            stakeValues.multiplierTotal -=  _levels[_nfts[tokenId].level-1].levelmultiplier;
        }
    }
    weightCal(tokenId);
}

`
The requires don't work, the network only tells you that it's an error.

—-----------------------------------

XDCpay is super old, and web3modal does not support it. We needed to build a web3modal custom for adding xdcpay. XDCpay doesn't connect with snapshot.org. I suggest to fork the last version of metamask and adding the custom logos and information.

—-------------------------
https://rpc.xinfin.network is not working with NFT DApps. You need to use https://erpc.xinfin.network
—-------------------------------

xdc.observatory is not working, lots of missing info, no nfts... Lots of missing txs

—--------------------------------------

XinFin's website is outdated. https://howto.xinfin.org/xinfinpay/features/ This is super old also

https://howto.xinfin.org/get-started/token/ outdated info...

We have the message of begin innovative and super powerful, we shouldn't have these errors, outdated info, problems...

https://medium.com/xinfin no posts since months. Medium is one of the most used media platforms, in my opinion, you should publish all the updates here.

If you want a call with me or something just contact me on telegram @Arturo_Cantera or email: admin@primenumbers.xyz