xFUND: Behind the scenes

Oct 8, 2020 · 7 min read

For an introduction to xFUND, see the article “What is xFUND? And how to participate in the ecosystem

Implementing xFUND has provided an interesting challenge from a technical perspective. On the surface, it seems relatively simple: xFUND are emitted daily to FUND Mainchain (MainNet) validators, who can then claim the xFUND to do with as they please. Easy, right? Well, hopefully for validators, yes! Behind the scenes however, there is a fair amount going on.

First, there needs to be a method for fairly distributing xFUND emissions to validators, in such a way that every active validator has a chance of being allocated an xFUND emission, no matter how small their total stake.

The process is also bridging two mutually exclusive blockchains — FUND’s Mainchain, where our awesome validators are chugging away securing the network, and Ethereum, where the xFUND ERC20 smart contract resides. Since there is no inherent correlation or link between the two, there needs to be a system in place to bridge data from both chains.

The next challenge is proof of ownership and identity. In order for a validator to claim their xFUND, they will need to prove both their validator identity and ownership of the Ethereum address they are claiming the xFUND with. It’s perhaps worth noting that “identity” in this context merely refers to the FUND wallet address a validator uses to interact with their node on FUND Mainchain.

There also needs to be a method where every action undertaken during the emission and claim processes are logged somewhere on-chain for public auditing and transparency.

Finally, this needs to all be wrapped up and implemented in such a way that it is as secure as possible while also being as easy as possible for validators to execute.

Below, I will attempt to explain the overall process while addressing how we overcame the above challenges.


The Portal, Oracle and BEACON bridge the processes and blockchains together.

The Portal acts as an interface for validators to interact with the overall system, enabling them to easily monitor their emissions, logs, audits, and also claim their available xFUND whenever they like.

The Oracle monitors both blockchains for pertinent data, and either acts upon it or submits data to Mainchain (via BEACONs) accordingly.

The BEACON allows the logging of every successful action — emissions and claims — on-chain, allowing for a full transparent and public audit trail of the xFUND emission and claiming (minting) process. By querying the BEACON data, it’s possible to see exactly who is entitled to what, and what has been claimed in order to rebuild the xFUND emission and claim history.

xFUND emission distribution

Out of all the challenges, this was — relatively speaking — the simplest. The algorithm has since been refined, but the end result is the same. Each day, the xFUND Oracle queries FUND Mainchain (MainNet) for the current active validator set, along with their current FUND stakes (both delegated and self-delegated). Each validator’s stake is then calculated as a percentage of the total network stake, which is used by the emission algorithm to calculate the probability an xFUND will be allocated to the validator. The emission algorithm runs 24 times, each time emitting 1 xFUND and allocating it to a validator based on the probability. Each allocation is also mutually exclusive of all others, and being allocated an xFUND emission does not affect subsequent allocations within the emissions batch.

An emissions simulator has been deployed here, and the simulator source code, which is an exact replica of the actual emissions code, is available here.

The validator set and stake data used by the emissions algorithm is refreshed every day immediately before the algorithm runs, so it always has the latest data — meaning a validator’s probability can decrease or increase daily depending on how their stake has changed within the previous 24 hours.

Once all 24 xFUND emissions have been allocated, each individual emission is then recorded in a BEACON timestamp on FUND Mainchain. BEACON timestamps allow a certain amount of flexibility with data submissions, and while a submission is (currently) limited to 65 characters, it is not restricted to only being used for 32 byte hashes. In this case, raw emission data is being submitted, for example:


The first two characters (in the above example ) represent the emission number for the day, and range from to . The next 13 characters are the UNIX Epoch (including milliseconds) at which the emission occurred. Finally, the bech32 value of the validator’s self-delegate address to which the xFUND was allocated is appended.

Emitted xFUND are not claimable until they have a corresponding BEACON timestamp on Mainchain.


xFUND emissions are allocated to validators’ self-delegate/operator address. This is all well, but how can the claim process be sure that it is indeed the actual validator claiming their xFUND? How can the process be sure that they are the owner of the Ethereum wallet into which they want the xFUND minted?

In order to initialise an xFUND claim, the validator needs to 1) prove they are actually the validator and owner of the self-delegate/operator address, and 2) prove ownership of the Ethereum wallet address they want to claim with. This two-step process is integrated into the xFUND Portal.

1. Validator — prove identity

First, the validator submits the Ethereum address they are using to claim their xFUND, via the Portal. The address is acquired automatically via Metamask integration into the Portal, and is the address currently active in Metamask. Once submitted, a JSON Web Token is generated. The JWT is comprised of the Ethereum address and the payload is signed, for example:


The above example can be decoded and viewed here.

The validator is required to submit this JWT as a memo in a transaction containing an empty message to FUND Mainchain — an example Tx in the Blockchain Explorer is here, and the raw REST query here. This is a special transaction that only the owner of the corresponding private key for the self-delegate address can sign and send, and is therefore proof that the person sending the transaction owns the validator node’s self-delegate address.

2. Ethereum address — proof of ownership

The resulting Mainchain transaction hash must then be submitted by the validator to the Portal. The Mainchain tx hash is submitted along with an Ethereum “typed data” message containing the tx hash, signed using the method. The message must be signed by the key for the Eth address submitted when initialising the claim in the previous step. (Note: hardware wallets such as Ledger do not currently support methods). This ensures that the Mainchain tx hash is actually being submitted by the Eth claimant embedded in the Mainchain tx’s memo.

The signed message and tx hash are forwarded to the Oracle, which validates all of the data on-chain, along with the signature and other elements required to validate the claim. Validation consists of several stages.

The first stage is checking if the FUND Mainchain transaction has actually been accepted by the network and that it contains a message, and a memo field.

Next, the signature of the Mainchain transaction is extracted from the section of the transaction, and the bech32 wallet address is derived by decoding the public key embedded within the signature object. The derived address is used to further validate the claim, and verify the JWT embedded in the Mainchain tx’s memo.

If the transaction is valid, and the JWT in the memo successfully verified, then the claimant’s Ethereum wallet address is extracted from the memo.

Finally, the Ethereum address is also recovered from the signature what was sent along with the Mainchain transaction hash, and is compared with the address extracted from the decoded JWT from the Mainchain transaction memo to check that they match. This helps verify that the Ethereum address that was used to initialise the claim is the same address used to complete the claim, and that all steps and elements have been completed and submitted by the owner.

If at any point in the flow a single check fails, the claim is rejected.

If all of the checks and validations pass, a claim ticket is finally generated and issued to the validator.

Where are the xFUND?

Up to this point, xFUND don’t actually exist as an ERC20 token, and there has been no interaction with the xFUND ERC20 smart contract. The claim ticket issued to a validator is a promise that the amount of xFUND being claimed will be minted for the wallet address specified within the ticket — as long as the ticket itself is actually valid! xFUND only come into existence as actual ERC20 tokens when a validator submits their claim ticket to the xFUND ERC20 smart contract, and the contract is happy that the ticket is indeed valid.

The smart contract’s function is where claim tickets are submitted and verified — the contract submission process is also integrated into the Portal, using Metamask as the vehicle for delivery (although, once the ticket has been issued, it is technically possible to use any method to send the data to the smart contract, for example via Etherscan’s contract writer).

The smart contract checks the submitted ticket, and validates the claimant’s address and amount being claimed. If everything checks out and is verified, the xFUND are finally minted and allocated to the Ethereum wallet address, and the smart contract emits a event to log the claim.

The xFUND Oracle monitors the Ethereum network for these events and finally submits a BEACON timestamp to FUND Mainchain with the Ethereum Tx hash as the data. Validators cannot claim again until the open claim has been processed and confirmed.

Validators are free to claim as frequently or infrequently as they like — as long as xFUND emissions have been allocated to them.

Web: unification.com
xFUND: https://xfund.unification.io
Telegram: https://t.me/unificationfoundation
Twitter: https://twitter.com/UnificationUND
Github: https://github.com/unification-com
Discord: https://discord.gg/SeB69w5

Paul Hodgson, Unification CTO

Unification Foundation

Blockchain Solutions For Enterprise