Developers Forum for XinFin XDC Network: Quincy Jones

Crypto Feels Like Whatever People Are Doing

Quincy Jones — Thu, 16 Apr 2026 18:40:02 +0000

One thing I’ve started to notice about crypto, and I didn’t really get this at first, is that it’s not actually dictated by what’s “best” or even what’s most advanced. It’s dictated by activity. Just whatever people are doing at scale, that becomes the space, at least for a period of time.

Like when things are hot, it feels obvious. Everyone’s trading, everyone’s posting, there’s new projects every day, people are jumping chains, minting, flipping, whatever it is. And because that activity is so loud, it kind of defines reality. It’s like, okay this is crypto right now. This is what matters.

NFTs had that moment. Memecoins had that moment. Even certain ecosystems, they didn’t just win because they were better technically, they won because people were there, doing things, interacting, creating momentum. And momentum is weirdly one of the most powerful forces in this space.

But then things slow down, and it almost feels like everything disappears. Prices drop, timelines get quiet, nobody is really talking the same way anymore. And it can feel like the whole space just… died or something. But it didn’t, it just changed form.

Because what’s happening underneath during those slower periods is honestly kind of more important, it’s just not as visible. Builders are still there, probably even more focused because there’s less noise. People are working on infrastructure, fixing problems, trying to actually make things usable instead of just exciting. It’s not flashy, it doesn’t go viral, but it’s real.

There’s almost like two versions of crypto. The one you see during hype cycles, and the one that actually gets built when nobody is paying attention. And they don’t really look the same at all.

The hype version is fast. It’s social. It’s easy to understand. You can jump in, participate, feel like you’re part of something immediately. And that’s why speculation becomes such a big part of it, because speculation itself is activity. It creates movement, and movement pulls people in.

But the quieter version, it’s slower, more technical, sometimes kind of boring if we’re being honest. But that’s where a lot of the real foundation gets laid. The stuff that actually sticks around longer than a cycle.

And I think the interesting part is how those two phases feed into each other.

Because the things that get built in the quiet don’t just stay there. They come back during the next hype cycle, just in a different form. Usually simplified, sometimes repackaged, but they’re rooted in that earlier work that nobody really saw at the time.

So yeah, crypto is driven by activity, but not all activity is the same. Some of it is loud and temporary, and some of it is quiet and foundational. And if you only pay attention to one, you get a really incomplete picture of what’s actually going on.

It’s not just what people are building, it’s what people are choosing to do at scale. That’s what defines the space, at least in that moment.

The New Frontier of XDC Subnets

Quincy Jones — Wed, 05 Nov 2025 19:28:33 +0000

So here’s the thing about XDC Subnets. They’re basically the missing link between private blockchains that companies love for control and the public XDC network that everyone uses for open trade. Think of it like having your own private world inside the internet that can still plug into the larger web whenever you want. An enterprise can build its own subnet where all its internal assets, transactions, and data stay private, but the magic is that those same assets can travel out to the public XDC chain when it’s time to trade or settle with other organizations.
Inside a subnet, a company can create its own tokenized system. Every resource, share, or piece of data can exist as a digital asset. These assets can move around privately for accounting, record keeping, or even internal trades. The company has complete control, kind of like running its own economy. But when it wants to interact with another business, it can move those tokens to the public network. That’s when the subnet connects to the broader world and the assets become tradeable. It’s smooth, it’s efficient, and it keeps everything secure until you’re ready to go public.
This setup completely changes how tokenization works. Instead of waiting for some big public exchange to list assets, enterprises can start small on their private subnets. They can create tokens for internal use, private sales, or equity distribution. When they’re ready, those tokens can step into the public arena, bringing liquidity with them. It’s like a new kind of incubation model for digital finance where innovation happens privately first and then expands outward.
The potential use cases are endless. A real estate company could tokenize its property data and manage settlements privately before offering shares to investors on the public chain. A supply chain network could track goods internally while using the public side to verify authenticity. Financial institutions could test new instruments safely before connecting them to global markets.
What makes it all exciting is the freedom this brings. Every organization can now build its own financial sandbox, run experiments, and still plug into a global settlement layer when it’s time to do business. XDC Subnets make blockchain feel less like a locked system and more like an open playground for value, trust, and trade.
Setting up an XDC Subnet is like spinning up your own mini-blockchain inside the XDC ecosystem. It’s private, fast, and fully under your control, but it still connects to the public XDC network so the outside world can verify everything you do. Think of it as your own private island that occasionally sends postcards to the mainland to prove it’s real.
Your subnet is where all your transactions live. It’s got its own validators that produce blocks and keep your internal system humming. Then there’s the Relayer, which acts like a messenger or a delivery guy. Every so often, it grabs a snapshot of your subnet’s activity called a checkpoint and delivers it to a Checkpoint Smart Contract (CSC) sitting on the main XDC chain. The CSC is like your public receipt. It’s proof that your subnet’s data is authentic and accounted for on the global network.
Now, setting it up isn’t hard. All you really need is an Ubuntu server with Docker installed. After that, you just fire up the Subnet Deployment Wizard. It walks you through everything creating your network, generating node keys, linking to the parent chain, and deploying your CSC. The wizard even gives you your CSC address right away that’s what connects your subnet to either the XDC mainnet or the Apothem testnet. You can also decide how often your subnet sends checkpoints. If you want maximum precision, send them every block. If you’d rather save gas, set it to a checkpoint periodically.
Once everything’s running, you configure the Relayer with your subnet’s RPC endpoint, the parent chain’s endpoint, and your CSC address. Then it just does its job quietly in the background, keeping your subnet synced with the public chain. You can open up the Subnet Dashboard anytime to watch the magic happen blocks being produced, validators doing their thing, checkpoints showing up live on XDC. In a few minutes, you’ve got your own fully functional, verifiable blockchain.
And here’s where it gets even cooler once your subnet is online, you can integrate Subswap. It’s a decentralized exchange built specifically for subnets, so your users or organizations can trade tokens directly within your private network or bridge them out to the public XDC chain when you’re ready. Think of Subswap as the liquidity layer for your subnet. It turns your private ecosystem into an actual marketplace. You can launch internal assets, manage private liquidity pools, and even open up selective public trading.
At the end of the day, XDC Subnets give you the best of both worlds — the privacy and control of your own blockchain with the security and visibility of the XDC main network. You can build, trade, and experiment freely inside your subnet, then connect to the public chain whenever it’s time to scale. With the Subnet Deployment Wizard and Subswap ready to go, setting one up feels less like a tech project and more like unlocking your own digital economy. It’s simple, powerful, and kind of addictive once you see it working. Honestly, you should try it out.

All you need to get started is to run this script on the machine you want to run your subnet and open the deployment wizard on port 5210!

curl -0 https://raw.githubusercontent.com/XinFin0rg/Subnet- Deployment/v2.0.0/container-manager/start.sh chmod +x start.sh /start.

[Informative] How NFTs can be batched, creating new markets for batched assets

Quincy Jones — Wed, 18 Oct 2023 18:00:35 +0000

The concept of batched assets plays a pivotal role in contemporary asset management, serving as a cornerstone for optimizing processes, cost reduction, and the streamlining of diverse financial and operational activities.

In the context of smart contracts, an illustrative example involves the creation of a smart contract capable of consolidating tokens from multiple contracts, even encompassing multiple tokens within a singular contract. These aggregated tokens are then batched into a single token, offering possessors the ability to redeem the underlying tokens encapsulated within the smart contract. Such a tool finds valuable application in the realm of financial investments, particularly in the tokenization of collective assets managed as a unified entity.

One compelling instance of batched assets emerges within the sphere of investment portfolios. Here, the grouping of akin financial instruments, spanning stocks, bonds, and real estate, enables investors to effectively oversee and manage their portfolios, informed by comprehensive performance data.

Furthermore, in supply chain management, this concept underpins efficient inventory control, while in the tech sector, batched assets manifest in software updates. Software developers routinely bundle multiple patches and enhancements into a cohesive batch, facilitating seamless updates and bolstering system stability and security.

In manufacturing, batched assets are integral to production lines, where products with congruous specifications or production requisites are produced in clusters. This approach curtails setup and transition times, driving heightened efficiency and cost-effectiveness, particularly within the realm of collecting accounting in the form of NFTs.

The tokenization of diverse assets and objects using NFTs, alongside their integration into a contract governed by an NFT, offers a sophisticated mechanism for the management of multiple assets.

As the DeFi (Decentralized Finance) landscape matures, the sheer volume of tokens in circulation is poised to expand significantly, rendering batch processing an essential strategy to minimize operational overhead and complexity when grappling with these novel forms of tokenized assets.

//SPDX-License-Identifier: MIT

pragma solidity ^0.8.9;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/token/ERC1155/IERC1155.sol";
import "@openzeppelin/contracts/utils/math/SafeMath.sol";

/// @title Multi Asset Batch Contract
/// @author Quincy J
/// @notice This contract is meant to allow a multitude of different assets from different contracts to be referenced by a single token
/// @dev This contract is built to allow for more complex contracts to only have to manage  a single token rather than a complex multitude of different tokens

contract MultiAssetBatch is ERC1155{
    uint public handlerToken;
    string public batchName;
    uint public tokenIDNumber = 0;
    uint public maxBatchSize; //50-100 recomended

    constructor(uint _totalHandlers,string memory _URI,string memory _batchName,uint _maxBatchSize) ERC1155(_URI) {
        handlerToken = uint(keccak256(abi.encodePacked(_URI)));
        _mint(msg.sender,handlerToken,_totalHandlers, "");
        batchName = _batchName;
        maxBatchSize = _maxBatchSize; 
    }

    mapping(uint => Assets) assetID;
    mapping(address => Assets) assetContract;
    struct Assets{
        address assetContract;
        string assetName;
        uint[] amount;
        uint[] assetID;
        uint count;
        bool exist;
    }

    modifier handler{
        require(balanceOf(msg.sender,handlerToken) >= 1, "user does not hold handler token");
        _;
    }

    function addAssets(address _contract,string memory _assetName,uint[] memory _id,uint[] memory _amount)public handler returns(string memory,bool){
        require(tokenIDNumber <= maxBatchSize,"Contract has hit Max Batch limit");
        require(_id.length ==_amount.length ,"both the token id and the ammount arrays must have the same length");

        ERC1155 tokenContract = ERC1155(_contract);

        if(assetContract[_contract].exist == false){
            assetContract[_contract] = Assets(_contract,_assetName,_amount,_id,tokenIDNumber,true);
            assetID[tokenIDNumber] = Assets(_contract,_assetName,_amount,_id,tokenIDNumber,true);
            tokenIDNumber++;

            for(uint i =0;i<= _id.length;i++){
                require(tokenContract.balanceOf(msg.sender,_id[i]) >= 1,"user is missing a token");
            }

            tokenContract.safeBatchTransferFrom(msg.sender, address(this), _id, _amount, "");
            return ("new asset added",true);

        }else if(assetContract[_contract].exist == true && _id.length != 0 && _amount.length != 0 && _amount.length == _id.length){
            for(uint256 i = 0; i < _id.length; i++){
                assetContract[_contract].assetID.push(_id[i]);
                assetContract[_contract].amount.push(_amount[i]);

                assetID[assetContract[_contract].count].assetID.push(_id[i]);
                assetID[assetContract[_contract].count].amount.push(_amount[i]);
            }
            tokenContract.safeBatchTransferFrom(msg.sender, address(this), _id, _amount, "");

            return ("Assets Added",true);
        } else {
            return ("asset already exist",false);
        }
    }

    function redeemAssets()public handler returns(bool){
        for(uint i; i <= tokenIDNumber;i++){
            ERC1155 tokenContract = ERC1155(assetID[i].assetContract);
            tokenContract.safeBatchTransferFrom(address(this),msg.sender, assetID[i].assetID, assetID[i].amount, "");
        }
        return true;
    }

    function viewAssets(uint _tokenIDNumber)public  view returns(address,string memory,uint[] memory,uint[] memory,uint,bool){
        return (assetID[_tokenIDNumber].assetContract,assetID[_tokenIDNumber].assetName,assetID[_tokenIDNumber].amount,assetID[_tokenIDNumber].assetID,assetID[_tokenIDNumber].count,assetID[_tokenIDNumber].exist);
    }

    //ERC1155Received fuctions
    function onERC1155Received(address, address, uint256, uint256, bytes memory) public virtual returns (bytes4) {
        return this.onERC1155Received.selector;
    }
    function onERC1155BatchReceived(address, address, uint256[] memory, uint256[] memory, bytes memory) public virtual returns (bytes4) {
        return this.onERC1155BatchReceived.selector;
    }
    function onERC721Received(address, address, uint256, bytes memory) public virtual returns (bytes4) {
        return this.onERC721Received.selector;
    }

    fallback() external payable {}
    receive() external payable {} 
}

Github: https://github.com/CoinClubQuincy/XDC-BrokerageDapp/blob/main/contracts/BrokerageTools/MultiAssetBatch.sol

[Informative]How Brokerage DApps can change trade finance on the XDC network

Quincy Jones — Mon, 21 Aug 2023 18:01:28 +0000

Most of the crypto space is quite familiar with the notion of NFTs and marketplaces. Typically, when people refer to these different types of instruments in Blockchain technology, they often refer shallowly to pictures being sold in the new online markets. This tends to create a misconception that NFTs are merely pictures, rather than a shared accounting tool to represent a particular object of ownership. NFTs are unique digital objects residing within smart contracts that can be used as units of account by shared applications. These objects can be referenced as derivative objects, such as a representation of a stock or a currency, or they could be abstract representations of some piece of code, like possessing a token to allow access to an application, using it as a key license, or even keeping track of scores.

Previously, I wrote a smart contract to create a representation of an asset as a token in my article titled "A Conceptualization on How Brokers, Banks, and Financial Institutions can Tokenize Assets on XDC":

[(https://www.xdc.dev/yourbroquincy/a-conceptualization-on-how-brokersbanks-and-finance-institutions-can-tokenize-assets-on-xdc-2g17)]

In that article, I explained how a token can be used as a unit of account for traditional assets, similar to how assets can be represented in a database. What makes the token special on the blockchain is that it can be referenced by third-party applications like marketplaces and other DApps. In this article, I aim to articulate how new markets can be formed and how tokenized assets can be automated in these new marketplaces.

To demonstrate how you can automate assets on XDC, I forked an NFT marketplace repository from TronzitVeca’s ERC1155-Marketplace-Contract. Using my previous Assets contract and creating a portfolio contract, I managed to create a 4-contract DApp that enables the Marketplace to trade assets and a portfolio to manage assets for users, and allowing them to interact with the marketplace.
A DApp like this is analogous to an application like Robinhood, but with three main differences:

The infrastructure is self-hosted. So any broker interacting with this application does not need to set up or manage in infrastructure of the application
Users can self-custody assets via access to their portfolio contract, enabling them to move between different marketplaces and brokers with ease. The user has a portfolio generated by the original broker but can take that portfolio to other brokers while remaining in potential compliance rules established by the portfolio and marketplace.
Broker-dealers and other firms can engage with each other via the decentralized marketplaces. Other broker-dealers can allow their users portfolios to interact with the marketplaces, providing more options to their users and additional liquidity in their marketplace.

As more broker-dealers create their marketplaces tailored to their clientele, the number of financial participants and the necessary liquidity for exchanges will exponentially increase. Each broker can access the marketplaces of others, and clients from different brokers can access the assets of other marketplaces if liquidity is needed locally.

This enables easier and faster trading between partners and investors. Traditionally, trading between finance partners required intricate relationships and redundant record-keeping. With partners using the XDC network as a shared accounting system, asset transfers become significantly quicker, and partners don't need to sync extensively to ensure accurate recording. What used to take days can now happen in seconds.
Similar to how social media enabled greater online connections, blockchain technology allows banks and financial institutions to trade over the internet on the blockchain with more parties than they could otherwise.

This contract can be broken into 4 parts

Marketplace Contract [https://github.com/TronzitVeca/ERC1155-Marketplace-Contract]The marketplace is where the Assets are located to be traded, this is no different than most NFT marketplaces the main difference being The assets held in this one are Tradition assets listed by broker-Dealers to help facilitated the sale to
Portfolio Ledger
The portfolio Ledger is a contract that generate Portfolio contracts and keeps track of all the users who are interacting with a particular Marketplace These portfolios can be possessed by other brokers or just investors interacting with the Marketplace
Portfolio contract
The portfolio contract is a way for users to directly interact with the Marketplace and custody Assets, that acts a a basket that can manage and interact with 3rd party assets while giving
The Asset that gets traded [(https://www.xdc.dev/yourbroquincy/a-conceptualization-on-how-brokersbanks-and-finance-institutions-can-tokenize-assets-on-xdc-2g17)] The underlying Asset that get traded and owned within this application

Portfolio Ledger


contract portfolioLedger{
    string portfolioTokenURI;   //URI formart for users
    address marketplaceAddress; //address of marketplace Contract

    uint totalAccounts = 0;

    constructor(uint _totalHandlers,string memory _URI,string memory _marketplaceName){
        portfolioTokenURI = _URI;
        marketplaceAddress = address(new Marketplace(_totalHandlers,_URI,_marketplaceName));
        totalAccounts++;
    }
    mapping(string => Ledger) ledger;
    mapping(uint => numberLedger) numbLedger;
    struct Ledger{
        string account;
        uint accountNumber;
        address portfolio;
        bool exist;
    }
    struct numberLedger{
        string account;
        address portfolio;  
        bool exist; 
    }
    //Create new User Account
    function createAccount(string memory _account)public returns(string memory,address){
        require(ledger[_account].exist == false, "account already exist");
        address portfolioContractAddress; 
        portfolioContractAddress = address(new Portfolio(portfolioTokenURI,_account,address(this),marketplaceAddress,msg.sender));
        ledger[_account] = Ledger(_account,totalAccounts,portfolioContractAddress,true);
        numbLedger[totalAccounts] = numberLedger(_account,portfolioContractAddress,true);
        totalAccounts++;
        return ("new account created", portfolioContractAddress);
    }
    //check and view new user Account
    function checkAccount(string memory _account,uint accountNumber)public returns(string memory,address,bool){
        if(ledger[_account].exist = true || numbLedger[accountNumber].exist){
            return (ledger[_account].account,ledger[_account].portfolio,ledger[_account].exist);
        }else{
            return ("none",0x0000000000000000000000000000000000000000,false);
        }
    }
    //forward funds from one user name to another
    function forwardFunds(string memory _reciver)external payable returns(bool){
        string memory account_;
        address portfolio_;
        bool exist_;
        (account_, portfolio_, exist_) = checkAccount(_reciver,0);
        require(exist_ == true, "User does not exist");
        payable(portfolio_).transfer(msg.value);
        return true;
    }
}

Portfolio Contract

contract Portfolio is ERC1155{
    uint public handlerToken;
    string public accountName;
    uint marketplaceCount =0;

    Marketplace public marketplace;
    portfolioLedger public DAppLedger;
    address private ledgerPrivate;
    address currentOwner;

    event changedMarketPlace(string _newmarketplace);
    event changedOwner(string _brokerMSG,address _newOwner);

    mapping(address => savedMarketPlaces) savedmarketplace;
    mapping(uint => savedMarketPlaces) marketplaceNumber;
    struct savedMarketPlaces{
        address marketplaceAddress;
        string marketplaceName;
        bool exist;
    }

    constructor(string memory _URI,string memory _name,address _DAppLedger,address _marketplace,address user) ERC1155(_URI) {
        handlerToken = uint(keccak256(abi.encodePacked(_URI)));
        _mint(user,handlerToken,1, "");

        accountName = _name;
        ledgerPrivate = _DAppLedger;
        DAppLedger = portfolioLedger(_DAppLedger);
        marketplace = Marketplace(_marketplace);

        logNewMarketPlace(address(_marketplace));

        currentOwner = user;
    }
    modifier broker{
        require(marketplace.balanceOf(msg.sender,marketplace.handlerToken()) >= 1, "broker does not hold handler token");
        _;
    }
    modifier handler{
        require(balanceOf(msg.sender,handlerToken) >= 1, "user does not hold handler token");
        _;
    }
    function resetOwner(address _newOwner) public broker returns(address){
           _mint(_newOwner,handlerToken,1, "");
           _burn(currentOwner,handlerToken,1);
           currentOwner = _newOwner;

           emit changedOwner("The registerd broker has chaged the owner of this contract",_newOwner);
           return _newOwner;
    }

//Delegate functions that interact directly with the marketplace
}

The future of blockchain technology is about connecting siloed entities that struggle with maintaining settlement and moving capital among multiple parties globally. With the XDC network and connected markets, the means of connection have never been easier. Marketplaces can reference liquidity from other marketplaces directly, brokers can interact without intermediaries, and investors can self-custody assets, enabling more people to participate directly. This reduces the cost and ease of access to financial services, with the barrier to entry lowered to having an internet connection.

The more participant that operate in this way the more engagement this online economy can facilitate an the better the trade volume globally.

Github: https://github.com/CoinClubQuincy/XDC-BrokerageDapp

A Conceptualization on How Brokers,Banks and Finance Institutions can Tokenize Assets on XDC

Quincy Jones — Thu, 27 Jul 2023 17:46:57 +0000

Being able to tokenize assets, such as commodities, securities, derivatives, currencies, and other types of assets, can allow financial institutions like banks and brokerage firms to have easier means of managing, trading, and accounting for different assets, not only for themselves but also for their trade partners.
These organizations can offset databasing costs by having the accounting of their assets on decentralized networks, making them easier to exchange and cheaper to operate. By moving hosting fees to transaction fees, the management of these assets becomes incredibly inexpensive and allows these organizations to focus more on their business model rather than on the hosting and operation of the systems that run their business.
Having assets tokenized on decentralized networks allows for a shared accounting of unique assets that would otherwise be siloed in independent databases operated by individual organizations. The means of syncing information between organizations during an exchange or transfer can be slow and a manual process when dealing with international organizations. When these assets are tokenized and used as shared accounting tools, the means of exchanging ownership of different assets becomes simple.
I built a proof-of-concept smart contract that takes the place of a broker who is not only tokenizing their possessed assets (asset certificates custodied under management) for their clients but also allows for these assets to be exchanged with other brokerage services. This contract is meant to illustrate that utilizing smart contracts and tokenization as a tool can allow for a simple means of management of these new assets, a cheaper operational cost, and a shared accounting tool that allows for engagement with anyone who also operates on the XDC network.
This asset smart contract provides a means for administrators to manage the contract by possessing a particular token called the handlerToken. The handler token is a token that acts as a key and allows the broker to create new assets with predefined sets of attributes.
When the handler deploys the contract the handler key is generated with a random integer not to interfere with the other asset tokens being generated, each token is paired to an integer.

 //initializer Execute some initial code as contract is launched
 constructor(string memory _URI) ERC1155(_URI) {
 handlerToken = uint(keccak256(abi.encodePacked(_URI)));
 _mint(msg.sender,handlerToken,1, "");
 }

Also, when launching the contract, you must set a Uniform Resource Identifier (URI). The URI is a set of metadata referenced by the user interface (UI) to allow data about the assets to be depicted on a screen. This typically includes attributes about the asset like images, the asset's origin broker, or even a name and description of the asset.
These attributes are typically hosted off-chain, but their links are referenced in the URI.

{
 "name": "{id}",
 "description": "https://hostedSite/description/{id}",
 "image": "https://hostedSite/{id}",
 "Broker": "QTrade" 
}

The administrator becomes the initial handlerToken holder as the contract is launched. This special token grants exclusive rights to certain contract functions.

//Store Asset details within contract 
 mapping(uint => Tokens) public tokens;
 struct Tokens{
 string name;
 string description;
 string image;
 string assetType;
 }
//This function allows you to add or create new tokens and log their data into the smart contract 
 function AddToken(string memory name, string memory att1, string memory att2 ,string memory att3,string memory assetType)public handler returns(bool){
 _mint(msg.sender,totalCoins,1, "");
 tokens[totalCoins] = Tokens(name,att1,att2,assetType);
 totalCoins++;
 return true;
 }

Once the contract is launched, the handler can call the AddToken function to create a new token to represent an asset. These tokens represent unique assets possessed by the broker with predefined attributes. The trust that these assets represent tangible means of ownership relies on the trust of the broker who issued them. Similar to how assets custodied on an app like Robin Hood are trusted due to Robin Hood being a trusted organization, if I were to create a clone of Robin Hood and sell assets that I do not currently possess, the user would not actually be buying the asset, and my sales would be fraudulent.
The firm can provide the token's name and attributes during the token creation process. In practice, these attributes can be anything about the asset that is important, like total supply, origin, expiration date (commodities/derivatives), or any other detail to describe the asset.

 //view token name and price of token to gauge what asset is corelated to the index nuber acociatyed with the asset
 function viewToken(uint Token)public view returns(string memory, string memory, string memory,string memory) {
 return (tokens[Token].name, tokens[Token].description, tokens[Token].image, tokens[Token].assetType);
 }

Users can view the name of a token and its attributes by calling the viewToken function.
The contract allows the handlerToken holder to move or destroy abandoned tokens to help recover lost or stolen assets.

 //if the broker for any reason need to move the asset from an abandond account
 //they can use the move Asset function 
    function moveAsset(uint _Token,address _userA,address _userB,uint _amount)public handler returns(bool){
        require(balanceOf(_userA, _Token) >= 1, "Insufficient balance");
        safeTransferFrom(_userA, _userB, _Token, _amount, "0x0");
        return true;
    }
 function destroyAsset(uint Token,address _userA)public returns(bool){
 require(balanceOf(_userA, Token) >= 1, "Insufficient balance");
 _burn(_userA, Token, 1);
 return true;
 }

In summary, this smart contract offers a convenient and secure way for finance firms and brokers to create and manage new assets on XDC. The handlerToken mechanism provides the necessary access control, allowing administrators to govern the contract while empowering brokers to create unique and valuable representations of their assets to be easily exchanged.

These Assets are accounting tools and as tools they are built to allow for a better more productive financial system.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.2 <0.9.0;
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
contract Asset is ERC1155 {
 uint public totalCoins = 0; //toal tokens
 uint public handlerToken; 
 
 //initializer Execute some initial code as contract is launched
 constructor(string memory _URI) ERC1155(_URI) {
 handlerToken = uint(keccak256(abi.encodePacked(_URI)));
 _mint(msg.sender,handlerToken,1, "");
 }
 //The Handler function allows the holder of the handler token to allows the owner of the contract create more assets 
 // As well as allows only the handler to redeem value from the contract
 modifier handler(){
 require(balanceOf(msg.sender,handlerToken) == 1, "user does not hold handlerToken");
 _;
 }
//Store Asset details within contract 
 mapping(uint => Tokens) public tokens;
 struct Tokens{
 string name;
 string description;
 string image;
 string assetType;
 }
//This function allows you to add or create new tokens and log their data into the smart contract 
 function AddToken(string memory name, string memory att1, string memory att2 ,string memory att3,string memory assetType)public handler returns(bool){
 _mint(msg.sender,totalCoins,1, "");
 tokens[totalCoins] = Tokens(name,att1,att2,assetType);
 totalCoins++;
 return true;
 }
//view token name and price of token to gauge what asset is corelated to the index nuber acociatyed with the asset
 function viewToken(uint Token)public view returns(string memory, string memory, string memory,string memory) {
 return (tokens[Token].name, tokens[Token].description, tokens[Token].image, tokens[Token].assetType);
 }
 //if the broker for any reason need to move the asset from an abandond account
 //they can use the move Asset function 
 function moveAsset(uint Token,address _userA,address _userB)public returns(bool){
 require(balanceOf(_userA, Token) >= 1, "Insufficient balance");
 _burn(_userA, Token, 1);
 _mint(_userB,Token,1, "");
 return true;
 }
 function destroyAsset(uint Token,address _userA)public returns(bool){
 require(balanceOf(_userA, Token) >= 1, "Insufficient balance");
 _burn(_userA, Token, 1);
 return true;
 }
}

*GitHub: * https://github.com/CoinClubQuincy/XDC-Automated-Asset-Management

Automating Agreements with the XDC network

Quincy Jones — Tue, 18 Jul 2023 19:19:57 +0000

I started a series of templates to help other developers with their projects. I created a basic contract that allows you to manage and represent an asset, such as a stock, commodity, or even debt. The contract can also programmatically manage the means of management of the asset and assign metadata to describe its attributes.

The contract's terms and conditions are embedded in the code and stored on the blockchain. Once deployed, the contract becomes immutable, meaning that its contents cannot be altered or tampered with. This immutability ensures that the agreed-upon terms cannot be changed without the consent of all parties involved. Additionally, the contract's transparency allows all parties to view and verify its content, eliminating the need for trust in a central authority.

The contract assigns a document hash to a variable, which represents the agreement between the parties. The document hash serves as a unique identifier for the agreement's content and can be used to verify its integrity. By comparing the document hash provided by any party to the stored document hash, the contract can determine whether the agreement has been modified or tampered with.

The contract enables parties to sign the agreement by interacting with the smart contract using their respective addresses. Once a party signs the contract, their address is recorded, indicating their consent and commitment to the agreement. This digital signature provides a non-repudiable proof of the party's involvement and prevents them from denying their participation later.

The contract includes functions for counterproposals, allowing either party to suggest modifications to the agreement by reassigning the document hash. This automation eliminates the need for manual communication and revision of physical documents. Furthermore, the contract keeps track of the total number of counterproposals, enabling parties to track the negotiation process accurately.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.2 <0.9.0;
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
//Smart contract
contract Contract is ERC1155 {
    uint256 public constant PartyA = 0;
    uint256 public constant PartyB = 1;

    uint256 public constant witnessA = 2;
    uint256 public constant witnessB = 3;

    string public DocumentHash = "";
    address PartyASignature;
    address PartyBSignature;
    uint public total_Counter_Proposals =0;

    bool public contractComplete = false;
    //Create 2 tokens for Party A-B
    constructor(string memory _DocumentHash, string memory _URI) ERC1155(_URI) {
        DocumentHash = _DocumentHash;
        _mint(msg.sender,PartyA,1, "");
        _mint(msg.sender,PartyB,1, "");
    }
    //only Party A-B can use functions with their modifier
    modifier PartyA_Sign {
        require(contractComplete == false, "contract has already been signed");
        require(balanceOf(msg.sender,PartyA) == 1);
        _;
    }
    modifier PartyB_Sign {
        require(contractComplete == false, "contract has already been signed");
        require(balanceOf(msg.sender,PartyB) == 1);
        _;
    }
    ///once both parties have sign you can no loger modify the contract
    modifier contractSigned {
        require(contractComplete == false,"Contract has been signed by both parties");
        require(PartyASignature == address(0) || PartyBSignature == address(0), "contract has been signed");
        _;
    }

    //this function will compare any data of hash to see if it matches the DocumentHash
    function verify(string memory _DocumentHash)public view returns(bool){
        if(keccak256(abi.encodePacked(_DocumentHash)) == keccak256(abi.encodePacked(DocumentHash)) ){
            return true;
        } else {
            return false;
        }
    }
    // Party A or party B can make a counter proposal and  reassign the hash
    function counter_proposal_A(string memory _DocumentHash)public  PartyA_Sign returns(bool){
        DocumentHash = _DocumentHash;
        total_Counter_Proposals++;
        return true;
    }
    function counter_proposal_B(string memory _DocumentHash)public PartyB_Sign returns(bool){
        DocumentHash = _DocumentHash;
        total_Counter_Proposals++;
        return true;
    }
    //Both parties can sign an make the contract official
    function sign_proposal()public contractSigned returns(bool,string memory){
        if(balanceOf(msg.sender,PartyA) == 1){
            PartyASignature = msg.sender;
            return (true, "Party A has signed Document");
        } else if(balanceOf(msg.sender,PartyB) ==1 ){
            PartyBSignature = msg.sender;
            return (true, "Party A has signed Document");
        }
        if(PartyASignature != address(0) && PartyBSignature != address(0) ){
            contractComplete = true;
            return (true, "only one party  has signed");
        }
        return (false, "error user does not hold token to authorize this call");
    }
}

The contract utilizes modifiers to control the execution of certain functions. For example, the PartyA_Sign and PartyB_Sign modifiers ensure that only Party A or Party B, respectively, can call the counter-proposal functions. The contractSigned modifier restricts further modifications to the agreement once both parties have signed, preventing any unauthorized changes.

These features provided by smart contracts on XDC offer increased efficiency, security, transparency, and automation to contractual agreements. They have the potential to revolutionize the way parties engage in business interactions, potentially reducing the need for intermediaries in certain scenarios.

GitHub: https://github.com/CoinClubQuincy/XDC-Automated-Asset-Management

The Coupled Relationship between Blockchain and AI and how it changes Big Data Analysis

Quincy Jones — Wed, 08 Mar 2023 22:10:33 +0000

The power of artificial intelligence (AI) has taken the tech industry by storm in recent months. Years of computer science modeling through machine learning and deep learning have provided the traction for what has become a wide range of AI use cases. Its capabilities are now evident in everyday use, whether giving instructions to a smart assistant like Siri or sitting behind the wheel of a self-driving car. And with supervised and reinforcement learning, conversant AI systems can handle an articulate back-and-forth discussion with a human. The trajectory of AI’s potential impact on our lives seems long and steep.

Blockchain technology provides a unique opportunity for big data to operate like never before. Previously, a subset of private data would have to be gathered over time until it became rich enough for its artificial intelligence (AI) to run insights.

Coinmarketcap recently published a very informative piece about the merging of blockchain and AI. Without getting too much into why AI and blockchain make so much sense together, the article outlines a dozen or so AI projects on blockchain, from generative NFTs to health and wellness applications. But why? Why does the overlap of blockchain and AI present so much promise in the long term? Let’s first discuss the basics of this powerful combination.

Through behavior pattern observations and learning, traditional AI systems analyze all sorts of operations, particularly for financial institutions and financial regulators. These tasks can range from fraud detection, to audits, to live market research, making way for predictive analytics.

Data to an AI is like a knife sharpener to a blade. The more data, the more accurate and precise the results are — similar to the more you sharpen a knife, the easier it is to cut. The difference is AI will have an infinitely sharpening blade that makes it more accurate over time.

As data on blockchain is much more accessible, sharpening this blade becomes a lot easier. On-chain applications generate more user data that AI systems can analyze almost instantaneously. Blockchain can not only extract rich data from smart contracts, it can also pull data from the relationship between one contract and another, or between contracts and users. This allows for data insight on behavioral patterns like we’ve never seen before.

For those worried about privacy, this will not be private identifying data. The data being analyzed will be similar to public market data provided by exchange and regulator agencies for transparency, the way public companies have reporting standards. The big difference is the on-chain aggregate data being reported will be public and automatically produced instantaneously.

When you couple AI with blockchain technology, there is just so much more data readily available. Blockchain and AI would allow financial regulators to conduct live audits and fraud detection. Decentralized applications on a given blockchain network can maintain a close relationship with AI to root out bot users, analyze user activity, generate complex user stats, and conduct in-depth evaluations of third party application activity.

Data is power. As more applications come onto blockchain networks, their activity and growth can be monitored in new, unprecedented ways. It can be analyzed in real time for insights into new companies, allowing for creation of better growth models or increased profitability.

Real time monitoring of an economy, afforded uniquely by blockchain and AI, can provide insight into macroeconomic systems that is simply not possible through other means. Economic growth in an entire industry could be tracked live, allowing economists and lawmakers to craft relevent policy or detect widespread impropriety. Government subsidies could be doled out while AI monitors for fraudulent activity.

There are over 100 projects on blockchain - or in the pipeline - that incorporate AI. Some of these use - or plan to use - AI as a predictor much like traditional AI platforms. These capabilities range from spot stock trading and hedge funds, to disease prevention and diagnosis. Others are simply expanding AI capabilities in a very general sense, and bringing them on blockchain. But down the line, as more data goes on chain, we will see even more exciting, real-time, extremely practical use cases like what I outlined above. These AI capabilities will only be possible on blockchain networks.

When coupled with the distributed ledger of a blockchain network, the possibilities of AI are nearly limitless. And as no one party has a monopoly on subsets of data, not only will the intelligence be richer, but the AI capacities themselves can grow by leaps and bounds through open source innovation. It’s almost impossible to predict exactly what is in the promising future of blockchain plus AI, but I can’t wait to see what it brings.

Creating an index of all Layer 2s on the XDC Network

Quincy Jones — Thu, 22 Dec 2022 20:25:09 +0000

Currently for the past few days I've been putting together a list of Layer 2s on the XDC Network to index all current DApps and there contract addresses,github,documentation, and website to allow developers a simple means of finding information on XDC layer 2 projects to allow new devs to build smart contracts with features embed from current projects allowing:

more use and adoption of current Layer 2s

2.makes it easier to create new dApps with more functionality (like using a DEX,NFT market place, or oracle) can now leverage current L2s to bring more services to their projects.

Currently Ive taken note of the bigger ones (Globiance, XSwap, Plugin, StoreX) as well as some others to list on the XDC Community Website to allow for Users, Investors and Developers to have a one step shop for XDC layer 2s

The basic require meant to be included in the index are:

a valid Website with a secure (HTTPS) domain name
Github repo with any public open source code
The Contract Address
The contract Must be Verified on Blocksscan

As more applications come on to the network we will continuously be adding to the index to continually updating the website to allow for people to find all available info on current Layer 2s

once a good draft of Layer 2s have been put together you will be able to see them on the XDC Community website to find all the info you need on your favorite L2s on XDC.

all suggestions welcomed, Thank you!

NFT Keys to Manage Multi-Sig Wallets

Quincy Jones — Thu, 03 Nov 2022 20:51:49 +0000

Most people are familiar with the aesthetic functions of non-fungible tokens (NFTs), but their capabilities actually include functionality that goes far beyond anything visual. Those who understand that NFTs can have real utility usually think of tickets or supply chain tools. But an NFT can also act as a key.

In the world of crypto, having multiple signatures required for wallet access allows for further security and further redundancy as well as a decentralized mechanism for giving multiple parties custody of assets in a wallet.

In addition, using a key to cast a signature on a multi-signature wallet allows users to easily move the access key to other devices. Users can even delegate their key to another smart contract for further functionality. Contract keys may be a popular contract design in the future due to their ability to hold NFTs as an access mechanism to the contract. As contracts become increasingly sophisticated, access keys may manage access rights for all users and contracts that use them, and can allow further automation when used within other smart contracts.

In this Multisig Key contract, I added in a few additional functions. Instead of tying each account to an address, I tied it to a token. This allows for users to use an NFT as a key to sign a proposed transaction. In theory, the NFT can act as a ballot to propose and vote on proposals proposed within the contract by any of the key holders. This means a multisig contract can be used to propose and vote on principal items by the key holders as well as act as a standing treasury for assets to be decentrally held in custody and voted on to be reallocated to other addresses.

The Multisig Key contract can primarily act as a decentralized trust, a dApp, DAO, escrow, or even a secondary wallet for someone who wants to have multiple protective measures to safeguard their assets. With any of these use cases, users can have a form of governance and community control over a given smart contract. In fact, they can make community-driven decisions by having each user hold a key which they use to vote. Additional means of governance can be programmed into the smart contract using the signer key tokens as governance tokens for any additional function created.

dApps and DAOs can also use this contract as a library for basic governance amongst a given set of users. Keys can be used to manage assets and votes within their applications, greatly increasing functionality of a dApp with little effort. As further libraries are built out, future dApps and DAOs will be able to gain greater functionality for less.

when engaging with the contract there are many different Settings (proposals, confirmation to a proposal, type of proposal) so all input parameters are an array with a syntax in accordance to the Setting

submitProposal() Parameters

function submitProposal(uint  _ammount, address [] memory  _address,string  memory  _topic,string  memory  _messege) public CheckKeys returns(bool)

uint: [Amount,tokenID]
address: [0: toAddress, 1: XRC_Type, 2: NFT_id] (token based parameters)
String: [Topic,Message, FunctionExecution() ]

#int [] Based Parameters

governance Vote

[NA]

XDC & XRC20 transactions

[amount,N/A]

XRC721&1155 Transactions:

[1,tokenNumber]

#address [] Based Parameters

Note: 0x0000000000000000000000000000000000000000 is used as a 0 place hoder

Governance Vote:
A blank vote where token holders can vote on a topic (no execution is made other than showing the result of a majority vote)

0: (address) 0x0000000000000000000000000000000000000000 (Required!)
1: (address) 0x0000000000000000000000000000000000000000 (Required!)

XDC Transactions:
A simple transaction sending XDC to another address upon a completed vote

0:(address) toAddress
1: N/A

XRC20 Transactions:
A simple transaction sending XRC20 tokens to another address upon a completed vote

0: (address) toAddress
1: (address) XRC contract address

XRC721&1155 Transactions:
A simple transaction sending a XRC721 or XRC1155 tokens to another address upon a completed vote

0: (address) toAddress
- 1: (address) XRC contract address

#String [] Based Parameters

Topic & Message
Topic and message of transaction or vote describing the

["Topic name" , "message",""] : XDC transaction without function excution or blank transaction
["Topic name" , "message","XRC20"] : XRC20 transaction or blank transaction
["Topic name" , "message","XRC20"] : NFT transaction or blank transaction

FunctionExecution() [Not completed]

Function Execution can only be made with an XDC transaction and execute another contracts external functions (only one execution at a time!)
so a multi executing function would require to be done in a separately created contract where the Treasury would execute to automate multiple executions

["Topic name" , "message", FunctionExecution()]

Github:https://github.com/CoinClubQuincy/Multi-Sig-Treasury

Unable to Sync Testnet Nodes

Quincy Jones — Fri, 14 Oct 2022 21:24:44 +0000

For the past few weeks I've been getting quite familiar with deploying and managing private XDC test networks and i came into a little snag once having them deployed i couldn't get them to sync. Either I'm stuck on block 0 or when I do have have some short term successes i maintain having consensus for about 500 blocks or so but then the nodes go into a pending state and get stuck on that block

I made an Issue is the xdc-testnetwork-leo Github Repo addressing my struggles following the documentation to deploy the test network

Ive been deploying the testnets and trying to get them synced for a weeks now my primary issue seems to be the nodes are able to peer and for a time will make consensus but after 500 blocks or so the network gets stalled and won't proceed to make consensus any more.

I don't get any errors except for the logs stating its not their turn to publish a block, or permission denied or failed to create the protocol stack I'm not sure what is causing this to be the case but its keeping my nodes from gaining consensus. even with the error I can see the nodes are online but not sure what the consensus issue may be of what may be flagging any of the issues listed above.

While following the Documentation most of the documentation has been pretty straight forward the 2 parts that were difficult to reconcile was making sure the encodeIDs and IPs are associated to every node so the boot nodes can see and launch off each other and ensuring firewall/ Security group ports are Identified so the nodes can have a clear read of each others ports the main ones being 8545-8547 for the RPC and 30303-30307 for peering

The main issue is syncing and consensus for moving forward with progress to the next block with a Master node and 2 other full nodes (3 nodes total)

What gives a network initial consensus? the boot nodes seem to be the initial connectors and they are able to see each other but what gives it consensus when they can see each other?

ubuntu@ip-172-31-93-57:~/xdc-testnetwork-leo$ bash run.sh 
touch: cannot touch '.pwd': Permission denied
make: go: No such file or directory
go run build/ci.go install ./cmd/XDC
make: go: No such file or directory
make: *** [Makefile:14: XDC] Error 127
INFO [10-14|17:43:30] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/1: permission denied
INFO [10-14|17:43:30] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/2: permission denied
INFO [10-14|17:43:30] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/3: permission denied
INFO [10-14|17:43:30] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/1: permission denied
INFO [10-14|17:43:30] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/2: permission denied
INFO [10-14|17:43:31] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/3: permission denied
Starting the bootnode ...
Starting the nodes ...
Fatal: -ListenUDP: listen udp 0.0.0.0:30301: bind: address already in use
INFO [10-14|17:43:31] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/1: permission denied
INFO [10-14|17:43:31] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/2: permission denied
INFO [10-14|17:43:31] Maximum peer count                       ETH=25 LES=0 total=25
Fatal: Failed to create the protocol stack: mkdir /home/ubuntu/xdc-testnetwork-leo/nodes/3: permission denied
ubuntu@ip-172-31-93-57:~/xdc-testnetwork-leo$ sudo bash run.sh 
make: go: No such file or directory
go run build/ci.go install ./cmd/XDC
make: go: No such file or directory
make: *** [Makefile:14: XDC] Error 127
INFO [10-14|17:43:38] Maximum peer count                       ETH=25 LES=0 total=25
INFO [10-14|17:43:38] XDCX datadir                             path=/root/.XDC
INFO [10-14|17:43:38] Maximum peer count                       ETH=25 LES=0 total=25
INFO [10-14|17:43:38] XDCX datadir                             path=/root/.XDC
INFO [10-14|17:43:38] Maximum peer count                       ETH=25 LES=0 total=25
INFO [10-14|17:43:38] XDCX datadir                             path=/root/.XDC
Starting the bootnode ...
Starting the nodes ...
Fatal: -ListenUDP: listen udp 0.0.0.0:30301: bind: address already in use
INFO [10-14|17:43:39] Maximum peer count                       ETH=25 LES=0 total=25
INFO [10-14|17:43:39] XDCX datadir                             path=/root/.XDC
INFO [10-14|17:43:39] Allocated cache and file handles         database=/root/.XDC cache=134.22mB handles=1024
INFO [10-14|17:43:39] Maximum peer count                       ETH=25 LES=0 total=25
INFO [10-14|17:43:39] XDCX datadir                             path=/root/.XDC
INFO [10-14|17:43:39] Allocated cache and file handles         database=/root/.XDC cache=134.22mB handles=1024
ERROR[10-14|17:43:39] Can't create new DB                      error="resource temporarily unavailable"
INFO [10-14|17:43:39] Starting peer-to-peer node               instance=XDC/v1.4.4-stable/linux-amd64/go1.15
INFO [10-14|17:43:39] Allocated cache and file handles         database=/home/ubuntu/xdc-testnetwork-leo/nodes/2/XDC/chaindata cache=805.31mB handles=512
INFO [10-14|17:43:39] Maximum peer count                       ETH=25 LES=0 total=25
INFO [10-14|17:43:39] XDCX datadir                             path=/root/.XDC
INFO [10-14|17:43:39] Allocated cache and file handles         database=/root/.XDC cache=134.22mB handles=1024
ERROR[10-14|17:43:39] Can't create new DB                      error="resource temporarily unavailable"
INFO [10-14|17:43:39] Starting peer-to-peer node               instance=XDC/v1.4.4-stable/linux-amd64/go1.15
INFO [10-14|17:43:39] Allocated cache and file handles         database=/home/ubuntu/xdc-testnetwork-leo/nodes/3/XDC/chaindata cache=805.31mB handles=512
INFO [10-14|17:43:39] Starting peer-to-peer node               instance=XDC/v1.4.4-stable/linux-amd64/go1.15
INFO [10-14|17:43:39] Allocated cache and file handles         database=/home/ubuntu/xdc-testnetwork-leo/nodes/1/XDC/chaindata cache=805.31mB handles=512
INFO [10-14|17:43:39] Initialised chain configuration          config="{ChainID: 72 Homestead: 1 DAO: <nil> DAOSupport: false EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 4 Constantinople: <nil> Engine: XDPoS}"
INFO [10-14|17:43:39] Initialising Ethereum protocol           versions="[63 62]" network=72
INFO [10-14|17:43:39] Loaded most recent local header          number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Loaded most recent local full block      number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Loaded most recent local fast block      number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Initialised chain configuration          config="{ChainID: 72 Homestead: 1 DAO: <nil> DAOSupport: false EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 4 Constantinople: <nil> Engine: XDPoS}"
INFO [10-14|17:43:39] Initialising Ethereum protocol           versions="[63 62]" network=72
INFO [10-14|17:43:39] Loaded most recent local header          number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Initialised chain configuration          config="{ChainID: 72 Homestead: 1 DAO: <nil> DAOSupport: false EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 4 Constantinople: <nil> Engine: XDPoS}"
INFO [10-14|17:43:39] Loaded most recent local full block      number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Initialising Ethereum protocol           versions="[63 62]" network=72
INFO [10-14|17:43:39] Loaded most recent local fast block      number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Loaded local transaction journal         transactions=0 dropped=0
INFO [10-14|17:43:39] Loaded most recent local header          number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Loaded most recent local full block      number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Regenerated local transaction journal    transactions=0 accounts=0
INFO [10-14|17:43:39] Loaded most recent local fast block      number=0 hash=8997ba…315e17 td=1
INFO [10-14|17:43:39] Starting P2P networking 
INFO [10-14|17:43:39] Loaded local transaction journal         transactions=0 dropped=0
INFO [10-14|17:43:39] Regenerated local transaction journal    transactions=0 accounts=0
INFO [10-14|17:43:39] Starting P2P networking 
INFO [10-14|17:43:39] Loaded local transaction journal         transactions=1 dropped=0
INFO [10-14|17:43:39] Regenerated local transaction journal    transactions=1 accounts=1
INFO [10-14|17:43:39] Starting P2P networking 
INFO [10-14|17:43:41] UDP listener up                          self=enode://3a80d2dde89c9fdca3f7d28f49bcac1266f5f78095418971c1feff8c38b1809b51a91b793fc4b1d2a9731e7671c619a490cd9c202efa122a4f7b98307e341902@[::]:30305
INFO [10-14|17:43:41] UDP listener up                          self=enode://5661081332f458bd512daa76c149042c00f78f045aba4494cc64fcfaf7517638025b979d0fe11c7a420447f76d24ddd438da6253027820ed95eade4fcdeaf4b6@[::]:30303
INFO [10-14|17:43:41] HTTP endpoint opened                     url=http://0.0.0.0:8545 cors=* vhosts=*
INFO [10-14|17:43:41] WebSocket endpoint opened                url=ws://[::]:8555
INFO [10-14|17:43:41] UDP listener up                          self=enode://6a67c3175b994311c8e4408b671471ef166d3d3d828d432233f349c395907f9a843b18d5e6ccab1c278778193c452dcfefc83d431678078d41d7140bcef3860b@[::]:30304
INFO [10-14|17:43:41] HTTP endpoint opened                     url=http://0.0.0.0:8547 cors=* vhosts=*
INFO [10-14|17:43:41] WebSocket endpoint opened                url=ws://[::]:8557
INFO [10-14|17:43:41] RLPx listener up                         self=enode://6a67c3175b994311c8e4408b671471ef166d3d3d828d432233f349c395907f9a843b18d5e6ccab1c278778193c452dcfefc83d431678078d41d7140bcef3860b@[::]:30304
INFO [10-14|17:43:41] IPC endpoint opened                      url=/home/ubuntu/xdc-testnetwork-leo/nodes/1/XDC.ipc
INFO [10-14|17:43:41] RLPx listener up                         self=enode://5661081332f458bd512daa76c149042c00f78f045aba4494cc64fcfaf7517638025b979d0fe11c7a420447f76d24ddd438da6253027820ed95eade4fcdeaf4b6@[::]:30303
INFO [10-14|17:43:41] IPC endpoint opened                      url=/home/ubuntu/xdc-testnetwork-leo/nodes/2/XDC.ipc
INFO [10-14|17:43:41] HTTP endpoint opened                     url=http://0.0.0.0:8546                              cors=* vhosts=*
INFO [10-14|17:43:41] RLPx listener up                         self=enode://3a80d2dde89c9fdca3f7d28f49bcac1266f5f78095418971c1feff8c38b1809b51a91b793fc4b1d2a9731e7671c619a490cd9c202efa122a4f7b98307e341902@[::]:30305
INFO [10-14|17:43:41] IPC endpoint opened                      url=/home/ubuntu/xdc-testnetwork-leo/nodes/3/XDC.ipc
INFO [10-14|17:43:41] WebSocket endpoint opened                url=ws://[::]:8556
INFO [10-14|17:43:42] Unlocked account                         address=xdc4e7D2c63d5afd93058fC7a827745a17339EdCcFF
INFO [10-14|17:43:42] Etherbase automatically configured       address=xdc4e7D2c63d5afd93058fC7a827745a17339EdCcFF
INFO [10-14|17:43:42] Unlocked account                         address=xdcb96016369693812449D6F08e64275d5D639258D1
INFO [10-14|17:43:42] Etherbase automatically configured       address=xdcb96016369693812449D6F08e64275d5D639258D1
INFO [10-14|17:43:42] Unlocked account                         address=xdc78e5c3bBBcD34a1cffdbEe9b6670e59763709bC4
INFO [10-14|17:43:42] Etherbase automatically configured       address=xdc78e5c3bBBcD34a1cffdbEe9b6670e59763709bC4

This shows that the nodes are peering but for some reason they won't make consensus I have a transaction pending but no consensus is made

> txpool
{
  content: {
    pending: {
      xdc9EC5998c873A295b01491375B092E0BCF5B0B4e8: {
        0: {...}
      }
    },
    queued: {}
  },
  inspect: {
    pending: {
      xdc9EC5998c873A295b01491375B092E0BCF5B0B4e8: {
        0: "xdcB22fe441774c143D3CeF39d739b9B062C087a9ae: 100000000000000000000 wei + 21000 gas × 1000000000 wei"
      }
    },
    queued: {}
  },
  status: {
    pending: 1,
    queued: 0
  },
  getContent: function(callback),
  getInspect: function(callback),
  getStatus: function(callback)
}

> eth.blockNumber
0
> net.peerCount
2
> admin.peers
[{
    caps: ["eth/62", "eth/63"],
    id: "3a80d2dde89c9fdca3f7d28f49bcac1266f5f78095418971c1feff8c38b1809b51a91b793fc4b1d2a9731e7671c619a490cd9c202efa122a4f7b98307e341902",
    name: "XDC/v1.4.4-stable/linux-amd64/go1.15",
    network: {
      inbound: false,
      localAddress: "172.31.93.57:42776",
      remoteAddress: "18.212.67.27:30305",
      static: false,
      trusted: false
    },
    protocols: {
      eth: {
        difficulty: 1,
        head: "0x8997bae00839d39d4dbc3f6fa3a209fa56f7ce8c558ef71eaf6b56cb31315e17",
        version: 63
      }
    }
}, {
    caps: ["eth/62", "eth/63"],
    id: "6a67c3175b994311c8e4408b671471ef166d3d3d828d432233f349c395907f9a843b18d5e6ccab1c278778193c452dcfefc83d431678078d41d7140bcef3860b",
    name: "XDC/v1.4.4-stable/linux-amd64/go1.15",
    network: {
      inbound: false,
      localAddress: "172.31.93.57:41228",
      remoteAddress: "18.212.67.27:30304",
      static: false,
      trusted: false
    },
    protocols: {
      eth: {
        difficulty: 1,
        head: "0x8997bae00839d39d4dbc3f6fa3a209fa56f7ce8c558ef71eaf6b56cb31315e17",
        version: 63
      }
    }
}]
> eth.coinbase
"xdcb96016369693812449d6f08e64275d5d639258d1"
> admin.nodeInfo.enode
"enode://5661081332f458bd512daa76c149042c00f78f045aba4494cc64fcfaf7517638025b979d0fe11c7a420447f76d24ddd438da6253027820ed95eade4fcdeaf4b6@[::]:30303"

Ive tried running all the nodes collectively on one server with the run.sh script @anilchinchawale recommended from the XDPoSChain deployment script I've been able to have the nodes peer each other any sync for a short period of time. Ive also tried running the nodes on separate servers but I can get them to peer so I've been focusing on the single server node deployment strategy

run.sh from XDPoSChain
`

#!/bin/bash
_interupt() { 
    echo "Shutdown $child_proc"
    kill -TERM $child_proc
    exit
}

trap _interupt INT TERM

touch .pwd
export $(cat .env | xargs)
Bin_NAME=XDC

WORK_DIR=$PWD
PROJECT_DIR="/root/XinFin/XDPoSChain"
cd $PROJECT_DIR && make XDC
cd $WORK_DIR

if [ ! -d ./nodes/1/$Bin_NAME/chaindata ]
then
  wallet1=$(${PROJECT_DIR}/build/bin/$Bin_NAME account import --password .pwd --datadir ./nodes/1 <(echo ${PRIVATE_KEY_1}) | awk -v FS="({|})" '{print $2}')
  wallet2=$(${PROJECT_DIR}/build/bin/$Bin_NAME account import --password .pwd --datadir ./nodes/2 <(echo ${PRIVATE_KEY_2}) | awk -v FS="({|})" '{print $2}')
  wallet3=$(${PROJECT_DIR}/build/bin/$Bin_NAME account import --password .pwd --datadir ./nodes/3 <(echo ${PRIVATE_KEY_3}) | awk -v FS="({|})" '{print $2}')
  ${PROJECT_DIR}/build/bin/$Bin_NAME --datadir ./nodes/1 init ./genesis/genesis.json
  ${PROJECT_DIR}/build/bin/$Bin_NAME --datadir ./nodes/2 init ./genesis/genesis.json
  ${PROJECT_DIR}/build/bin/$Bin_NAME --datadir ./nodes/3 init ./genesis/genesis.json
else
  wallet1=$(${PROJECT_DIR}/build/bin/$Bin_NAME account list --datadir ./nodes/1 | head -n 1 | awk -v FS="({|})" '{print $2}')
  wallet2=$(${PROJECT_DIR}/build/bin/$Bin_NAME account list --datadir ./nodes/2 | head -n 1 | awk -v FS="({|})" '{print $2}')
  wallet3=$(${PROJECT_DIR}/build/bin/$Bin_NAME account list --datadir ./nodes/3 | head -n 1 | awk -v FS="({|})" '{print $2}')
fi

VERBOSITY=3
GASPRICE="1"
networkid=50


echo Starting the bootnode ...
${PROJECT_DIR}/build/bin/bootnode -nodekey ./bootnode.key --addr 0.0.0.0:30301 &
child_proc=$! 

echo Starting the nodes ...
${PROJECT_DIR}/build/bin/$Bin_NAME --bootnodes "enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@78.129.229.96:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@5.152.223.199:30301,enode://d757f1a21828c9c426e26df39176053302209e3dd05e7a6c0e0eae57739e233c0fa970c9b98e010cee4817e6233c3ad3eef461cef3e731c485ed4bc08de7d0ac@37.58.56.228:30303,enode://d757f1a21828c9c426e26df39176053302209e3dd05e7a6c0e0eae57739e233c0fa970c9b98e010cee4817e6233c3ad3eef461cef3e731c485ed4bc08de7d0ac@37.58.56.228:30304,enode://ef4d512152b875de3fc3990e3e124ae55adea35c49c5df40d0c4bea9327116fcfba70b920a7c164e08f425876025cbcf2519ad5238e57c10ea205e7897926a35@45.76.113.250:30303,enode://bcda483330dc0845f521ad611bcdc8cb147a7a8008c022dba20da2ab52ae46fd6d04f3cb9b7da4e94cf81d2c61065e008a13b5f05f3b69795b0dbdd2a14bb48d@209.222.30.63:30303,enode://2edc16258f6f2e18b105362df5af89889b5dbb7b098f266c39ba1b6200e9dfa76b8fd3bc0cdefce089d9e285772ae69d549e6807b23341ac975d0c085b936f1b@139.180.131.100:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@149.28.135.114:30303,enode://5fcb6aa25e9e4184f278f842581507e4180851e861a59e1a02cf62f2927ee073ba921b5cba10301043f41ed494860f0ccc7508f1058c25f8ebcd56e9f8da018b@149.28.140.203:30303,enode://3a792327abf09be1b78db697c33de653d21bb702eaf6e292899c31a59f0b9535753a34d41f088416bc3f90d25c35ecd6b79d0015c36cf10f9a27c89ecd1f7fa4@149.28.140.232:30303,enode://26def7887241597a30314a77b1a32f156bdcc92eee198b086ae7c4dc26b986a9be6d078b09e93a1f963b083885020e1edfbf6b053dcebbdd090f6dfb289b59f0@149.28.142.223:30303,enode://f35e4ff8bfca2b37297dae0524146c2e4ef20c5d95be48cabe0072334bcf77a9385bad27b9630ee5ba4de451076c2123ad06113f21e3f78387a0e6fde7ec1b0b@45.77.183.160:30303,enode://44f8256e0285d1a94a73187116772522dcf53ef3affcac171cf01ffb00ec613ba1960f1309cc9353207a8f1211e645016c6e30b9669190aac8386c78545b84b1@198.13.34.190:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@139.180.218.68:30303,enode://5701cfd1d03a04a3a17076e50983397ff634ff7f00693f62f6d4d94107796b74b8e10b8ad6efbf1499ae0c6263e84594d30986c79242a37b1c9d27cddb57cdc5@207.148.71.42:30303,enode://b0bd514f1b0892ab26c1d8be59510406f7d700c74cd3cd03d3f8d0fc21b784bb2fb7bde3afacf435928ca9506decf73bd15af5a64bd5dd113b26fc91605ce397@45.77.181.79:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@139.180.135.153:30303,enode://297167bcccf50a94fd2b9a1f1a372228526a95066030295ee8842e0bcaf798da751974a8b08caa9fb9764d2b2d50e64ec5a90a8b942a2a9d6b1db9d5995de3ff@139.180.143.152:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@45.77.244.187:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@45.76.153.161:30303,enode://3a914391c6f6ff0af000b5e614df1074c2a2db2575d6c4d02c3d96bc00ed52ba4281df45b065cbc253c2a02d0bc34272520e772ee9880b28ef107e91b86166d8@109.169.55.28:30303,enode://2953c5ea2a2829a242123e14538b137be858602da1e68beb8c7f7ec797d9d42cf4f0c76b62e98c4d5578e0eeefa42a501fdfec7079e8db206d89d037a09cde3a@109.169.55.28:30304,enode://80dee88ded07fcb0ed1f4a9db4c60c0bd0592d44656571822b479047653b0c30d84e68c83057db048d2120cd7d504fd6a70a89161c31aaf98e65cfba4a77a528@109.169.55.28:30305,enode://7e495d7e1be1fc47d62f8510249435fb3b6f279880704896cbd78e05027298ed133979a388cc0ecf51fb014a8c68438b45e4a2d82ab1ed9cf86a31e87fed32c5@78.129.229.96:30303,enode://02c155fe4b34293b50d70a10889a57d9f2434fefdf142c6d24d73df9ccff19994cb243b55e87a9349a8f87d827363f74b0b40f44d96925aaaedadb456e38c0c0@78.129.229.96:30304,enode://bc2a722d080b008132ef395763d87f491fb6adc34b5d34b698cfeeadced2d4468ee5dc09f39956b4686c88af9bf26e39bc050feb52c0976238645a0343e6049f@78.129.229.96:30305,enode://560113969268e30a430991e36fcb1a6ea8a2bc16f23bc1dabffd6f8c17649237d58d8cf554e9ce882184abdc9b3a607230123e2bcf819d4ed01ec02acee1c4c2@78.159.100.155:30303,enode://a86d3268c060323572bfeb6df76081e4668ec44cc60ff028c1685a9a683c5d6497c987b5dfade81323d08875066218a1877484396e11f400ce1c2c9bd343c935@78.159.100.155:30304,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@127.0.0.1:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@78.129.229.96:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@5.152.223.199:30301" --syncmode "full" --datadir ./nodes/1 --networkid "${networkid}" --port 30303 --rpc --rpccorsdomain "*" --ws --wsaddr="0.0.0.0" --wsorigins "*" --wsport 8555 --rpcaddr 0.0.0.0 --rpcport 8545 --rpcvhosts "*" --unlock "${wallet1}" --password ./.pwd --mine --gasprice "${GASPRICE}" --targetgaslimit "420000000" --verbosity ${VERBOSITY} --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,XDPoS --ethstats "XinFin-MasterNode-01:xinfin_xdpos_hybrid_network_stats@stats.xinfin.network:3000" &
child_proc="$child_proc $!"
${PROJECT_DIR}/build/bin/$Bin_NAME --bootnodes "enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@78.129.229.96:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@5.152.223.199:30301,enode://d757f1a21828c9c426e26df39176053302209e3dd05e7a6c0e0eae57739e233c0fa970c9b98e010cee4817e6233c3ad3eef461cef3e731c485ed4bc08de7d0ac@37.58.56.228:30303,enode://d757f1a21828c9c426e26df39176053302209e3dd05e7a6c0e0eae57739e233c0fa970c9b98e010cee4817e6233c3ad3eef461cef3e731c485ed4bc08de7d0ac@37.58.56.228:30304,enode://ef4d512152b875de3fc3990e3e124ae55adea35c49c5df40d0c4bea9327116fcfba70b920a7c164e08f425876025cbcf2519ad5238e57c10ea205e7897926a35@45.76.113.250:30303,enode://bcda483330dc0845f521ad611bcdc8cb147a7a8008c022dba20da2ab52ae46fd6d04f3cb9b7da4e94cf81d2c61065e008a13b5f05f3b69795b0dbdd2a14bb48d@209.222.30.63:30303,enode://2edc16258f6f2e18b105362df5af89889b5dbb7b098f266c39ba1b6200e9dfa76b8fd3bc0cdefce089d9e285772ae69d549e6807b23341ac975d0c085b936f1b@139.180.131.100:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@149.28.135.114:30303,enode://5fcb6aa25e9e4184f278f842581507e4180851e861a59e1a02cf62f2927ee073ba921b5cba10301043f41ed494860f0ccc7508f1058c25f8ebcd56e9f8da018b@149.28.140.203:30303,enode://3a792327abf09be1b78db697c33de653d21bb702eaf6e292899c31a59f0b9535753a34d41f088416bc3f90d25c35ecd6b79d0015c36cf10f9a27c89ecd1f7fa4@149.28.140.232:30303,enode://26def7887241597a30314a77b1a32f156bdcc92eee198b086ae7c4dc26b986a9be6d078b09e93a1f963b083885020e1edfbf6b053dcebbdd090f6dfb289b59f0@149.28.142.223:30303,enode://f35e4ff8bfca2b37297dae0524146c2e4ef20c5d95be48cabe0072334bcf77a9385bad27b9630ee5ba4de451076c2123ad06113f21e3f78387a0e6fde7ec1b0b@45.77.183.160:30303,enode://44f8256e0285d1a94a73187116772522dcf53ef3affcac171cf01ffb00ec613ba1960f1309cc9353207a8f1211e645016c6e30b9669190aac8386c78545b84b1@198.13.34.190:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@139.180.218.68:30303,enode://5701cfd1d03a04a3a17076e50983397ff634ff7f00693f62f6d4d94107796b74b8e10b8ad6efbf1499ae0c6263e84594d30986c79242a37b1c9d27cddb57cdc5@207.148.71.42:30303,enode://b0bd514f1b0892ab26c1d8be59510406f7d700c74cd3cd03d3f8d0fc21b784bb2fb7bde3afacf435928ca9506decf73bd15af5a64bd5dd113b26fc91605ce397@45.77.181.79:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@139.180.135.153:30303,enode://297167bcccf50a94fd2b9a1f1a372228526a95066030295ee8842e0bcaf798da751974a8b08caa9fb9764d2b2d50e64ec5a90a8b942a2a9d6b1db9d5995de3ff@139.180.143.152:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@45.77.244.187:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@45.76.153.161:30303,enode://3a914391c6f6ff0af000b5e614df1074c2a2db2575d6c4d02c3d96bc00ed52ba4281df45b065cbc253c2a02d0bc34272520e772ee9880b28ef107e91b86166d8@109.169.55.28:30303,enode://2953c5ea2a2829a242123e14538b137be858602da1e68beb8c7f7ec797d9d42cf4f0c76b62e98c4d5578e0eeefa42a501fdfec7079e8db206d89d037a09cde3a@109.169.55.28:30304,enode://80dee88ded07fcb0ed1f4a9db4c60c0bd0592d44656571822b479047653b0c30d84e68c83057db048d2120cd7d504fd6a70a89161c31aaf98e65cfba4a77a528@109.169.55.28:30305,enode://7e495d7e1be1fc47d62f8510249435fb3b6f279880704896cbd78e05027298ed133979a388cc0ecf51fb014a8c68438b45e4a2d82ab1ed9cf86a31e87fed32c5@78.129.229.96:30303,enode://02c155fe4b34293b50d70a10889a57d9f2434fefdf142c6d24d73df9ccff19994cb243b55e87a9349a8f87d827363f74b0b40f44d96925aaaedadb456e38c0c0@78.129.229.96:30304,enode://bc2a722d080b008132ef395763d87f491fb6adc34b5d34b698cfeeadced2d4468ee5dc09f39956b4686c88af9bf26e39bc050feb52c0976238645a0343e6049f@78.129.229.96:30305,enode://560113969268e30a430991e36fcb1a6ea8a2bc16f23bc1dabffd6f8c17649237d58d8cf554e9ce882184abdc9b3a607230123e2bcf819d4ed01ec02acee1c4c2@78.159.100.155:30303,enode://a86d3268c060323572bfeb6df76081e4668ec44cc60ff028c1685a9a683c5d6497c987b5dfade81323d08875066218a1877484396e11f400ce1c2c9bd343c935@78.159.100.155:30304,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@127.0.0.1:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@78.129.229.96:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@5.152.223.199:30301" --syncmode "full" --datadir ./nodes/2 --networkid "${networkid}" --port 30304 --rpc --rpccorsdomain "*" --ws --wsaddr="0.0.0.0" --wsorigins "*" --wsport 8556 --rpcaddr 0.0.0.0 --rpcport 8546 --rpcvhosts "*" --unlock "${wallet2}" --password ./.pwd --mine --gasprice "${GASPRICE}" --targetgaslimit "420000000" --verbosity ${VERBOSITY} --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,XDPoS --ethstats "XinFin-MasterNode-02:xinfin_xdpos_hybrid_network_stats@stats.xinfin.network:3000" &
child_proc="$child_proc $!"
${PROJECT_DIR}/build/bin/$Bin_NAME --bootnodes "enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@78.129.229.96:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@5.152.223.199:30301,enode://d757f1a21828c9c426e26df39176053302209e3dd05e7a6c0e0eae57739e233c0fa970c9b98e010cee4817e6233c3ad3eef461cef3e731c485ed4bc08de7d0ac@37.58.56.228:30303,enode://d757f1a21828c9c426e26df39176053302209e3dd05e7a6c0e0eae57739e233c0fa970c9b98e010cee4817e6233c3ad3eef461cef3e731c485ed4bc08de7d0ac@37.58.56.228:30304,enode://ef4d512152b875de3fc3990e3e124ae55adea35c49c5df40d0c4bea9327116fcfba70b920a7c164e08f425876025cbcf2519ad5238e57c10ea205e7897926a35@45.76.113.250:30303,enode://bcda483330dc0845f521ad611bcdc8cb147a7a8008c022dba20da2ab52ae46fd6d04f3cb9b7da4e94cf81d2c61065e008a13b5f05f3b69795b0dbdd2a14bb48d@209.222.30.63:30303,enode://2edc16258f6f2e18b105362df5af89889b5dbb7b098f266c39ba1b6200e9dfa76b8fd3bc0cdefce089d9e285772ae69d549e6807b23341ac975d0c085b936f1b@139.180.131.100:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@149.28.135.114:30303,enode://5fcb6aa25e9e4184f278f842581507e4180851e861a59e1a02cf62f2927ee073ba921b5cba10301043f41ed494860f0ccc7508f1058c25f8ebcd56e9f8da018b@149.28.140.203:30303,enode://3a792327abf09be1b78db697c33de653d21bb702eaf6e292899c31a59f0b9535753a34d41f088416bc3f90d25c35ecd6b79d0015c36cf10f9a27c89ecd1f7fa4@149.28.140.232:30303,enode://26def7887241597a30314a77b1a32f156bdcc92eee198b086ae7c4dc26b986a9be6d078b09e93a1f963b083885020e1edfbf6b053dcebbdd090f6dfb289b59f0@149.28.142.223:30303,enode://f35e4ff8bfca2b37297dae0524146c2e4ef20c5d95be48cabe0072334bcf77a9385bad27b9630ee5ba4de451076c2123ad06113f21e3f78387a0e6fde7ec1b0b@45.77.183.160:30303,enode://44f8256e0285d1a94a73187116772522dcf53ef3affcac171cf01ffb00ec613ba1960f1309cc9353207a8f1211e645016c6e30b9669190aac8386c78545b84b1@198.13.34.190:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@139.180.218.68:30303,enode://5701cfd1d03a04a3a17076e50983397ff634ff7f00693f62f6d4d94107796b74b8e10b8ad6efbf1499ae0c6263e84594d30986c79242a37b1c9d27cddb57cdc5@207.148.71.42:30303,enode://b0bd514f1b0892ab26c1d8be59510406f7d700c74cd3cd03d3f8d0fc21b784bb2fb7bde3afacf435928ca9506decf73bd15af5a64bd5dd113b26fc91605ce397@45.77.181.79:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@139.180.135.153:30303,enode://297167bcccf50a94fd2b9a1f1a372228526a95066030295ee8842e0bcaf798da751974a8b08caa9fb9764d2b2d50e64ec5a90a8b942a2a9d6b1db9d5995de3ff@139.180.143.152:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@45.77.244.187:30303,enode://95fc2505216570bce1f75de47289d5cdcd35eba61a3e2d89fe1690dbdc60e22d8a12fe12c54c77d87f7b56035aa9ef2021387906ac3f5b3814cd90267b64f02e@45.76.153.161:30303,enode://3a914391c6f6ff0af000b5e614df1074c2a2db2575d6c4d02c3d96bc00ed52ba4281df45b065cbc253c2a02d0bc34272520e772ee9880b28ef107e91b86166d8@109.169.55.28:30303,enode://2953c5ea2a2829a242123e14538b137be858602da1e68beb8c7f7ec797d9d42cf4f0c76b62e98c4d5578e0eeefa42a501fdfec7079e8db206d89d037a09cde3a@109.169.55.28:30304,enode://80dee88ded07fcb0ed1f4a9db4c60c0bd0592d44656571822b479047653b0c30d84e68c83057db048d2120cd7d504fd6a70a89161c31aaf98e65cfba4a77a528@109.169.55.28:30305,enode://7e495d7e1be1fc47d62f8510249435fb3b6f279880704896cbd78e05027298ed133979a388cc0ecf51fb014a8c68438b45e4a2d82ab1ed9cf86a31e87fed32c5@78.129.229.96:30303,enode://02c155fe4b34293b50d70a10889a57d9f2434fefdf142c6d24d73df9ccff19994cb243b55e87a9349a8f87d827363f74b0b40f44d96925aaaedadb456e38c0c0@78.129.229.96:30304,enode://bc2a722d080b008132ef395763d87f491fb6adc34b5d34b698cfeeadced2d4468ee5dc09f39956b4686c88af9bf26e39bc050feb52c0976238645a0343e6049f@78.129.229.96:30305,enode://560113969268e30a430991e36fcb1a6ea8a2bc16f23bc1dabffd6f8c17649237d58d8cf554e9ce882184abdc9b3a607230123e2bcf819d4ed01ec02acee1c4c2@78.159.100.155:30303,enode://a86d3268c060323572bfeb6df76081e4668ec44cc60ff028c1685a9a683c5d6497c987b5dfade81323d08875066218a1877484396e11f400ce1c2c9bd343c935@78.159.100.155:30304,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@127.0.0.1:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@78.129.229.96:30301,enode://1c20e6b46ce608c1fe739e78611225b94e663535b74a1545b1667eac8ff75ed43216306d123306c10e043f228e42cc53cb2728655019292380313393eaaf6e23@5.152.223.199:30301" --syncmode "full" --datadir ./nodes/3 --networkid "${networkid}" --port 30305 --rpc --rpccorsdomain "*" --ws --wsaddr="0.0.0.0" --wsorigins "*" --wsport 8557 --rpcaddr 0.0.0.0 --rpcport 8547 --rpcvhosts "*" --unlock "${wallet3}" --password ./.pwd --mine --gasprice "${GASPRICE}" --targetgaslimit "420000000" --verbosity ${VERBOSITY} --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,XDPoS --ethstats "XinFin-MasterNode-03:xinfin_xdpos_hybrid_network_stats@stats.xinfin.network:3000"

A New XIP Proposal to Tokenize DApps with Dividend Yielding Tokens on the XDC Network

Quincy Jones — Tue, 04 Oct 2022 20:53:29 +0000

Tokenizing DApps: SHARES & SPLITS

Most people are familiar with NFTs as decentralized objects that show ownership of an item or keep a unit of account. An NFT can represent literally anything, even a decentralized application (DApp).

I recently made a proposal to the XDC Community (XIP Proposal) to standardize a new type of token — the SHARE. A SHARE is an NFT that represents ownership over a DApp and will take the incoming funds and distribute them among the token holders. Developers can also use these NFTs within their application to give the SHARES governance capabilities, such as access control and voting rights, by defining the tokens in the code itself.

There are 2 types of SHARES — SHARES and SPLITS. A SHARE acts as a share of a DApp that receives the dividends based on its performance while a SPLIT is a share of a SHARE, receiving the yield of the original SHARE while splitting the dividends again amongst a set of derivative token holders.

SHARES are not a crypto currency but a native crypto asset to a crypto application. The performance and relative value of the SHARE is predicated on the growth and use of the DApp and the accumulated fees that are dispersed among the token holders.

SHARES Attributes:

A DApp can have a max of 1,000 SHARES.
Each SHARE has its own account in the contract, and the holder of the SHARE can redeem any yield from that token’s account.

SPLIT Attributes:

SPLITS have the same amount of splits per SHARE as the SHARE has total SHARES.
A SPLIT is a uniform contract and doesn't have any additional functions but redeem value from the deriving SHARE.
A SPLIT of the same generation maintains equal value even if it comes from a different SHARE in the same SHARES contract.

Example of a DApp with SHARES:

GitHub: https://github.com/CoinClubQuincy/XRC-SHARES

All function within contract can use this line of code at the bottom of their function to forward funds to the receiving function to allocate funds.

redirectValue(msg.value); //this will forward all funds to share token treasury

This contract bellow is an example of a lemonade stand contract that receives 10XDC for a glass of lemonade and divides those funds amongst a set token holders while keeping track of how many glasses have been sold.

contract lemonadeStand is XRCSHARE{
    uint public lemonadeCount =0;
    constructor(string  memory _name,string  memory _symbol,uint _totalSupply) XRCSHARE(_name,_symbol,_totalSupply){}

    function GlassOfLemonade()  public  payable  returns(bool){
        require(msg.value >=  10000000000000000000,"need more funds");
        lemonadeCount++;
        //this call can be used in all functions that recive fees
        redirectValue(msg.value);
        return  true;
    }
}

SHARES & SPLITS allow developers to sell portions of their DApps by allowing a simple means of owning and distributing equity of profitable applications that reside on the XDC Network. This means an investor can invest in the DApp, to help the developer build more features or to help grow its user and community base while being attributed dividends. The value of the tokens are based on the performance of the DApp. Any DApp, no matter how big or small, can have SHARES to allocate profits.

SPLITS are uniform contracts to split SHARE tokens into smaller dividend tokens that redeem and split the dividends allocated to that associated token provided to the SPLIT contract. A SPLIT is functionally identical to a SHARE, but a SPLIT can only represent partial ownership of a SHARE, whereas a SHARE represents ownership of the DApp. If a DApp uses the SHARE tokens as governance tokens or in some form of automation, SPLITS cannot participate. SPLITS only redeem dividends from the SHARE that's been split.

We refer to these layers of SPLITS as generations, as shown in the graphic above. The original SHARE stands as generation 0, the next is generation 1, and so forth. All SPLITS in a given generation hold equal value.

These generations allow for SHARES to be divided up indefinitely. SPLITS can only have as many splits as the SHARE contract has SHARES. That means that if there are 1,000 SHARES, each of those SHARES can have only 1,000 SPLITS in the first generation. In the second generation, each of these 1,000 first generation SPLITS can have 1,000 second generation SPLITS.

Meaning that in generation one, all the SHARES can have a total of 1 million SPLITS derived from them, and in the second generation can have 1 Billion SPLITS derived from its first generation SPLITS . Simply put, dividend-earning stakeholding of a DApp can increase liquidity in each generation, as these SPLITS also increase affordability to investors who want to own the yield of a DApp,as a derivative token of the original SHARE.

How DApps Can Use SHARES

DApps can use SHARES in a few different ways:

DApps can be built with SHARES to allow for dividend allocation of the revenue in these DApps
Developers can also build more smart contracts after the fact, which can offer more functionality and consolidate the profits from the new DApps into the original SHARE contract
Third-party developers can also do this to add functionality and increase the yield for the SHARES
Developers can also create abstract single function contracts (ex: polling DApp, analysis DApp, Tax DApp) called DApplets — isolated DApps that aren't typically user facing and may allow functionality to other smart contracts that can hold SHARES and justify profitability from otherwise abstract functions
SHARES are a direct means of having developers sell portions of their products no matter how big or small to help fund their future products
Investors can own DApps similar to how they own companies

Currently, crypto currencies are the primary market on blockchain. However, as DApps develop novel means of ownership, new markets will arise that are centered around the popularity and growth of DApps. As primary DApps interconnect with secondary applications that rely on them, both the secondary and primary DApps may become profitable. The SHARE holders of both are able to gain fees on the usage of their contract.

SHARES and SPLITs allow developers, investors, and DApp users to easily sell and invest in DApps of all sizes in a more autonomous way than was possible before. This model exemplifies the promise of blockchain.

The XRC-SHARE & XRC-SPLITS contracts have been submitted to be approved as an official standard on the XDC Network. To comment on the process or the contracts, check out the XDC-Community Github to participate in the XDC XIP process.

Delegated Authorities & Notarizing Identities on the XDC Network — #BuildItOnXDC

Quincy Jones — Thu, 02 Jun 2022 16:20:10 +0000

Blockchain technology can be used to implement a collection of different tools. Most deal with finance or automations, but what I want to talk about is personal data and self custody of information.

Legacy applications currently run on third party servers hosted by a company. With this comes big risks. Data leaks, corporate hacks, or any other compromise of user information.

Most users are familiar with Know Your Customer (KYC) conditions of financial institutions — be it a bank, a broker, or some application with requirements to identify users for regulatory requirements.

Applications in Web 2.0 meet these conditions by possessing user data in their databases and verifying the user data within their own systems, as each application has its own means of collecting, verifying, and storing user data. This is a security concern, as users are reliant on the security of the different applications to secure their personal Identifiable information (PII). This information could be breached or leaked by any of the applications, leaving users’ private data exposed.

The XDC Network offers the potential to mitigate that risk by hosting private userdata on the blockchain. Data stored privately in a contract cannot be leaked or stolen as in a typical relationship database. I have previously written about storing private data with a token and creating user logins.

We can also store identities and verify them. Without the need for a 3rd party to host the data, leaks and hacks can be mitigated and redundancy of data can be reduced.

In The Delegated_Authority.sol contract example I provide PII data for:

(Public) Legal Name
(Private) Address
(Private)Passport ID
(Private)Social Security Number
(Private)Driver’s License Number

But any necessary data can be modified to suit the required needs of the delegated authority.

A delegated authority is a dApp who would verify the identity of their users then having a boolean status result presented to third parties who have delegated trust to the delegate contract to give accurate results. The delegate contract is a contract who will deploy a series of smaller contracts that hold the user private data and will be allowed to view and notarize the identities of the contracts. Delegated authority contracts will have authentication tokens associated with them, only the possessor of which can read and notarize the identity of a user. These delegated authorities can be banks, financial institutions, or any establishment that is required to verify PII data on their users.

For example if a bank needs to verify an identity of a user to create an account the bank can launch a delegate authority contract and as users submit information to confirm their identities there will be a new generated contract that will hold their data and issue a token to show that the new generated contract belongs to them. With this other applications like an exchange can delegate the task of authorizing and confirming the identities to the banks delegate contract,which can check to see if the users KYC contract has been notarized and can check to see if the current user is holding the token that represents the Identity of the KYC contract they was generated when the user submitted their KYC info to the delegate authority.

On the XDC Network, a smart contract created by the delegated authority will allow for users to enter some know your customer (KYC) Personal Identification information (PII). This will create a separate KYC contract that contains the PII data of the user, and will generate an ID token for the user.

This ID token can be used as a form of notarization to third party dApps that they are the correct Identity of KYC contract and can view contents of the contract to view the PII data. Only the delegated authority will also have permission to view the contents of the generated KYC contracts as well as store and notarize authenticity and the status of said contracts. When a KYC contract has finally been notarized, either manually or programmatically by the delegated authority, third party dApps can check the validity of any given KYC contract from the delegated authority. If the user in the dApp possesses the ID token produced by the contract, their identity is confirmed.

The delegated authority contracts can even monetize their authority by charging micro fees to check the validity of a contract. Delegated authorities can bear the risk of notarization while being compensated for that risk. While dApps can offset the responsibility and resources to notarize identities for a fee and focus on other tasks.

This will allow for a reduction in redundancy, as a user can notarize his or her data just once before carrying it to multiple dApps. The security of the authentication token mitigates risk by securing access to the data. This is similar to how you would hand a security key to a key management service (KMS) instead of hosting user data in a database.

Blockchain dApps can finally have a means of compliance with KYC standards while offsetting risk and freeing up resources. Delegated authorities can be the gateway between legacy systems and blockchain by notarizing and tokenizing identities for easy use and even monetization by third party dApps who seek top notch security.

This can be the future of identification, passports, and all other sorts of verification. All it takes is trusting a delegated authority to move identification data on the blockchain.

About the Author: R Quincy Jones XDC Foundation developer, who on behalf of the XDC Network is building new standards and applications for the XDC Network. With over four years in cloud development, and a growing following on YouTube: CoinClubCrypto, is well-suited to break down the fundamentals of blockchain-based technologies for general audiences.

GitHub Link: