Beam Payment Protocol by Content Fly

Beam, a new Streaming Payment protocol with trustless escrow payment enables creators to receive a continuous stream of payment each minute in real time once a job starts instead of lump-sum payment.

Comment

Inspiration

Why should workers have to wait to be paid for their time, only after all their time has been spent?

Problem
Workers are forever in debt of time spent working, in Work Now & Paid Later type arrangements. Workers are used like credit cards, with employers (buyers) benefiting through real-time work production, an interest-free period and then paying days or weeks later.

The buyer also heavily benefits from a cash flow and interest earned point of view. This arrangement oozes inequality, however, where there is no history between a buyer and a worker (a low state of trust), it is the safest arrangement for the buyer to avoid losing money paid to a worker that doesn’t produce the work.

But what about the safety of payment for the worker, with the chance that the buyer doesn’t eventually pay for the work produced? These arrangements also cause cashflow inefficiencies in a system, as the velocity of money is reduced, with capital sitting idle until payout instead of being utilised.

The birth of Beam
When sufficient trust is established between a buyer and a worker, the timing and frequency of payment usually become more flexible. However, there is always one party that is either paying more money than the amount of work produced or spending more time working than they’ve been paid for. To achieve a state where the time spent working equals the money paid, payment must be streamed in real time, at a constant rate over the duration of the job performed.

Benefits
Workers paid in real time for the work they produce enables them to utilise that money straight away. As job payment streams in, workers have the ability to stream it straight out again, continuing the stream into various projects, DeFi purchases, savings or investment channels. In a system containing a network of streams between parties, the velocity of money is increased which enables a higher economic output without the need for adding debt to make up the gap between outgoing and incoming payments.

What it does

The Beam Payment Protocol enables creators to be paid in a constant stream over the duration of a job on the Content Fly platform. It is one of two payment options for buyers who have created a job, with the other being a standard lump sum payment, which is only sent once the job has been completed. As the buyer awards a job to a Creator they select the payment type for the job and deposit the payment into the smart contract. Once payment is deposited, it immediately begins streaming to the Creator.

Rather than making a payment to the Creator's wallet each Heartbeat (which is costly), the smart contract adjusts the ownership of the funds inside and unlocks the Creator-owned funds for claiming as they wish.

Both the Buyer and Creator can view the live status of the Beam payment on the "Payment" page of the job as it updates in real-time. The Creator has an additional box showing the amount of live claimable funds and a "Claim" button to send the funds to their wallet.

How we built it

The backend Beam Payment Protocol is developed using Motoko running entirely on Internet Computer. Based on the knowledge we learned from the previous work we did for Content Fly Notifications, Beam utilizes IC Heartbeat to drive the canister to process the active beams. For each beam, it computes the creator’s claimable allocation at that moment of time and calls EscrowPayment canister to update the EscrowContract.

In terms of architecture, we applied a clear separation of roles in which Beam canister’s role is to work out when, how and what to manipulate on the EscrowContract while carrying no ownership of ICP at all. EscrowPayment canister on the other hand carries the main role to have the ownership of ICP tokens deposited by buyers. It requires a much higher level of security measures and asserts a number of invariants to make sure it is solvent in terms of all escrow payments stored for each EscrowContract and its actual ownership of ICP in the ledger.

Challenges we ran into

Payment Streaming (Beam) was an idea we came up with when we started building Content Fly a year ago in August 2021. We had no idea how to implement it or even if it’s possible at all on Internet Computer. While there is sample code on using IC Ledger API, a complete example with Continuous Integration / Continuous Delivery integrated and local testing is lacking. Getting it running locally is crucial for our development, as we can see whether Beam is working with Debug.print.

We understand IC Heartbeat consumes more cycles so we are still monitoring the usage of cycles to find the optimal update rate while not draining the cycles too much.

Accomplishments that we're proud of

We are proud of the clean UI/UX design that we mocked up ourselves in an afternoon and the fully functioning Beam Payment Protocol integrated into the development environment of Content Fly on Internet Computer, in such a short amount of time.

For Beam to work, it requires a lot of moving parts to integrate together including the ICP ledger, our Job canister, EscrowPayment canister, Beam canister, Plug Wallet deposit payment & claiming funds, web frontend pulling the information in regular intervals and a good UI/UX for users to understand what is happening behind the scenes. It’s essentially a big integration project. It’s also a testimony to demonstrate the merit of Asynchronous DeFi on Internet Computer.

What we learned

We have a better understanding of IC Ledger API and how to use it properly as a remote ledger in IC and local ledger with local wasm. Instead of putting everything together in EscrowPayment, we have an architecture with a better separation of concerns and roles that will lead us into a future extension of Beam, EscrowPayment or even a whole new innovative use case that makes use of EscrowPayment and Beam through composable DeFi smart contracts.

What's next for Beam Payment Protocol

While Beam will remain as a job payment option, we plan to feature Beam Fi as its own service on the Content Fly app home screen, for people to use without having to create a job. Beam Fi will allow anyone to stream payment to employees/freelancers that they already work with or are in discussions with for an ongoing role that doesn't suit the one-off task style job that Content Fly focuses on now. We plan to have several optional add-on features to Beam Fi (milestone check-ins, descriptions & tags/projects categories). Depending on its success in Supernova and the adoption of the community, we will have either a short or extensive separate roadmap for Beam Fi.

We will also explore supporting Bitcoin and stable coins e.g USDC as deposit payments once direct integration with Bitcoin and Ethereum is available in IC. A more sophisticated use case like staking the escrow payment or creator’s claimable tokens in AMM DEX LP automatically could also be considered once the technology is matured and secure. That will essentially improve the efficiency of idle money, allowing users to earn passive income.

Content Fly Main App Deployment

Since Beam involves the transfer of ICP tokens, we want to improve the security aspect of the smart contracts and write more unit tests before deploying Beam to the main app in mid-July for public users to try. In the meantime, users can visit the https://main.contentfly.app link to try the Alpha version features of Content Fly. If you absolutely want to try Beam and are happy to take risk in dev env which we erase the backend data occasionally, try https://dev.contentfly.app. Both dev and main are deployed to IC mainnet.

Beam Source Code

We have uploaded the source code in zip file to Additional Info.

Built With

Share this project:

Updates