Unification Foundation - Medium

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

Unification Developer Update — August 2025 was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unification Developer Update — May 2025

Codegnosis — Wed, 21 May 2025 08:42:06 GMT

Unification Developer Update — May 2025

Spring and Summer for Unification have historically been about major network upgrades. This year is no different, and therefore the main focus of this Developer Update is the work we have been doing on our mainchain software, the recent successful TestNet network upgrade, and our roadmap for the MainNet network upgrade.

We remain wholly committed to the continued development and improvement of our ever-growing permissionless software suite, and are excited to walk our community through the latest development progress!

Dev Work to Date

Mainchain & the und Binary

v1.11.0 of the mainchain software has been finalised and released. This version has already been successfully rolled out to TestNet (see below), and the MainNet upgrade is planned to begin in the next couple of weeks.

A huge amount of work has been undertaken in updating the code for this behemoth upgrade (see the scanlan branch of the mainchain Github Repository), but it’s been worthwhile!

The latest und binary implements Cosmos SDK v0.50.x and IBC v8.7.0. The SDK, IBC and custom FUND modules have all had a number of exciting updates — here are some of the highlights:

eFUND minting process

We’ve made some changes to the minting process for eFUND. The changes are all under the bonnet, and the end-user process remains the same for purchasing and utilising/spending eFUND. Spent eFUND are also distributed to validators in exactly the same way.

Previously, when eFUND were purchased via a Purchase Order (and the PO was accepted and processed), the entirety of the value of the PO was minted as FUND and then transferred to the Enterprise module’s account to be held in escrow, until the eFUND owner used it to pay for fees. When eFUND was used to pay for WrkChain/BEACON fees, a custom AnteHandler was executed by the Enterprise module to unlock and transfer the fee amount from the Enterprise module account to the eFUND owner’s account. This was executed before the Cosmos SDK’s Fee AnteHandler was run, to ensure that the correct amount of eFUND was unlocked and then only used to pay for valid fees.

This process — while it worked well — was somewhat burdened with a rather convoluted requirement that was becoming increasingly difficult to maintain with each Cosmos SDK upgrade. The problem was that since the entire eFUND in a PO was minted as FUND at the point of purchase, it was included in the Bank module’s total FUND supply calculation. This led to an inaccurate representation of the FUND total supply (by the Bank module’s default query interface), since the eFUND was not yet supposed to be available for general usage in the total supply. To overcome this, some customisation was required to the Cosmos SDK Bank module’s Total Supply gRPC/REST API query interfaces, to subtract any locked eFUND from the FUND total supply prior to reporting the final amount. These changes were also required to the CLI commands used to query the Bank module.

With the latest Cosmos SDK releases migrating more to Pulsar and AutoCLI, this was becoming increasingly difficult to override, and therefore the decision was made to rewrite the underlying minting process.

In the latest mainchain release, eFUND is still purchased and locked using the same methods, but it is now minted as FUND at the point of usage, instead of the point of purchase. As far as eFUND users are concerned, there’s no change — the Locked eFUND amounts, etc. still remain the same post-upgrade — but future maintenance of the software is now much simpler, since there is no longer any need to customise the API interfaces reporting the chain’s Total FUND Supply. Therefore, the standard/default Bank module code can be used to query the total supply.

The upgrade process will handle the Enterprise module state migration from consensus v3 to v4 and the new minting method automatically. During the migration, the FUND currently held by the Enterprise module account (as locked eFUND) will be burned from the total supply. This will have zero effect as far as end users will be concerned — the Total FUND Supply will remain the same after the upgrade as it was before. To be clear: nothing is being burned from the active/general FUND supply. Only FUND that, for all intents and purposes, did not exist in the first place is being burned.

Full code changes to the eFUND minting process can be viewed in this Github Pull Request — https://github.com/unification-com/mainchain/pull/303

Expedited Governance Proposals

With Cosmos SDK v0.50.x comes Expedited Governance Proposals. Expedited proposals can be submitted which reduce the Voting Period required for the proposal. However, expedited proposals also have a higher vote tally threshold in order for them to pass. If an expedited proposal does not pass within the shorter vote period, then it is automatically converted to a standard proposal and voting begins again with the default proposal tally threshold.

This opens up the potential for critical proposals that require fast decisions — for example, a critical planned software upgrade — without the need to reduce the standard voting period parameter.

See the Cosmos Documentation for more details.

Confix

Confix has been implemented in und v1.11.x. It is the latest Cosmos SDK configuration management tool, which allows much simpler editing of the software’s configuration files (config.toml , app.toml, and client.toml) via the command line.

Confix also handles application configuration file migration from previous versions of Cosmos SDK. For example, running the command und config migrate v0.50 will automatically make any required modifications to .und_mainchain/config/app.toml in order to make it compatible with Cosmos SDK v0.50.x.

Finally, using the diff subcommand instead of migrate (e.g. und config diff v0.50), will simply display the required changes instead of automatically setting them, allowing node operators to manually verify and configure the required changes.

Pulsar API

One of the interesting features we have implemented in v1.11.x is the Pulsar API, which is generated from the Protocol Buffers, using the new golang apiv2 of protobuf. These are now used extensively in Cosmos SDK, and we have also implemented them for the mainchain modules (Enterprise, Payment Stream, WrkChain and BEACON)

AutoCLI & Hubl

We have also implemented Cosmos SDK’s AutoCLI feature. Not only does this handle automatic generation of und CLI commands (which it derives from the Pulsar API, as opposed to manually defining and coding commands for each module), but will allow Unification mainchain commands to be executed using Cosmos’s Hubl application!

Hubl is a command line utility which allows users to query any blockchain implementing Cosmos SDK, meaning that any und query command will be available via the all-in-one hubl command line tool.

This is a huge step forward for the Unification mainchain application becoming integrated into the wider Cosmos community and application suite.

Testnet command

The testnetsubcommand has been implemented, which allows for the quick generation of the configuration files required to run a local testnet. This can be useful for developers who wish to rapidly deploy their own local/offline environments in order to quickly test their applications prior to deploying on TestNet/MainNet. A localised testnet can be configured to the developer’s needs, then reset and reused as required.

Public TestNet Upgrade

The public TestNet was successfully upgraded to und v1.11.0 on 14/04/2025 at approx 13:30 UTC, in block 18,359,370. As covered above, und v1.11.0 implements Cosmos SDK v0.50.x and IBC v8.7.0 and TestNet is therefore currently running all of the changes and improvements outlined above.

Planning for the MainNet rollout is now underway and an announcement will be made via all available channels within the next couple of weeks when the details have been finalised..

WIP

MainNet Network Upgrade

With the successful upgrade of our TestNet, planning is underway to rollout the upgrade to MainNet. As usual, we plan on monitoring TestNet for any potential issues over the next couple of weeks.

The tentative release schedule for MainNet is as follows:

26–28/05/2025 — submit the upgrade governance proposal
02–04/06/2025 — voting ends
09–11/06/2025 — upgrade executes

Final dates are to be decided, and may change by a few days either way.

Announcements will be made in due course via our usual channels (Telegram and Discord).

Developer Portal

In the Pipeline

Cosmos SDK/IBC Upgrades for mainchain

Planning has already begun for updating the mainchain und application to the Cosmos SDK v0.53.x and IBC v10.x upgrades. Although the code migration looks to be much simpler than v0.47 to v0.50, we’ll be waiting for a more stable release of the v0.53 branch before commencing work on the upgrade. (Note — Cosmos have rolled up v0.52 into v0.53, hence the version skip)

Web Wallet Makeover

As mentioned in our previous Developer Updates, we’re still in the R&D stage regarding the Web Wallet makeover.

Payment Streams module

We believe that the Payment Streams module can benefit the wider Cosmos community, and as such, we’re looking to decouple the code from the mainchain repo, allowing it to be released as an independent SDK module that can be integrated into any Cosmos chain.

As far as Unification mainchain goes, this will be seamless — there will be no noticeable changes to MainNet, and the module will function as it does currently.

We’re currently researching the requirements for this, but it will effectively mean that the module will have its own versioning and release schedule.

Outro

We’re excited to continue the development work on our permissionless toolset! While the majority of our development has been focused on the Cosmos SDK/IBC upgrades for mainchain over the last couple of months, we’re partially shifting focus to our other tools after rolling out und v1.11.x to MainNet, in addition to progressing with the Cosmos SDK/IBC upgrades.

Important Links

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

Unification Developer Update — May 2025 was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unification Developer Update — February 2025

Codegnosis — Tue, 04 Mar 2025 07:13:58 GMT

Unification Developer Update — February 2025

In a critical and turbulent time in the Blockchain industry, the Unification team has continued the development of our road-map and we are glad to see the focus once more on true decentralised, technical and financial utility and breakthrough in the space which we have contributed to since our origin.

As always, we’re excited to share the latest progress including the imminent release of UNoDE 2.0, mainchain upgrades, and new developments across our ecosystem. We’re on the verge of launching the highly anticipated UNoDE Community Cloud public beta, paving the way for a more decentralised and rewarding infrastructure for Community Node Operators.

We’ll also cover major updates on the Developer Portal, OoO & VOR on QOM QL1, and upcoming Cosmos SDK upgrades. Let’s dive in as there’s a lot to cover!

Dev Work to Date

UNoDE 2.0: Community Cloud

The UNoDE 2.0 Public Beta is, from the technological perspective, pretty much ready for deployment. We’ve had a feature freeze in place for a number of weeks, and are working on a few final tests and optimisations.

UNoDE 2.0 will introduce the UNoDE Community Cloud platform, which — as previously promised — will allow anyone running EVM or Cosmos SDK compatible RPC nodes to plug them in to the Community Cloud backend. In doing so, they not only earn the auspicious title of Community Node Operator, but also (and perhaps arguably more important) gain the opportunity to earn income for serving data to UNoDE end users.

Indeed, one of the final features we’re testing and optimising is the actual payout process. Community Node Operators will be able to view, manage and create Payout Requests from their main UNoDE dashboard:

Once created, Operators will be able to view their requests and the respective statuses of their requests in the same dashboard. Fully processed and paid requests will also be accompanied with relevant data such as transaction hashes, allowing operators to obtain information required for their own accounting processes.

Initially and for simplicity, payments will be made in FUND on MainNet on a frequent batch basis. Operators will simply need to provide a FUND MainNet wallet address to which they would like to receive their payments.

Numerous tests for the Payout system have been run on FUND TestNet, and several test cases have been successfully processed by our test wallet: und1g68rqj3m3wje4ypgpkn9vpvw38xpsh6lgf4vev.

Community Node Operators will also be able to easily add, remove, and manage their Community Cloud nodes from within their UNoDE dashboard.

Once the node has been verified and plugged in to the Community Cloud backend, the UNoDE API will be able to route UNoDE user requests to the RPC node, thus earning the Community Node Operator income.

The platform has many measures in place and should any issues arise with a Community Node, the backend will notify the operator so that they can address the issue. Once addressed, the operator simply needs to re-verify the node with the UNoDE backend for it to be included in the active node pool on the Community Cloud platform.

It’s been a long, challenging road building the Community Cloud platform, but we’re excited to be on the cusp of deploying the public beta!

Community Node Operator: Applications open

In preparation for the release, we have created an application form for anyone interested in becoming a Community Node Operator. While the goal remains to allow fully permissionless additions to the network, we believe a steady introduction of operators into the Community Cloud is important, and the most sensible way forward, especially during the nascent period of the public beta. This will allow us to closely monitor and address any potential issues with a smaller number of experienced operators and without being overwhelmed.

More details on this and future plans are expanded in the WIP section below.

Interested node operators can apply here.

UNoDE.me Domain

For the public beta of UNoDE 2.0, we’re excited to be deploying the platform on a brand new dedicated domain — unode.me! Access to the dashboard and API will still be available via the existing unode.unification.io subdomains, but eventually, requests will be redirected to unode.me and ultimately, the unode.unification.io subdomains will be retired.

UNoDE users will receive plenty of notice before the domain is retired, allowing them enough time to migrate any existing applications to the new unode.me domain.

OoO and VOR Deployed on QOM QL1

We’re dedicated to making our tools available across multiple networks and platforms, and as such are happy to announce that both OoO and VOR have been deployed on QOM’s QL1 network. This allows developers to deploy their OoO and/or VOR enabled smart contracts on QOM mainnet. The respective deployment details for xFUND, OoO and VOR are as follows:

xFUND Token on QL1: 0x0d2FDD551199513D89D64d766E053E6fBC838831

OoO

OoO Router on QL1: 0x2E9ade949900e19735689686E61BF6338a65B881

Unification Foundation OoO Provider: 0xFDEc0386011d085A6b4F0e37Fab5d7f2601aCB33

VOR

VORCoordinator on QL1: 0xE5b72154bce0e75dA73Da3d9D9F3B17A6eAE31DD

BlockHashStore on QL1: 0x2E9ade949900e19735689686E61BF6338a65B881

Unification Foundation VOR Provider: 0x0181C847cE74B4F3201d10867aCb1180E5961cF4

This information is also published on our documentation portal.

Developer Portal

We have been working hard on the Unification Developer Portal, and are hoping to release the initial deployment alongside UNoDE 2.0.

As previously mentioned, the Portal will act as a central resource for developers wanting to harness any of our tools and integrate them into their projects. This is a medium to long term project, and the initial deployment of the portal will include:

Developer specific documentation with code snippets and examples for:
- Payment Streams integration
- OoO
- VOR
- WrkChains
- BEACONs
- fundjs and fundjs-react libraries
- UNoDE
Integrated Payment Streams dashboard
UNoDE integration
Integrated TestNet Faucet

With the release of the Developer Portal and UNoDE 2.0, we’ll also be offering any users who register on the Developer Portal a free UNoDE subscription! The free tier should be sufficient for most trading and client side usage, providing one of the fastest and most private options to all, while higher tiers will continue to offer more flexibility for developers and heavier users.

WIP

UNoDE 2.0 Improvements

UNoDE is a long term project, so we’ll be working constantly on improvements, optimisations and new features. The most significant aspects currently being worked on are related to new Community Node Operators joining the Community Cloud platform.

We want to make the platform robust. As such, any node operators interested in joining the platform are currently required to submit an application. If successful, they will be whitelisted and therefore have the ability unlocked in the UNoDE Portal to add their nodes to the backend. This short-to-medium term strategy will allow us to slowly build the platform in a controlled manner, while also allowing us the time and breathing space required to make the improvements and optimisations in order to open the Community Cloud platform to the wider public.

One of the major aspects of the Community Cloud improvements will involve ensuring the validity and integrity of data served by Community Node Operators to the UNoDE users via the API. With a relatively smaller number of experienced operators, we will be able to more effectively implement and test incremental improvements in a controlled manner, thus allowing us to build an increasingly robust platform.

We don’t believe in rushing. We’re in it for the long haul, and endeavour to do the best we can for our community.

Mainchain

Cosmos SDK / IBC Upgrade

Work is continuing on upgrading the mainchain codebase to implement Cosmos SDK v0.50.x and IBC v8. The upgrade to v0.50.x is the second and final step in the Cosmos migration from Tendermint to their CometBFT consensus platform. As with the previous update, there is a significant amount of work involved in migrating the code and implementing the SDK upgrades.

One aspect of the v0.50 branch of particular interest to us is the modularisation of SDK modules. This means that it should potentially be much easier for us to make our Payment Streams module available for any Cosmos chain to integrate and use. Once the mainchain codebase has been updated, we will be investigating the feasibility of this process (much like IBC migrated to a module independent of the SDK).

Codenamed Scanlan, we aim to execute the network upgrade in Q2 2025 in accordance with our usual network upgrade release schedule. Over the coming weeks, anyone interested will be able to follow the code commits to the scanlan branch of the mainchain repository.

As always, TestNet will be upgraded first, closely followed by MainNet.

Developer Portal

In addition to UNoDE, and Unification mainchain upgrades, the Developer Portal will be one of our main points of focus going forward. We’re really enthusiastic about building a solid platform that brings all of our products together, knitting them together such that developers can easily access and build using our tools in a single workspace.

In keeping with our decentralised and community-centric ethos, we’re always welcoming of any community input, ideas and of course development contributions, and look forward to working with everyone going forward!

In the Pipeline

Web Wallet Makeover

As mentioned in our previous Developer Updates, we’re still in the R&D stage regarding the Web Wallet makeover. The Web Wallet has so much potential going forward, and certainly deserves some TLC!

Payment Streams module

As far as Unification mainchain goes, this will be seamless — there will be no noticeable changes to MainNet, and the module will function as it does currently.

We’re currently researching the requirements for this, but it will effectively mean that the module will have its own versioning and release schedule.

Outro

With the UNoDE 2.0 public beta release, our Developer Portal nearly live, and continuous improvements across our infrastructure, a strong momentum is inevitably on the horizon.

We’re committed to building a decentralised future that empowers traders, developers and node operators alike. Stay tuned for more updates, and as always, we welcome community feedback and contributions. If you are a Node operator (or in touch with someone who is), we strongly invite and urge you to join us in the whitelist — and if you haven’t already, join us on GitHub, Telegram, to stay connected!

Important Links

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

Unification Developer Update — February 2025 was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unification Developer Update — December 2024

Codegnosis — Wed, 18 Dec 2024 09:23:42 GMT

Unification Developer Update — December 2024

As we approach another New Year, it’s time to update the community on some of the ongoing and new projects that Unification is developing. UNoDE Phase 2 is fast approaching the end of the private alpha test, and gearing up for public beta deployment. Work is beginning on mainchain’s Cosmos SDK and IBC upgrades, and we have some exciting news for developers as we reveal our new Unification Developer Portal.

Dev Work to Date

UNoDE Phase 2 Alpha Testing

UNoDE Phase 2 private alpha testing is nearing the end, and we’re almost ready to go live with the public beta deployment.

Phase 2 allows node operators to add blockchain network RPC nodes they control/operate to the UNoDE backend in order to serve data requests via the end-user API. Any successful requests served by their nodes will receive a percentage payment from UNoDE subscriptions. For the initial deployment of Phase 2, payments made to node operators will be in FUND on Unification MainNet and in order to receive payments, operators simply need to add a Unification wallet address to their UNoDE account.

Currently, almost any Cosmos based chains, and EVM compatible chains can be added by node operators, potentially increasing RPC nodes offered by UNoDE to users by a huge number.

We’re still tweaking some bits and pieces behind the scenes, but the public beta should be live early in Q1 2025, with full documentation aimed at node operators wanting to join made available at the same time.

OoO Deployed on Puppynet

OoO has been deployed on Shibarium Puppynet, allowing developers to deploy and fully test their OoO enabled smart contracts prior to deploying on Shibarium mainnet.

xFUND Test Token: 0x78f022230EaE6E05D8739E83a14b0Cf1D00CfaD5

Router: 0x7a99f98EfC7C1313E3a8FA4Be36aE2b100a1622F

To fully replicate the Shibarium environment, the xFUND token has been bridged from Sepolia to Puppynet. This means that test xFUND will need to be minted in the Sepolia contract (0xb07C72acF3D7A5E9dA28C56af6F93862f8cc8196), and then bridged to Puppynet.

fundjs & fundjs-react Libraries

The new fundjs and fundjs-react libraries for Unification Mainchain have been released. The new libraries have been built with Telescope — a Typescript transpiler for Cosmos protobufs. This new standardised library includes bindings for all Cosmos SDK modules, IBC applications and our custom Mainchain modules and are available via the NPM package manager here and here.

Developers familiar with existing SDKs such as cosmjs and osmojs can easily use fundjs in their Cosmos based Web3 applications, allowing them to implement the new Payment Streams module, in addition to integrating any other Mainchain module.

A Payment Streams developer guide for fundjs has been published on our Documentation site, and one for fundjs-react will follow shortly. These will also be published as Medium articles in the near future.

Full fundjs developer documentation covering all aspects and functionality is currently in production. Tools for both fundjs and fundjs-react will ultimately be integrated into the new Developer Portal (see below).

WIP

Developer Portal

We’re excited to reveal that we are working on a Developer Portal for all Unification related projects.

Unification and its fantastic community have often been at the forefront of many of these elements with Oracle of Oracles, VOR, WrkChains, UNoDE, and most recently our on-chain module for payment streams.

Given Unification’s mission has been to develop and maintain the best in class truly permissionless rapidly deployable toolkits for decentralised Finance (DeFI) since 2018, with a variety of products and tools throughout the last six years, the time is right to consolidate these tools in a place to allow developers to access and utilise them all in the most efficient way possible.

The Portal will act as a central resource for developers wanting to harness any of our tools and integrate them into their projects. This is a medium to long term project, with the initial basic toolset being deployed and made public at the beginning of Q1 2025.

Initially, the portal will include:

Developer specific documentation with code snippets and examples for:
- Payment Streams integration
- OoO
- VOR
- WrkChains
- BEACONs
- fundjs and fundjs-react libraries
- UNoDE
Integrated Payment Streams dashboard
UNoDE integration
Integrated TestNet Faucet

The ultimate goal is to implement a development environment, with simple IDE capabilities catering specifically for Unification projects. We hope to create an environment where developers can easily generate and write Unification specific code for easy integration into new or existing projects.

UNoDE Free Tier

To celebrate the release of the Unification Developer Portal, Unification will be adding a free tier to the UNoDE subscriptions, available exclusively for developers who sign up to the Developer Portal and access UNoDE via the Developer Portal.

The Free tier will be available from the beginning of Q1 2025, alongside the release of the Developer Portal.

Mainchain

Cosmos SDK / IBC Upgrade

Work has begun on upgrading mainchain to implement Cosmos SDK v0.50.x and IBC v8 (v8.5.2 at the time of writing). As with the upgrade to Cosmos v0.47.x, this is quite a large task requiring a significant amount of code changes and testing. The upgrade to the v0.50.x branch marks the second and final step in the Cosmos migration from Tendermint to CometBFT.

One particularly interesting aspect of the v0.50 branch is the modularisation of SDK modules, meaning that it should potentially be much easier for us to make our Payment Streams module available for any Cosmos chain to integrate and use.

Codenamed Scanlan, we aim to run the network upgrade in early Q2 2025. In accordance with our usual network upgrade release schedule, TestNet will be upgraded first, closely followed by MainNet.

VOR on Puppynet

Following in the footsteps of OoO and at the request of developers, we’ll be deploying VOR on Shibarium Puppynet, allowing developers to fully test their VOR enabled projects before deploying on mainnet. As with OoO, xFUND will need to be minted on Sepolia and bridged to Puppynet.

In the Pipeline

Payment Streams module

As far as Unification mainchain goes, this will be seamless — there will be no noticeable changes to MainNet, and the module will function as it does currently.

We’re currently researching the requirements for this.

Web Wallet Makeover

As mentioned in our previous Developer Update, we’re still in the early R&D stage regarding the Web Wallet makeover. The Web Wallet has so much potential going forward, and certainly deserves some TLC!

Outro

A huge thank you to everyone involved in the UNoDE Phase 2 alpha testing — we’re looking forward to finalising Phase 2 and deploying it for the public beta! We have some interesting times ahead with the development of the Developer Portal and we’re looking forward to releasing what we hope will become a super useful tool for all developers wishing to build in the Unification ecosystem.

Important Links

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

Unification Developer Update — December 2024 was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Guide to FUND Payment Streams

Codegnosis — Wed, 09 Oct 2024 09:16:29 GMT

Payment streams allow users to send FUND to a receiving wallet, spread over a desired period of time. In this article, we’ll cover what they are, and how to use them — both via the new Web UI, and the und binary.

A stream comprises four main elements: a sender who initiates a stream, a receiver wallet to which FUND will be sent, a flow rate and a deposit to cover the desired time period. Flow rates are calculated as a flow of the lowest denomination of a token per second. For example, for FUND, this would be a flow of nund per second.

Once a stream is set up, it is the responsibility of the receiver to “claim” (withdraw) payments, which are calculated as per the specified flow rate at the point of the claim.

Streams will continue until either the deposited amount runs out, or the stream creator (the sender) cancels the stream. Flow rates can be adjusted and deposit amounts increased at any time by the sender.

The Payment Streams module also emits several events which can be queried via gRPC/REST endpoints, or subscribed to via websockets. A more in-depth developer specific article will be published in the near future, containing code examples.

Use Cases

A non-exhaustive list of example use cases for Payment Streams includes:

Subscriptions: a subscription service costs 100 FUND per month — a user can set up a payment stream with a flow rate of approx. 38051 nund/sec, and a deposit of 1,200 FUND to cover 1 year of payments.
Streaming Services: Streaming payments allow users to automate recurring payments for subscription-based services, such as media streaming platforms or software-as-a-service (SaaS) models. Instead of making a lump-sum payment each month, users can set up a stream that continuously delivers small amounts (down to the minute) to the service provider, ensuring uninterrupted access.
Payment for work: payment streams could also be used for a pre-agreed payment for a project. For example, two parties agree that a project will be completed in 1 week for 5,000 FUND. The client sets up the stream, and the contractor begins work. Half way through, work stops for some reason and the client therefore cancels the stream. The payment stream ensures that 1) the work to date gets paid for, and 2) the client can get a refund for the unfinished work.
Grants, Crowdfunding & Community Funds: Streaming payments can be used in crowdfunding campaigns, where donors can commit to ongoing support for a project or initiative. This enables a steady flow of funds rather than one-time donations, offering projects a continuous revenue stream & also accountability for the duration
Token Vesting: Streaming payments are especially useful for token vesting in blockchain projects. Teams and early investors can receive their tokens gradually over time, aligning their long-term incentives with the project’s success. This prevents large, one-time releases of tokens that could disrupt the market, ensuring a smooth and fair distribution while rewarding stakeholders progressively.

Payment Streams UI

The Unification Foundation has deployed a fully functional, proof of concept Payment Streams UI for MainNet at streams.unification.io. It works out of the box with a variety of established wallets such as Keplr, Leap and Cosmostation. The UI implements the new fundjs and fundjs-react libraries, in addition to several React libraries developed by the Cosmos community such as cosmos-kit/react and interchain-ui/react.

Using the UI, it’s possible to interact with all the features of the Payment Streams module:

Creating a stream
Modifying a stream
Withdrawing (claiming) from a stream
Cancelling a stream
Querying a stream (current state on-chain)
View the full Tx history for a stream (querying events emitted for a stream)

Creating a Stream

In order to create a new payment stream, you will need a few bits of information:

The receiver wallet address
The amount you want to stream and the frequency
Enough FUND in your wallet to cover the deposit and the transaction fee

In this example, we’re creating a stream for 100 FUND/month. Once the details are entered, the flow rate is automatically calculated and displayed for confirmation

Before broadcasting the transaction, the UI will display the following information:

The receiving wallet address. Note - if the receiving wallet does not yet exist on-chain, a warning will be displayed recommending that some FUND is sent to the address so that it can send claim transactions.
The amount you wish to deposit (this can be modified before sending the transaction)
The calculated flow rate (in both nund/second and FUND/second
The time and date the current deposit amount will run out (effectively ending the stream). This will automatically update if the Deposit amount is modified before sending the transaction, to show the effect of adding more/less deposit.

When the “Create” button is clicked, your selected wallet provider (for example Keplr) will pop up asking you to verify, sign and broadcast the transaction.

If successful, the UI will display the transaction hash with a link to the block explorer.

Behind the scenes, the Payment Streams module will emit a number of useful events in the on-chain transaction, which can be used by developers to capture and process data (for example, a websocket listening for Stream events in order to update their subscription database)

Viewing a Stream (as a Sender)

Once created, the UI will automatically update with the new stream information, which can be accessed via the “As Sender” tab

Each stream entry in the list contains all pertinent information regarding the stream, including:

The Receiver wallet address (linked to the block explorer)
The current flow rate
The remaining deposit in the stream
The date and time the current deposit amount will reach zero
The date and time of the last claim made by the receiver
A real-time update of the current amount the receiver can claim/withdraw

Viewing the stream as a sender displays a number of action buttons which the sender can undertake. These are covered in the relevant sections below.

Viewing a Stream (as a Receiver)

As a Receiver, the data shown is identical to that of a sender. The only difference is the action buttons — only the Tx History and Claim buttons are available to the receiver.

View Tx History (both)

Clicking the “Tx History” button will open a modal listing the complete transaction history for the stream. This includes transactions broadcast by both the sender and the receiver.

Modifying a Stream (sender)

The sender can modify the stream in two ways — topping up the deposit, or adjusting the flow rate.

Top up the Deposit

A sender may wish to top up the deposit to, for example, renew or extend a subscription. If the deposit zero time is close, a subscription service may send a reminder to a user that the subscription is about to expire. The user may then add more FUND to the stream in order to extend or renew the subscription.

Once the “Top Up Deposit” button is clicked, a dialog will appear allowing the user to enter the amount of FUND they wish to add to the stream. Clicking “Send” will prompt the wallet provider to ask the user to verify/sign and broadcast the Tx. The only requirements are that the sender wallet has enough FUND to cover the addition, and the tx fee.

If successful, the deposit zero time will be updated, and relevant events will be emitted by the blockchain.

Modify the Flow Rate

A sender may wish to modify the flow rate of a stream if, for example, they are moving to a different subscription tier to a particular service.

Clicking the “Update Flow Rate” button will open a dialog prompting the user to enter the new details.

The new flow rate will be calculated based on this data, and a new dialog will appear asking the user to confirm.

This dialog will contain the new flow rate information, as well as a notice that the current claimable amount at the current flow rate will automatically be sent to the receiver before the flow rate is applied on-chain.

Cancelling a Stream (sender)

A sender can cancel a stream at any time. This will open a dialog asking the user to confirm, and display information about the cancellation process.

Cancelling a stream will have the following effects:

The claimable amount at the block time the cancellation transaction is processed will be sent to the receiver.
Any remaining deposit held in the stream will be refunded to the sender.
The stream will be deleted from the blockchain state

Claiming/Withdrawing from a Stream (receiver)

A receiver can withdraw the current claimable amount at any time during the lifetime of a stream. This can be done as frequently as desired, or even only once the stream has ended (the deposit zero time is reached).

Clicking the “Claim” button will open a dialog showing:

The total amount currently claimable
The actual amount you will receive
The amount that will be sent to validators. This is currently a flat fee of 1% of the total claimable amount in this transaction. The fee can be modified via Governance.

The full source code of the UI is available in our Github repositories.

und CLI

The undbinary (>= v1.10.1) can also be used to create and manage Payment Streams, and a number of commands are available to facilitate this.

Installation

The und binary is available for Linux, Mac OS and Windows, and is available here.

Once downloaded, install in a directory known by $PATH, for example on Linux in $HOME/bin, or globally in /usr/local/bin. Ensure the installed version is kept up to date.

Create a Stream

Similarly to the UI, in order to create a stream we need a few pieces of information — the receiver wallet, the flow rate, and the deposit.

Calculating the Flow Rate

The Flow rate can be calculated manually, or automatically using the und binary.

Manually

First, we’ll need to convert the amount being sent in FUND to nund. This is simply FUND*10^9, for example, 100 FUND = 100,000,000,000 nund,

Next, we calculate the flow rate using the formula:

Flow Rate = nund/ total seconds

For example, if we’re sending 100 FUND/month, then the total seconds is (365/12) * 24 * 60 * 60.

Flow Rate = 100000000000 / ((365/12) * 24 * 60 * 60) = 38051

(rounded down from 38051.75)

Our flow rate is 38051.

Automatically

Two commands can be used to help automatically calculate the flow rate:

Convert FUND to nund:

und convert 100 fund nund

Calculate the Flow rate:

und query stream calculate_flow \
 --coin 100000000000nund \
 --period month \
 --duration 1

This will return the flow rate of 38051.

Once we have this information, the stream can be created using the command:

und tx stream create [RECEIVER_ADDRESS] [DEPOSIT_AMOUNT] [FLOW_RATE]

For example:

und tx stream create und123…abc 1000000000000nund 38051 \
 --node https://rpc.unification.io:443 \
 --chain-id FUND-MainNet-2 \
 --gas auto \
 --gas-adjustment 1.5 \
 --gas-prices 25.0nund \
 --from SENDER_WALLET

Modify a Stream

Top Up Deposit

Topping up a deposit is simple, and requires the sender wallet to execute the following command:

und tx stream topup [RECEIVER_ADDRESS] [DEPOSIT_AMOUNT]

For example:

und tx stream topup und123…abc 1000000000000nund \
 --node https://rpc.unification.io:443 \
 --chain-id FUND-MAinNet-2 \
 --gas auto \
 --gas-adjustment 1.5 \
 --gas-prices 25.0nund \
 --from SENDER_WALLET

Update Flow Rate

The flow rate can be updated at any time during an active stream. The sender may modify the flow rate if, for example, they wish to move on to a higher (or lower) subscription tier on the service they are paying for.

Two important things happen when a flow rate is updated:

1. Any unclaimed payments are calculated at the current flow rate and sent to the receiver wallet (with validator fees also calculated and sent if applicable)

2. The deposit zero time is recalculated based on the new flow rate.

The following command can be executed to update a flow rate:

und tx stream update-flow [RECEIVER_ADDRESS] [NEW_FLOW_RATE]

For example, the Sender wants to move onto a higher subscription tier, which costs 150 FUND/month. The new flow rate is therefore 57077 nund/sec:

150000000000 / ((365/12) * 24 * 60 * 60) = 57077

(rounded down from 57077.62)

The command to run is:

und tx stream update-flow und123…abc 57077 \
 --node https://rpc.unification.io:443 \
 --chain-id FUND-MainNet-2 \
 --gas auto \
 --gas-adjustment 1.5 \
 --gas-prices 25.0nund \
 --from SENDER_WALLET

Cancel a Stream

A sender can cancel a stream at any time. When a stream is cancelled, any unclaimed payment up to the time of the

cancellation is calculated and sent to the receiver. Any remaining deposit, if any, is returned to the sender’s wallet.

The following command can be executed to cancel a stream:

und tx stream cancel [RECEIVER_ADDRESS]

For example:

und tx stream cancel und123…abc \
 --node https://rpc.unification.io:443 \
 --chain-id FUND-MainNet-2 \
 --gas auto \
 --gas-adjustment 1.5 \
 --gas-prices 25.0nund \
 --from SENDER_WALLET

Claim/Withdraw from a Stream

A receiver can run the claim command at any time:

und tx stream claim [SENDER_ADDRESS]

For example:

und tx stream claim und456…def \
 --node https://rpc.unification.io:443 \
 --chain-id FUND-MainNet-2 \
 --gas auto \
 --gas-adjustment 1.5 \
 --gas-prices 25.0nund \
 --from RECEIVER_WALLET

Query a Stream

A stream can be queried with the following command:

und query stream stream [RECEIVER_ADDRESS] [SENDER_ADDRESS]

For example:

und query stream stream und123…abc und456…def \
 --node https://rpc.unification.io:443 \
 --chain-id FUND-MainNet-2

The data returned will be similar to that displayed in the UI, but without the real-time claimable amount.

Programmatically with Msgs, RPC, gRPC and REST

A separate article will be released covering programmatic use, and how to integrate fundjs into an application and utilise Msgs over RPC in order to facilitate this.

Outro

As Unification advances its ecosystem, the power of streaming payments becomes a vital tool for transforming blockchain utility and enhancing real-time financial interactions. By integrating streaming payments into the Unification and the Cosmos ecosystems, users can take advantage of real-time, transparent financial transactions.

Beyond traditional use cases like subscriptions and payroll, streaming payments open the door for new applications such as continuous micro-loan repayments, real-time rent payments, and even dynamic in-game economies.

Additionally, token vesting, infrastructure resource sharing, and decentralised collaboration through DAOs benefit from the flexibility and efficiency that streaming payments offer. As these use cases expand, streaming payments will play a critical role in enhancing the utility and scalability of blockchain technology, creating more dynamic and efficient decentralised financial systems.

Important Links

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

A Guide to FUND Payment Streams was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unification Developer Update — September 2024

Codegnosis — Mon, 09 Sep 2024 13:52:08 GMT

Unification Developer Update — September 2024

Hot on the tail of our last update, we’re pleased to announce the successful MainNet upgrade which includes the deployment of our new Payment Streams module. We’ve also made incredible progress on UNoDE Phase 2. There’re also a fair amount of other items to cover this time, including progress on the partnerships mentioned in our previous Developer Update article and a number of other features in the pipeline for development.

Dev Work to Date

MainNet Upgrade

FUND MainNet was successfully upgraded at 12:11:59 UTC on 29th August 2024 at block height 12,210,000. It took around 3 minutes for ⅔ validator power to complete the upgrade and continue producing blocks, with the vast majority of the remaining validator power coming online within 5 minutes of the target upgrade block. Once again, a huge thank you to our highly valued validators who continue to be consummate operators! You’re all fantastic, and we’re lucky to have such a brilliant validator community.

The network is now running undv1.10.x (codenamed pike), which is built on Cosmos SDK v0.47.x, and implements IBC v7.7.0. Noticeably, Cosmos SDK v0.47.x marks the first major migration to the new CometBFT, replacing Tendermint as the consensus layer for all Cosmos based chains.

In addition to the new Payment Streams module developed by the Unification Foundation (see below), the upgrade also integrates the consensus and group Cosmos modules.

Additionally, the upgrade unfreezes the BitForex wallet, enabling movement of FUND stored there on the Unification Blockchain. (Although Unification is not affiliated in any way with Bitforex, we have reached out to the team to offer aid for any further assistance needed to enable/expedite what’s needed on their side, and will update our community once there’s been an update)

Payment Streams

We’re proud to announce that the new Payment Streams module is now deployed and running on MainNet! Inspired by Superfluid’s Money Streaming, the module allows any user to set up a payment stream between a sending wallet and a receiving wallet. Streams are initialised such that payments are calculated as “tokens per second”, using the lowest denomination of the tokens (for example, nund for FUND payments). This means that in addition to the standard method for transferring, say, 100 FUND to a user, it will also be possible to send 100 FUND over the course of a specified amount of time (for example 100 FUND per month), and modify the amount/frequency at any time.

Withdrawals can be executed by the receiver at any time during the stream’s active lifetime, with the amount received being calculated from the point of either the last withdrawal time, or the time of stream creation (whichever is the latest).

The sender can modify a stream at any time — increasing/decreasing the flow rate (for example, if they wish to change a subscription payment to a higher/lower tier), and topping up the stream with tokens (for example, to continue paying for a subscription service). Senders may also cancel their stream at any time, at which point the module will calculate and reconcile remaining withdrawals and refunds, forwarding the amounts to the respective wallets.

Additionally, validators can earn fees from all payment streams processed on the chain. The validator fee on MainNet is currently set to 1%. This parameter can be modified via governance.

Payment Streams will be integrated into UNoDE in an upcoming update, thus allowing native FUND to be used to pay for UNoDE subscriptions, and we’re excited to work with our partners to help them utilise native FUND payments.

A more detailed and dedicated article covering all aspects of Payment Streams is forthcoming, and both end-user and developer documentation will be published here.

Block Explorer Update

Our block explorer has been updated to use the latest upstream changes from the ping.pub repository. This has been rolled out to both TestNet and MainNet, with some modifications to accommodate and display the Payment Streams parameters.

The updates include an upstream fix for the IBC connection and channel statuses, which are now displayed correctly — https://explorer.unification.io/u/ibc/connection/connection-1.

Internal Services Migrated to UNoDE

We continue to migrate many of both our in-house and public services to utilise UNoDE RPCs to communicate with their respective chains. So far, the following have been successfully migrated from Alchemy/Infura to UNoDE:

OoO Ethereum mainnet
OoO Shibarium
VOR Ethereum mainnet
VOR Shibarium

Services planned for migration include the Block Explorer (MainNet), and our public MainNet REST/RPC interfaces. We anticipate these to be seamless.

WIP

fundjs

Currently in development is a new Javacript library for Unification Mainchain. The new fundjs SDK is built using Telescope — a Typescript transpiler for Cosmos protobufs. This new standardised library will include bindings for all Cosmos SDK modules, IBC applications and our custom Mainchain modules and will be available via the NPM package manager. This will be released along with fundjs-react, which also includes React hooks.

Developers familiar with existing SDKs such as cosmjs and osmojs will easily be able to use fundjs in their Cosmos based Web3 applications, allowing them to implement the new Payment Streams module, in addition to integrating any other Mainchain module.

A repository containing examples - including a simple React & Keplr UI for Payment Streams - is also in the works, and progress can be tracked on Github.

QOM Network Partnership

We’re excited to be working with QOM Network, an EVMOS & Cosmos SDK based L1 network and DEX. We are working closely with their development team to bridge xFUND to the QOM Network, and this will be closely followed by deploying both VOR and OoO on QOM, making it the first chain in the Cosmos ecosystem to be supported by the platforms.

Further, we are planning on integrating the QOM Swap DEX into OoO as data source for AdHoc price queries, making it the first Cosmos based DEX to be supported as a data source by the platform.

VOR Integration Partnership

We have been approached to partner and work on elements of VOR for multi-chain integration on an exciting new Blockchain project building a large community around NFT & Real World Assets.

The project (still in stealth) will use VOR on Ethereum mainnet as a primary engine and the team has committed to xFUND purchase through its initial stage. We look forward to sharing more once the project is live/out of stealth in the upcoming months.

Mainchain Cosmos SDK/IBC Upgrade

Work on the next mainchain upgrade has begun. Codenamed scanlan, it will implement the Cosmos SDK v0.50.x and IBC v8.4.x releases. In accordance with our usual mainchain release schedule, we aim to deploy this around the beginning to middle of Q2 2025.

UNoDE Phase 2

An enormous amount of progress has been made on UNoDE Phase 2, and we’re really excited to be so close to inviting alpha users to test! We still have some final development and internal testing to undertake, but we’re hoping that in the next few weeks we’ll be able to start sending out invites to alpha testers. If you’re interested in becoming an alpha tester, please get in touch — we’re specifically looking for experienced node operators at this stage (with the intention of making the integration process accessible to all levels of operator experience).

We have covered Phase 2 extensively in the past, but briefly for the sake of brevity, it will allow any node operator to add potentially any blockchain network RPC node they control/operate to the UNoDE backend in order to serve data requests via the end-user API. Any successful requests served by their nodes will receive a percentage payment from UNoDE subscriptions. This means, for example, that an Osmosis RPC node operator can add their node to the UNoDE family, and get paid for serving data requests.

Work completed so far includes:

Node Operator UI, allowing operators to add new RPC nodes to the UNoDE network (currently both Cosmos SDK and JSON-RPC/EVM compatible chains), and manage existing nodes
Routing API, allowing third party nodes to be utilised by the UNoDE network
Verification scripts — to be run by operators to verify ownership/validity of their node(s)

The final pieces of Phase 2 currently being worked on and near completion include:

Payment calculation for successful requests to third party nodes
Penalty calculation for poor performance
Payment distribution method.
Subscription payments in native FUND using Payment Streams (using fundjs)

We’re really looking forward to working with node operators during alpha testing.

In the Pipeline

Web Wallet Makeover

We’re still in the early decision stage at this time, but we intend to give Web Wallet a makeover, following the recent updates required to ensure its Manifest v3 compliance. Some possibilities under review include:

Port from Vue to React
Migrating from und-js-v2 to fundjs
Integrate Payment Streams management
IBC integration
Local, internal encrypted storage of transaction history (similar to Metamask)
Multiple wallet management and local encrypted storage of the wallet seed (similar to Metamask), and phasing out of JSON file based wallets

These are mid- to long-term plans which will take a while to come to fruition while we prioritise more immediate projects.

Outro

We’ve accomplished a lot as a community in the past couple of months — the MainNet upgrade, UNoDE Phase 2 progress and our new partnership developments. We’re looking forward to the work ahead, the interesting challenges involved and to inviting our alpha testers to UNoDE Phase 2. Once again, a huge thank you to all our validators — your continued support and professionalism is greatly appreciated!

Important Links

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

Unification Developer Update — September 2024 was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unification Developer Update — July 2024

Codegnosis — Tue, 16 Jul 2024 09:13:26 GMT

Unification Developer Update — July 2024

It’s been a hectic year so far — it’s hard to believe we’re more than half way through already. A lot has been happening at Unification regarding development, and there is still a lot of ongoing development to keep us busy! UNoDE Phase 1 is live, and Phase 2 has moved from research into active development, and we have also been working on OoO and VOR. We’re also developing some major updates to mainchain (in addition to the Cosmos SDK and IBC upgrades).

Dev Work to Date

UNoDE Phase 1

UNoDE Phase 1 has been deployed and live for a number of months, and we have started migrating Unification’s various applications and services to UNoDE. Both the Ethereum mainnet and Shibarium deployments of the OoO application now use UNoDE RPC nodes for interaction with the Router smart contract, as does our VOR deployment on Ethereum mainnet (and so will the VOR deployment on Shibarium).

Further, we are also working on migrating our public Unification RPC, REST and gRPC nodes over to UNoDE and there will be an official announcement once this is complete.

OoO Updates

We have made a number of significant improvements to OoO — specifically to AdHoc querying, which allows querying price data for pairs on a number of supported DEXs without needing them to be integrated into the Finchains API. Additionally, we have migrated the OoO application’s dependency on thegraph.com’s hosted/free subgraphs to the more reliable paid (GRT) subgraph service. This migration brings many benefits to both OoO’s AdHoc querying, and to the Dex Verification tool, as outlined below.

AdHoc Querying improvements

Previous versions of the OoO application kept an internal database of supported DEX pairs by querying the top 1000 pairs from each supported DEX’s subgraph every 24 hours. For the most part this has worked well, but we felt the whole process could be improved and extended, and we therefore created the DEX Pair Verification Tool. OoO’s supported DEX pair import process has been migrated to this tool, which will allow additional manual verification of tokens and pairs using a number of metrics acquired from both the DEX’s subgraph and Coin Gecko. From this, we can export a curated set of pairs which the OoO application imports and uses to serve AdHoc price data requests. This allows us to exclude potentially fake tokens, and also pairs which may have recently slipped into low liquidity — both of which could affect price data.

Further, the tool will eventually allow us to create and implement tags and associations between tokens allowing for a more sophisticated AdHoc querying tool.

For example, by associating USDC, USDT and DAI, and tagging them as “USD” and also ETH/WETH as ETH, AdHoc queries for USD-ETH price data will be able to include all pairs using USDC, USDT, DAI, WETH and ETH.

Subgraph migration

With The Graph Network having completed its migration from the free hosted subgraphs to the paid GRT subgraphs, we have also implemented paid subgraphs for OoO’s AdHoc querying.

This allows for much faster and more reliable subgraph queries from incentivised providers, and is a great improvement in performance when serving AdHoc data requests. The older free hosted subgraphs are still supported in the OoO application, but will be deprecated in a future release.

Note: The cost of querying the GRT based subgraphs is negligible, and should therefore currently have zero impact on the xFUND cost of querying OoO for data.

FUND ERC-20 Bridged to Shibarium L2

The FUND ERC-20 token has been deployed and bridged to Shibarium L2–0xaDA0fA1f9A4Ea8513B3b607EFD31792336c09507, proudly joining its sibling token, xFUND. This will allow FUND to be sent from Ethereum mainnet over to Shibarium L2 to be utilised, and we’re excited to see what the community comes up with!

The official Shib announcement and article can be read here.

VOR Deployed on Shibarium Mainnet

The VOR smart contracts have been deployed on Shibarium!

VORCoordinator: 0xc6b24F8241C52531B376Ebe96737e167b923b1A7

BlockHashStore: 0xa8fd75Ff305F0FBf59f50afB4f6290FdB22F0430

The Unification Foundation’s VOR provider details can be found in the docs.

This takes us another step on the path to multi-chain deployment for both VOR and OoO.

WIP

UNoDE Phase 2

For the last couple of months, we have been researching the best implementation methods for UNoDE Phase 2, and development has started on the current proposed solution. Phase 2 will allow third party RPC node operators to join the UNoDE network and earn a share of UNoDE’s revenue, based on performance and data requests successfully served.

The four major features currently being developed are:

Plug in existing nodes into UNoDE. This allows node operators who have existing, established RPC nodes to join UNoDE, and potentially earn income. These nodes are not restricted to the current networks supported in Phase 1 (Ethereum, Shibarium and Unification). For example, an Osmosis RPC node operator should be able to plug their node into UNoDE’s API allowing it to be offered as an RPC endpoint to UNoDE users.

Deploy a new RPC Node. Using tools developed by us, third party operators will be able to deploy new RPC nodes, and have them seamlessly plugged into the UNoDE API. This is likely to be Phase “2.5”

Node Health/Data Integrity Monitoring API. The API will allow UNoDE’s backend to monitor the health of third party RPC nodes, in order for the end-user API to correctly route requests to the healthy nodes. The API will also randomly check data integrity of third party nodes.

Revenue Sharing and Penalties. Revenue will be calculated based on performance, and the number of queries successfully served, with penalties deducted from earnings for low performing nodes (for example, very slow responding to queries, or timing out etc.)

We will contact our previous alpha testers soon with details on how they can join and help testing.

Mainchain

Cosmos SDK / IBC Upgrade

Work is almost complete on the mainchain upgrade to Cosmos SDK v0.47.x and IBC v7.5.x. This is a major SDK upgrade, since it is the first step in the full Cosmos SDK migration from Tendermint to CometBFT, and has involved a huge amount of work ensuring all code and modules have been correctly migrated.

Payment Stream module

We have been developing a new module for mainchain, which will allow any user to set up a payment stream to a receiver wallet. Automated subscriptions are notoriously difficult to implement on-chain, and the payment stream module allows an efficient alternative to the traditional subscription model.

We believe this will be the first of its kind in active development on any Cosmos/IBC environment and will be adaptable by the rest of the Cosmos community to increase utility overall.

A payment stream can be initialised by a sender wallet with a simple process. The stream is created with an initial deposit amount, and a specified flow rate at which the receiver will be paid. Once created, the stream can be topped up, and the flow rate modified.

The concept is relatively simple. For example, a user wishes to send 100 FUND/month for 2 months to a specified receiver. They would set up a new payment stream with a deposit of 200 FUND, and a flow rate of approx 38051nund/s (flow rates are per second). The receiver can claim and withdraw at any time during the stream, and the module will calculate — based on the flow rate — how much they are currently entitled to. For this example, if the receiver claims after 1 week, they will be able to withdraw approx. 25 FUND.

If the sender cancels the stream, any unclaimed payment the receiver is entitled to will automatically be sent, with the remaining deposit returned to the sender’s wallet. Similarly, any modification to an existing stream’s flow rate will trigger unclaimed payment (at the old flow rate), before calculating future payments based on the updated flow rate.

Developers will be able to subscribe to on-chain events in order to monitor for new payment streams, and any modifications or cancellations to existing payment streams.

Once deployed on MainNet, we will be integrating the Payment Stream module into UNoDE’s subscriptions to allow them to be paid in native FUND.

Both the Cosmos/IBC upgrades and the Payment Stream module are currently in the testing phase. As usual, we will be upgrading TestNet first, monitoring for a couple of weeks, and then upgrading MainNet. The tentative target for the TestNet upgrade is towards the end of July, meaning MainNet will hopefully be upgraded towards the end of August. Dates are TBD, and will be announced via the usual channels on Telegram and Discord.

In the Pipeline

VOR Partnerships

We also have some very exciting and interesting progress being made with VOR and its utility. We are currently working with two separate and rather brilliant projects — neither of which we are at liberty to discuss in detail at the moment, but suffice it to say that one project relates to deployment of VOR on a new Cosmos EVM blockchain, and the other relates to VOR being used in a smart contract deployed across several networks.

We look forward to sharing the information on both these projects with the community as soon as publicly available

Outro

There’s a lot to digest there! We’re proud of the progress made so far, and are really excited to see how the community will utilise FUND on Shibarium. We’re also looking forward to rolling out our Payment Stream module to mainchain, and seeing it in action in UNoDE subscriptions. We are incredibly excited to roll out UNoDE Phase 2 and can’t wait to invite our alpha testers to join the network!

Finally, we’re really looking forward to revealing the partnerships for VOR and other tools in the near future.

Important Links

Discord: https://discord.com/channels/725618617525207042

Documentation: https://docs.unification.io

Unification Developer Update — July 2024 was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

UNoDE Public Beta & Beyond

Codegnosis — Thu, 09 May 2024 13:13:11 GMT

The UNoDE Phase 1 public beta is live! We’re still doing some last minute optimisations and tweaks, but everything is ready.

What to expect

Pretty much everything that has been previously outlined for Phase 1:

RPC Nodes as a Service, initially supporting:

Ethereum mainnet
Shibarium mainnet
Unification MainNet
Potentially more networks, depending on demand

2. Anonymity — no mandatory email address or names for end-users during registration. No logging — unless explicitly enabled by you, the user, for purposes of, for example, resolving issues and debugging. Logs are transitory and wiped when logging is disabled and no longer required.

3. Crypto payments with special offers and bonuses for FUND payments

What NOT to expect

Perfection. Whilst we have endeavoured to find/fix bugs and optimise the platform, it’s still a beta, so there will be issues that were not picked up during our smaller scale alpha testing. Bugs are an inevitability with software, and the wider scale public beta will help us catch and kill anything we missed, overlooked or were not even aware of during alpha testing. This is, of course, all a part of a large scale changes required as we move into Phase 2.

Since this is a beta, we will be offering bug bounties. Details to follow.

What next?

In parallel with bug fixing and optimising Phase 1 during the public beta, we will soon be starting planning and development for UNoDE Phase 2 — beginning the SaaS chapter of UNoDE.

With Phase 2, we aim to develop tools to allow potential operators to spin up their own RPC infrastructure and join the UNoDE family. Along with revenue sharing, this will help propel UNoDE into becoming a truly decentralised NaaS platform unlike any existing options today.

Phase 2 outline

Phase 2 of the UNoDE project aims to focus on implementing the SaaS (software as a service) aspect, in order to provide a decentralised network of NaaS RPC nodes.

UNoDE aims to offer a suite of scripts and tools allowing potential third party UNoDE Operators to deploy their own RPC nodes and connect them to the UNoDE API.

The UNoDE backend will maintain a list of “healthy” third party nodes, allowing the end-user API to route requests to these nodes. We aim to have these requests be load balanced, and also routed based on IP geo-location to reduce potential network latency incurred by third party nodes being situated in a different physical location.

The UNoDE backend also aims to maintain a history of the number of requests successfully routed to and served by third party nodes, so that some of the revenue earned from UNoDE subscriptions can be shared with third party UNoDE Operators.

What does all this mean? For the vast majority of end-users (developers, traders etc.), this should be a seamless implementation, and no changes should be required on their part. Existing API keys will remain the same, so the transition should be smooth.

For potential Node Operators, there will be some new sections in the UNoDE UI, allowing the generation of a new API key which is used specifically for registering their RPC nodes to the UNoDE network. Additionally, Node Operators should have access to a new area of the UI giving an overview of their nodes and data such as health status, number of requests served, and their current share of revenue, history etc.

We will be reaching out to our existing alpha testers during Phase 2 development, and will also eventually open up registration for new alpha testers.

True network decentralisation — including revenue sharing, and sustained growth together — has been the bastion pillar of Unification and will continue to a much deeper chapter as we expand our development into the next phase of UNoDE. We look forward to having you join us as users, supporters, developers & operators into the next chapter.

https://unification.com/unode

https://unode.unification.io

Important Links

Discord: https://discord.com/channels/725618617525207042

UNoDE Public Beta & Beyond was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unification Update — March 2024 United for Action

Unification Foundation — Mon, 11 Mar 2024 09:58:44 GMT

Unification Update — March 2024
United for Action

The unstoppable engine of OoO3, UNoDE, and community that is Unification.

The last two weeks have showcased the power of decentralized community collaboration in ways unseen in the blockchain community.

After discovering the compromise of one of the exchanges which listed the FUND token, the community came together to determine the most appropriate decision to essentially lock those FUNDs (until/unless there are appropriate actions by representative entities), protecting the community across including holders, delegators, and validators.

To determine, vote, and execute on the best actions in a decentralized fashion in this time is an unprecedented event giving life and showing the power of Unification.

Expedited MainNet Network Upgrade

Unification MainNet was successfully upgraded on 7th March 2024, 11:19 UTC at block 9,577,300 to und v1.9.0. The update — codenamed 4-percival — was an expedited hotfix to address the community-wide concerns surrounding the recent sudden disappearance of Bitforex’s online presence and the associated alleged suspicious hot wallet outflows across multiple blockchain networks (not Unification) worth approximately $56,000,000. With the upgrade was bundled the Cosmos SDK patch to v0.46.16.

Our Validators came together with us in an extraordinary call-to-arms collaborative brainstorming session to discuss the various options available, and potential solutions to address the issue — specifically regarding the 3,000,000 FUND held by the wallet address on MainNet identified as Bitforex’s hot wallet. Of the many potential solutions and opinions offered over several hours of amicable discussion, the Validator community agreed upon the following actions, deeming them to be the fairest and most practical under the circumstances:

All known IBC relayers to both Gravity Bridge and Osmosis were to be shut down immediately in order to greatly reduce the possibility of the FUND held in the wallet in question being transferred off MainNet. This had the side effect of preventing all wallets transferring via IBC, but since it was a temporary solution until the upgrade could be rolled out across the network, this was agreed to be acceptable.
The identified wallet would effectively be frozen on-chain and prevented from executing any kind of transactions on MainNet — including, but not limited to Bank (Send), IBC, Governance and Staking related transactions.

The underlying priorities for the solution was that it should be safe and fair to all Unification users but also be transient, such that should the Bitforex situation be resolved satisfactorily, the MainNet solution can easily be reversed via Governance.

Credit goes to Chainmasters for suggesting the solution to use the BeginBlock method to block the wallet address, which ultimately evolved through mutual discussion into the development of an AnteHandler Decorator to specifically handle freezing the wallet in question. The solution checks all messages in an incoming transaction along with the transaction signature itself to see if any of the message/transaction signers match the wallet being frozen. If found, the entire transaction is rejected with an error message.

The code was written and committed to GitHub, then double checked and verified by the Validator community. Once the code was verified and agreed upon, Governance proposal 21 was submitted, with the vast majority of validator and delegator power voting well before the voting period ended. Votes were unanimously “Yes”.

Due to the sensitive nature and rapid rollout requirement of the upgrade, the usual 7 day period between vote ending and the upgrade block was reduced to 24 hours. The usual TestNet upgrade which has always been executed prior to MainNet upgrades was also skipped in order to deploy the solution as soon as possible (TestNet will be upgraded to the same und version presently).

All known IBC Relayers were immediately re-activated soon after the upgrade rolled out, allowing users to resume IBC transfers to Gravity Bridge and Osmosis.

The whole process was once again testament to our fantastic Validators & community pulling together to collaborate and speedily solve issues not just as a community, but as a family! Thank you all for your valued input and speedy action putting the solution in place!

UNoDE

In addition to these updates, the foundation and community are still hard at work at finalizing for the public beta release of UNoDE.

Since we’ve last spoken, several large partners have expressed interest in offering UNoDE on behalf of their community/blockchain networks, necessitating the need for much larger scale testing than previously intended.

Although this may require some additional time as it requires much larger load/stress testing of the platform, it also opens up much larger possible doors for all larger partners to offer UNoDE’s benefits to their community and expands the original vision and potential.

In addition/relation, we’ve listened to the community’s feedback and added the option of payments through multiple other tokens, including Ethereum, Shib, & Bone (among many others), while still reserving special pricing and benefits to users who choose to use the service through FUND.

Private beta testing still continues and we look forward to sharing a public beta with all soon.

Future of Oracle of Oracles: Coming out of the Shadow

In addition to the current work, it’s important to note that planning of the next version of Oracle of Oracles (OoO3) is currently underway, in collaboration with a team focusing on AI optimization of the next version. We look forward to releasing more info about OoO3 and additional future utility of xFUND within the toolkit with you in the coming months.

Unification Update — March 2024 United for Action was originally published in Unification Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leap Wallet x Unification Integration

Ringoshi Tōitsu — Wed, 07 Feb 2024 07:57:21 GMT

Stake, Transact, Vote with $FUND on Leap. (PC, Android, iOS)

LEAP x UNIFICATION

Download Leap Wallet:

1. Go to the Leap Wallet Website:

Visit the Leap Wallet website or app store on your device (Google Play Store, Apple App Store, etc.) Search ‘Leap Wallet’ on App Store.

https://www.leapwallet.io/download

2. Download and Install:

Find the Leap Wallet app and download/install it on your device.

Add Unification Chain to Leap Wallet:

3. Open Leap Wallet:

Launch the Leap Wallet app on your device.

4. Access Chain Store:

Locate the ‘Browser’ option on Mobile and go to the link below to seamlessly add Unification to your app. If you’re on PC just click the url.

https://developers.leapwallet.io/chain-store

5. Confirm Addition:

Follow the prompts to confirm/approve to add Unification’s chain to your Leap Wallet.

Transferring Funds:

6. Access Wallet Balance:

Go to your Leap Wallet dashboard or wallet section to view your balances.

9. Choose Unification Chain:

Select Unification’s chain from the available options within your wallet as shown in picture below.

This button allows you to change which chain you display.

10. Transfer Funds:

Look for a “Send” or “Transfer” option within the Unification chain’s wallet section.
Enter the recipient’s address and the amount you want to send.
Follow the instructions to complete the transfer.

Send / receive FUND on Mainnet using these buttons.

Staking and Voting on Proposals:

11. Access Staking Section:

Find the staking section within Unification’s chain on Leap Wallet.

Stake FUND to a Validator using this button.

12. Delegate/Stake Tokens:

Choose the option to ‘STAKE’.

Choose a Validator (Ringoshi for Example)

Enter the amount you wish to stake and confirm the action.

13. Voting on Proposals:

Explore the governance or proposals section within Unification’s chain on Leap Wallet.

Review available proposals and their details.
Use the voting feature to cast your vote on the desired proposal.

Note:

The steps might slightly vary based on the interface and updates to the Leap Wallet app.
Always review transaction details before confirming to ensure accuracy.

Bridge FUND from Mainnet to Ethereum:

Navigate to the ‘Browser’ option within Leap Wallet.
Proceed to the URL below.

https://bridge.blockscape.network/

Follow the original bridging instructions provided by the Foundation below.

https://medium.com/unificationfoundation/wfund-bridge-access-use-grow-evolve-54adb2aabf70

When connecting LEAP to Gravity Bridge, you’re able to use the ‘connect KEPLR’ option as normal.

Important Links