Fans Platform – Progress Report

Fans Platform – Progress Report

This is an unlisted page used to post updates about the development of the Fans Platform. You can signed up and play around with a constantly improving live app at https://fans.calenda.rs

Overview

This gives an overview of the platform’s design and architecture.

Data Architecture

  • People: can maintain profiles with a username and icon, can link to their other socials
  • Interests: people indicate their interests, to receive notifications when relevant new content is published
  • Channels: anyone can start their own channel and invite followers, hosts and guests
  • Episodes: videos recorded on a channel can be imported from multiple sources
  • Clips: audience members can clip episodes and re-share clips to various social networks
  • Invites: people can invite others, and the system tracks who invited whom

Tech Stack

The uncensorable front end is built to run in mainstream web browsers, such as Chrome, Safari and Firefox:

  • Pages rendered from templates in HTML, CSS and Javascript
  • Tools are reusable components that can appear on pages
  • Players are video players that work with YouTube, Vimeo, internal video streaming, etc.
  • Embeds are widgets, such as a player, that can be placed on other websites
  • Teleconferences are live audio+visual conversations powered by open WebRTC protocol

The back end is built to run on a very mainstream stack, so it can be hosted anywhere, and moved to a different server if need be:

  • App Server is written in PHP and can work with web servers like NGinX, Apache, etc.
  • Database is MySQL allowing data portability, and optimized to handle millions of users
  • Streams use Node.js and web sockets
  • Subscriptions let people subscribe to topics and interests
  • Notifications are delivered by Node.js to endpoints like email, SMS, devices, and Telegram
  • Telegram integration with Telegram platform, including chats and bots
  • X integration with the X platform, for posting, upvoting and re-sharing clips together

Technical Details

For more technical information on our approaches and optimizations, feel free to click here:

Milestone 1 is Complete

The initial skeleton of the site has been developed. Here is what has been built so far:

:white_check_mark: User Accounts & Profiles
Users can register, log in, create public/private profiles, and optionally link social accounts (Twitter/X, Telegram, etc.).

:white_check_mark: Multi-Host Channels
A channel is owned by one user but can include multiple co-hosts, who can manage and broadcast from the channel.

:white_check_mark: Invite System
Users can invite others to join channels via SMS, email, Telegram, X, and QR codes, each tracked by origin.

:white_check_mark: Invite Tracking
Invites are tracked to build a referral graph, useful for crediting bonuses, building trust graphs, and analytics.

:white_check_mark: Text Chat
Embedded real-time chat for viewers and hosts, laying the groundwork for future engagement and moderation tools.

Here is an early look at the visual design and layout. The colors and images will be improved as we work on the project.
EarlyScreens

Milestone 2 is Complete

We’ve repurposed our videoconferencing technology and expanded its livestreaming capabilities. Here is what has been achieved in this milestone:

:white_check_mark: Peer-to-Peer Live Broadcasts
Livestreaming done with P2P livestreaming (no central server) using WebRTC with STUN/TURN fallback. Multiple guests can join and watch, and it feels like Twitter Spaces with video.

:white_check_mark: Stage & Permissions
Hosts/moderators of a stream can elevate others to the “stage”, with queueing and moderation tools. This feels like Speakers on Twitter Spaces. Can be used to bring guest streamers and cohosts.

:white_check_mark: Waiting Room & Guest Management
Guests enter a waiting room until accepted on stage. Hosts see profile previews and accept/reject requests. This is for people calling in, or interacting with the streamer in real-time. Supports screeners to speak with the caller before approving them on stage.

:white_check_mark: Intro/Outro Scenes
Basic branding support: automatic intro/outro animations or static screens when streams begin or end. The streamers can now update the assets on their channel.

Fans Milestone 2 Demo:

Technology Demo: Scheduling Peer-To-Peer Livestreams:

Milestone 3 is Nearly Complete

We’ve already implemented the following:

:white_check_mark: Buy Crypto and Deposit with the Platform
Users purchase platform credits with either crypto (e.g., USDC, ETH) or credit cards (if the user chooses to add a Stripe API key). In Web3, the money deposited can go into a specific address on the blockchain. This address can be an IncomeContract smart contracts, which can then be used to pay out to others on-chain at specific rates, overseen by managers. In Web2, it would be more opaque and use the Stripe Payouts API.

:white_check_mark: Recurring Weekly Subscription Model
Give permission to withdraw crypto from your wallet balance. Content creators should be able to set the recurring plans. All this is done with our turnkey solution involving recurring subscription smart contracts on EVM blockchains. On the web servers, a periodic cron job can run and call smart contract methods on those blockchains (e.g. once a day) in order to transfer subscription payments on-chain. Customers can top-up their balance as they see fit, but their subscription lapses, their access to videos on the website is paused.

:white_check_mark: Pay to Watch (Live + Recordings)
Streams and recordings can now be gated, requiring a small payment to unlock access. This is done off-chain, with site credits, and works to stream from the server. However, the actual hosting still needs to be more decentralized. This is what we’re working on now.

:white_check_mark: Seamless UX
The payment experience is smooth, on-platform, and consistent across devices. It also integrates with peer-to-peer livestreams, as well. Take a look:

Technology Demo: Operating Peer-to-Peer Livestreams:

Milestones 3 and 4 are Functionally Complete

Smart Contracts, the OpenClaiming Protocol, and Decentralized Encrypted Storage


We’re proud to report that both Milestone 3 and 4 are now functionally complete. Milestone 4 was the deepest engineering work of the entire project — not just a feature, but a new open protocol, a decentralized storage network, and a complete on-chain payment architecture. Here’s what we accomplished, why it matters to every creator and viewer on the platform, and why Milestone 5 is the final step to putting all of this in your hands.


The Core Promise: No One Can Shut You Down

When you host your content on YouTube, OnlyFans, or any centralized platform, you live at their mercy. Your account can be suspended, your earnings frozen, your content removed — overnight, without appeal, for any reason or none at all. Creators have lost years of work and income this way.

Our platform is built so that this is structurally impossible. Here’s why:

  • Content is encrypted on the creator’s own device before it ever leaves. Nobody — not us, not any server, not any government — can read it without the creator’s key.
  • Payments accumulate as cryptographically signed claims that anyone can submit to the blockchain. No company controls the payment rails. No account can be frozen.
  • Revenue distribution happens through Intercoin’s IncomeContract — an open-source smart contract that has been developed years ago for this very purpose. It distributes value to creators, infrastructure operators, and the platform automatically, on-chain, in any mainstream EVM token. And it does so predictably and deterministically according to predefined proportions, with no centralized middleman controlling the flow.

Creators can’t be deplatformed because there is no centralized platform to be deplatformed from. The content lives on the network. The money flows through open contracts. The keys stay with the creator.


What We Built: The OpenClaiming Protocol

The biggest deliverable of Milestone 4 is something that will outlast this project: the OpenClaiming Protocol (OCP) — an open standard for authorizing and executing micropayments using off-chain signed claims, published at openclaiming.org and github.com/OpenClaiming.

Why it’s needed

Smart contracts are powerful but slow for micropayments. When a viewer watches a video, you can’t ask them to sign a blockchain transaction and wait for confirmation every few seconds. That ruins the experience.

OCP solves this by separating authorization from execution. A viewer can sign micropayment claims instantly, off-chain, without needing to approve every transaction. Those claims are cryptographically bound to specific recipients, amounts, time windows, and spending limits — they cannot be forged, replayed, or altered. The claims accumulate silently in the background. At any point, anyone — the creator, an operator, or an automated relay — can submit a batch of claims to the blockchain and trigger the actual transfers. This is permissionless and global. No company needs to approve it. No bank needs to be involved. A digital content creator in Brazil, Nigeria, Indonesia, or anywhere else with a phone and a crypto wallet can receive payment from viewers worldwide without ever touching a traditional financial system.

What we built and documented

  • The OpenClaiming smart contract — deployed at a canonical address across supported chains. It verifies EIP-712 typed signatures, enforces per-claim and per-line spending budgets, and executes ERC-20 transfers directly or through Intercoin’s IncomeContract. Immutable. Open-source.

  • The full OCP specification — wire format, key URI schemes, RFC 8785 canonical JSON signing, multisignature policy, and EIP-712 Payment and Authorization extensions. Documented in full and published openly so any developer in the world can build on it.

  • Canonical implementations in multiple languages — including browser JavaScript, Node.js, and PHP — all producing byte-identical signatures that verify each other. A payment signed on a mobile browser can be verified by a routing server in Tokyo and executed by a smart contract on BSC. No translation layer. No trust required between the parties.


What We Built: Safecloud — Decentralized Encrypted Storage

The second major deliverable is Safecloud, a complete decentralized storage and delivery network built for this platform and open-sourced at github.com/Safebots/Safecloud.

How it works for a creator

A creator finishes a recording on their own computer. They upload into the Safecloud using their browser. Before a single byte leaves their device, the browser encrypts it — split into chunks, each with its own cryptographic key derived from a master root key that never leaves the creator’s possession. The encrypted chunks are distributed across a network of Drops: browser tabs on ordinary computers running the Safecloud website. These can include the creator’s own machine, as well as people around the world that opened the browser tab and agreed to storing encrypted chunks (so they don’t know what they are storing).

To share the video, the creator shares a link. The decryption key travels in the URL hash — the part after the # — which browsers never transmit to servers. Only someone with the full link can watch. Encrypted content is not revealed to any server – not ours, not anyone’s.

How it works for a viewer

The viewer clicks the link. Their browser derives the decryption keys from the URL, requests the encrypted chunks from the network, decrypts them locally, and plays the video. The viewer pays via OCP claims — tiny signed authorizations that flow silently in the background. No blockchain popups. No waiting for confirmations. It feels exactly like any other streaming platform, except the money goes directly to the creator.

How the network stays honest

  • Drops store and serve encrypted chunks. They earn Safebux tokens for every chunk they deliver. If they go offline or serve corrupt data, their reliability score drops and they stop receiving traffic — and they can’t quickly exit because of the token transfer rate limit (more on this below).
  • Jets are servers that route requests between viewers and Drops, verify OCP payment claims, and ensure sufficient redundancy. They earn a small share of each payment for this coordination work.
  • The content creator earns the majority of every payment made to watch their content.

All payouts flow through Intercoin’s IncomeContract — the same battle-tested smart contract that Intercoin has used for years to distribute value across communities in any EVM token. No centralized entity controls this distribution. The splits are encoded in the contract.


What We Built: The Safebux Token Economy

Safebux (SAFEBUX) is the token that powers the network’s incentives. Here’s the complete economic picture in plain English.

For viewers

A viewer wants to watch a gated video. They can buy Binance Smart Chain tokens (BNB) through any service like MoonPay. They approve a small BNB payment — or have a pre-authorized spending line so it happens automatically. Behind the scenes, the platform acquires Safebux using that BNB and routes it as OCP payment claims to the content creator and infrastructure operators. The viewer just sees a video that starts playing. No wallet popups mid-stream. No blockchain jargon.

In milestone 5 when we roll everything out publicly, we also plan to deploy this same system of smart contracts on Ethereum Mainnet, Optimism, Arbitrum, and Base (Coinbase’s blockchain). This will allow people to have a choice of blockchain on which to make payments. Besides the blockchain’s native coin (such as ETH, BNB, etc.) they will be able to use USDT and USDC stablecoins if they are available on the site.

From that point on, they can exchange their BNB, USDT, USDC for fiat using their local exchanges in their country. In milestone 5, once we integrate with Circle Mint / Payouts API, we will be able to allow businesses in the US to withdraw money to their bank account.

For creators

As viewers watch, OCP claims accumulate. The creator can submit these claims to the blockchain at any time — permissionlessly, from anywhere in the world — and Intercoin’s IncomeContract distributes the Safebux to their wallet. The creator then redeems Safebux for BNB, USDC, USDT, or their preferred token at market rate. Direct to their wallet. No platform holds the money.

For Drop operators

Anyone can run a Drop node — a piece of software that stores and serves encrypted chunks. Drop operators earn Safebux for every chunk they serve. The more reliable and well-stocked their node, the more they earn. There’s no approval process. Anyone with a computer and an internet connection can participate.

The 10%-per-day transfer limit: why it matters

Safebux includes a deliberate design constraint: no more than 10% of a wallet’s balance can be transferred per day.

This is not an accident. It means:

  • An operator who has been honest and accumulated a large Safebux balance has real skin in the game. They can’t dump and disappear overnight.
  • A bad actor who tries to earn tokens by misbehaving — serving garbage data, going offline after claiming payments — faces a slow exit. The damage they can do is bounded and recoverable.
  • The more Safebux someone holds, the greater their stake in the network’s health. This creates a proof-of-stake-like commitment without requiring a separate staking mechanism. Holding Safebux is itself the stake.

For honest participants, this is invisible. They accumulate tokens, redeem portions regularly, and reinvest in their infrastructure. For the network, it’s a continuous alignment mechanism.


What’s Live Right Now

  • :white_check_mark: The Safebux token is deployed and functional on BSC testnet
  • :white_check_mark: The OpenClaiming contract is deployed on BSC testnet, verifying EIP-712 Payment claims and executing transfers
  • :white_check_mark: The complete upload → encrypt → store → stream → decrypt → play pipeline works end to end in our demo environment
  • :white_check_mark: OCP claim signing and verification works across browser, Node.js, and PHP with byte-identical results
  • :white_check_mark: Drop nodes earn Safebux as they serve chunks, with on-chain accounting
  • :white_check_mark: The IncomeContract distribution splits are wired and tested on testnet
  • :white_check_mark: open-source Safecloud codebase — browser encryption, Node.js routing, service worker HLS streaming, and PHP handlers — published at github.com/Safebots/Safecloud

Milestone 4 vs. Statement of Work

Deliverable Status
Micropayment receipts on chain (signed OCP claims) :white_check_mark: Complete
Smart contracts for redemptions (Safebux ↔ BNB/USDC/USDT) :white_check_mark: Testnet
Reserve management and per-chunk pricing :white_check_mark: Complete
Fiat payout integration pathway :arrows_counterclockwise: Architecture complete; KYC hookup in Milestone 5

The fiat offramp (converting creator earnings to local bank currency for KYC’d users) is architecturally designed and the smart contract interfaces are ready. Connecting it to a payment processor is scoped for Milestone 5 alongside the mainnet launch.


Why Milestone 5 Is the Final Piece

Everything described above is now already developed. The cryptography is correct. The smart contracts have been deployed to testnets, and being tested before posting to mainnets. The storage network functions. The protocol is specified, implemented, and open-sourced for the world.

What Milestone 5 delivers will be the launch: turning a working system into something a creator can start earning from on day one, and a viewer can use without knowing any of the above exists.

Specifically:

  • BSC mainnet deployment of Safebux and OpenClaiming (currently testnet)
  • Seamless viewer UX — BNB → watch, with no visible blockchain interaction
  • Creator dashboard — earnings display, one-click Safebux redemption to any preferred token
  • Drop operator onboarding — simple UI to register a node and start earning
  • AI clip generation, translations, and social sharing per the Milestone 5 scope
  • Public launch — the platform opens globally to creators and viewers

The engine is built. Milestone 5 puts the body on the car and opens the factory doors.

We’re asking for Milestone 5 funding to take a functioning, documented, testnet-deployed, open-source system and turn it into the platform that creators — anywhere in the world, in any currency — can use to publish their work, own their audience, and get paid without asking anyone’s permission.


The OpenClaiming Protocol is published at openclaiming.org and github.com/OpenClaiming. Safecloud is open-source at github.com/Safebots/Safecloud. Intercoin’s suite of community smart contracts — including the IncomeContract powering all revenue distribution — is documented at community.intercoin.app.