# Project Access
### Project Overview * Company Name: Project Access * Organisation: SaFire Solutions * Industry: Film / Content Distribution, Digital Marketing * Website: [www.projectaccess.app](http://www.projectaccess.app) * Geographic Reach: Global * BSV Integration Start Date: February 2026 * Status: Alpha testing — over 250 successful test transactions recorded on the BSV blockchain ### Business Challenge #### What inefficiencies or risks existed? * Subscription fatigue is eroding audience willingness to pay platform-wide fees, putting pressure on creator revenue across the board. * Independent filmmakers and content creators are unable to generate sustainable income: revenue is split between platforms, producers, and distributors, leaving creators with a fraction of what their content generates. * Legacy payment systems make genuine micropayments economically unviable — high transaction fees consume margins at low price points and settlement is slow. * Creators cannot set, adjust, or customise pricing or affiliate percentages dynamically within traditional platforms. #### Why traditional systems were insufficient * Centralised platforms impose rigid revenue splits and lack pricing flexibility. * Traditional payment infrastructure cannot support real-time, per-view microtransactions at scale. * DMCA compliance and content protection require robust access control that legacy platforms do not provide to independent creators. ### Why BSV Blockchain? #### What made the BSV blockchain the ideal solution? * Throughput potential for microtransactions: every content unlock requires an on-chain transaction, making high TPS at negligible cost non-negotiable. * BSV's unbounded scaling design is technically viable where blockchains with artificial capacity limits and high fees are not — a $0.10 micropayment is only meaningful if the transaction fee is a fraction of a cent. * Stable, enterprise-focused protocol with immutable transaction history, supporting transparent creator payment records. * All payments — including those initiated via Stripe — are ultimately settled in BSV, preserving the integrity of the on-chain payment layer. #### BSV-specific features used * Micropayments — core to every content unlock and creator payout. * Smart contracts — payout routing logic splitting payments between creator, affiliate, and platform. * Data storage — transaction and access ledger. * Tokenisation — Pass ownership and access rights. * Overlay Networks and SPV (Simplified Payment Verification). ### Solution Architecture #### Overview of the implemented BSV-based system * Project Access is a decoupled orchestration layer connecting BSV microtransactions, third-party video delivery infrastructure, and a custom affiliate system — without requiring expensive monolithic video hosting or payment gateway infrastructure. * Creators lock content behind a paid "Pass" (priced from $0.10) for lifetime or time-limited access. When a Pass is purchased, the backend executes a smart split transaction, instantly routing specified percentages to the creator, the affiliate (if applicable), and the platform. (The system allows the creator to set any price -- even sub penny prices. There is no minimum. The pricing is fully up to the Creator. The platform gets 20% of whatever the creator sets as the price.) #### Key components * Authentication and Payment Layer (HandCash / BSV): users and creators authenticate via HandCash wallet OAuth; all transactions are settled on-chain and permanently recorded on the BSV blockchain. * Content Delivery Layer (YouTube infrastructure): video files remain on YouTube (set to Unlisted), embedded using domain-restriction policies that ensure the player only renders when the HTTP referer is projectaccess.app — providing DMCA-compliant access control without high-bandwidth hosting costs. * Pass Management: stores relational data linking Creator ID, YouTube URL, price, time limit, and affiliate bounty percentage. * Access Gatekeeper: checks the user's wallet token on each page load and serves either the paywall or the video embed accordingly. * Affiliate Tracking: generates unique referral parameters and reads them at transaction time to credit the correct affiliate wallet. #### Role of partners/vendors * HandCash — BSV wallet OAuth and split-payment API processing. * YouTube — headless video hosting and metadata API for auto-generating Pass interfaces. * Stripe — fiat on-ramp with BSV settlement backend. ### Implementation Process #### Phases of rollout * Phase 1 (February 2026): Development began; core architecture including HandCash integration, YouTube embedding, Pass management, and affiliate tracking logic. * Current phase (April 2026): Alpha testing with over 250 test transactions completed successfully. #### Integration with legacy systems * No legacy ERP or SCM integration required. Third-party services (HandCash, YouTube, Stripe) integrated via API. #### Stakeholder onboarding * Early testing has shown that both creators and consumers require guided onboarding to fully understand the pay-per-view micropayment model — hands-on walkthroughs have been the most effective adoption tool at this stage. ### Outcomes & Business Impact #### Quantifiable results * There have been 159 completed and onchain and 168 abandoned - all tests. #### Key qualitative benefits * Increased creator revenue through direct per-view monetisation, bypassing traditional platform revenue splits. * A new content consumption model — pay-per-view at micro-price points — reducing the friction of subscription fatigue for audiences. * A revenue channel for social media audiences through the affiliate system, enabling followers to earn a percentage of sales generated via their referral links. #### Stakeholder feedback * Early feedback from those who have seen the platform has been positive, particularly among users guided through the full user journey. ### Challenges & Mitigations #### Technical or operational challenges encountered * Market education: the platform introduces a wholly new model for content monetisation and consumption — one that neither consumers nor creators immediately grasp without a guided walkthrough. * Concept adoption: the micropayment content model requires a behavioural shift on both sides of the marketplace. #### How the team leveraged BSV's capabilities to overcome them * BSV's transparent on-chain transaction history has been used as a trust-building tool — the immutable record of every payment provides verifiable proof of the system's reliability for early adopters. * The low-fee environment allows the platform to demonstrate the economic case for micropayments convincingly: amounts that would be uneconomical on other blockchains are viable on BSV. ### Future Vision #### Expansion plans * Content discoverability: enabling consumers to browse and search across creators within the platform, moving fluidly between content offerings. * Plug-in model: allowing any website to integrate Project Access and lock specific content behind microtransaction paywalls, extending the monetisation architecture beyond the platform's own domain. #### Additional BSV functionalities to be explored * AI-CRM integration with BSV — leveraging the developer's CRM background to build intelligent creator engagement and retention tooling natively on-chain. * Deeper integration of emerging BSV features as the protocol matures. #### Scaling potential * Capturing 0.1% of global passive content views at $0.10 per unlock would require approximately 250 TPS and generate an estimated $788 million annually. * A mass-market model at 5% capture requires approximately 12,500 TPS — throughput only achievable on a blockchain with unbounded scaling, such as BSV. ### About SaFire Solutions SaFire Solutions is a web design company and the developer of Project Access. The team brings a background in CRM and web development to the BSV ecosystem, with a focus on practical, user-facing applications of blockchain technology in the creator economy. *Contact: | [www.projectaccess.app](http://www.projectaccess.app)* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://bsv-case-studies.bsvblockchain.org/digital-media-and-marketing/project-access.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.