Please describe your proposed solution.

An open source billing server framework that reacts to a queue of tasks to query the blockchain, send assets or confirm payments that can be used by all dApps that involve payment processing.

This billing server would rely on a custom frontend and remote database to form a whole payments-for-resource system. This server would interact with a series of database tables that represent billing task queues, then interact with the blockchain and update the task status for the benefit of a frontend app. The developer community can read the documentation for this server to understand how to create their own MongoDB database, send task objects to it, and ping the database for task status.

The author already has the other components for a full solution in place; namely, a web app and API server that utilizes a working set of user profile data and token gating data in a MongoDB Atlas account. When this proposed project is complete, there will be an instance of this open-source billing server online and in-use with an existing token gating project currently in an alpha phase, and this fully working solution will be presented live and in a recorded demonstration.

Through the use-case app, the author's version of this open-source billing server will be used to facilitate payments for gate-protected content on a third-party website. This app will prove the usefulness of the proposed billing server by allowing users to create token gates for media that require payment in order to pass. Without needing coding skills, NFT projects will be able to dictate that their creative content or livestream be protected behind a specific NFT series, require a particular amount of ADA to pass, or both.

When user payments are detected, this system is capable of performing follow-on tasks aside from querying the blockchain and marking the task as Paid. The task object can include instructions for the billing server to transfer assets from a specific hot wallet on-file to a provided address. The form of payment specified can be any token in the Cardano ecosystem, from ADA to fungibles to NFTs.

This flexibility would allow an app team to use this billing server to not only accept payments for NFTs as a sort of minting service, but to also gamify engagement for holders. An NFT project could, for example, create an app that sends tasks to this billing server in order to facilitate an “evolving” design; a certain NFT is sent to the app and the sender receives either a specific NFT or a random NFT belonging to a specific policy. Another potential use case would be to allow holders to turn in NFTs in exchange for a quantity of fungibles, or even return them for ADA. Yet another use case is as a whitelist - before sending a random NFT, verify the sender holds an NFT from a prior series and also has sent payment.

The primary benefit of this project to the Cardano ecosystem is a potentially significant lowering of development costs for all projects that involve some form of payment processing or token turn-in. By speeding up development for everyone we will surely see more great apps that can get a profitable, revenue-taking app launched in less time and requiring fewer project funds.

The scope of this proposal includes a finite list of task types and related reactions on the billing server:

• Creating internal wallets and associating them with a user identifier
• Detecting payments
• Confirming payment
• Sending tokens
• Generate access to private resources
• Charging and withdrawing

Creating Wallets

This task type asks the billing server to create a wallet and store the keys so that the billing server can make withdrawals at request, or send out assets in the context of NFT purchases, rewards or gamification. This task can specify a user identifier, which is arbitrary to the billing server but can be used by an app that involves user profiles to update that user’s payment status. The author will have an app ready as a live demonstration of this use-case as an app where user accounts have internal wallets associated with them, that they can deposit and withdraw from.

Detecting Payments

Possible conditions for “detect payment” tasks are:

• The receive address (required)
• The sender: From a specific address or anywhere
• The payment quantity
• The payment type: ADA, NFT or FT
• Sending wallet must hold a specific asset
• Sending wallet must hold any NFT in a series

Potential programmable actions include:

• Sending one specific asset
• Sending a random NFT from a specific policy
• Sending a quantity of fungibles
• Generating an authentication token for a resource identifier (OAuth for data)

A payment task object can also include an arbitrary resource ID, so that the billing server can act as a resource server and create an authentication code pointing to that resource. A development team would then create a frontend that can make use of that code to make a one-time fetch of that resource. The author already has an app in place that can demonstrate utilizing auth codes to fetch resource payloads such as videos, games, scripts, or raw data on-page. The author’s app token-gates video content, and with the open source billing server described in this proposal those video token gates will be able to require payment in ADA before streaming.

A developer team could add onto their billing server clone to include server-side actions when payment tasks are completed, such as creating Google Analytics conversion events.

Charging and Withdrawing

This type of task, unlike detecting payments described above, asks the billing server to create a transaction, transferring ADA from a specific hot wallet on file to another address. This can be used by a frontend UI such as a web app or game to send rewards to users if the system is aware of the user’s wallet address. This task type can be used as a token faucet, to send endgame rewards, or to send gift tokens to specific users who do not have to take any particular action.

The task type Withdraw is a request to transfer assets from the wallet belonging to a given user ID to a wallet address provided by the user in the Withdraw function of the demo web app. The billing server in the scope of this proposal is in charge of associating user identifiers with internal wallets. The Charge task type is a request to transfer ADA from a given user’s internal wallet to the billing server’s main revenue wallet. The task specifies the user’s service tier, and the billing server uses its configuration file to determine the amount to charge per service level. In the context of the demo app that leverages this billing server, the failure of a Charge task will demote the user to a Free usage tier which will affect the level at which they can use the app. Success of a Charge task will update the user’s payment status and automatically create a copy task for the next month.

The author will demonstrate a live example of an app utilizing this task type, in the form of a monthly payment subscription service where each user is associated with a hot wallet controlled by the billing server. User statuses will update depending on the success or failure of these transfers, which will alter the ways in which logged-in users can interact with the app.

How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

With this solution in place, Cardano project teams can each save themselves a large amount of work re-coding a proprietary solution to this particular component. DApp projects involved in or interested in a form of payment processing can use this billing server in flexible ways to facilitate payments for things of value such as app access, streaming video, wallet verification and other use-cases. Furthermore, this open source billing framework will be put to use in an app that is already live but would make use of this server to allow creators to monetize videos without making an NFT campaign and without needing coding skills.

How do you intend to measure the success of your project?

The proposal scope is for an open source billing server, so our metrics of success will be related to its adoption by the development community.

• Number of Github downloads of the framework
• Number of billing servers online
• Number of successful projects utilizing the framework
• Reported amounts of ADA processed by billing servers

Please describe your plans to share the outputs and results of your project?

We will share the progress and results of this work product on our website as blog updates as well as in partnership with project partners on Twitter and Youtube. We will reach out to projects, create how-to videos, and assist the public at large for working with instances of the billing server to implement their own solutions.

What is your capability to deliver your project with high levels of trust and accountability?

The team involved in this project has already created Cardano apps in prior funds and are looking to expand on what we have learned along the same theme of token-gating as a service.

We have already set up our UML diagramming, shared drives, and project management through ClickUp. Top-level work-sprints were made to assess the time and cost of this project, and once funded will be broken down into smaller tasks for assignment.

What are the main goals for the project and how will you validate if your approach is feasible?

Speed up the advent of other great apps by contributing to the underlying tooling ecosystem for Cardano.

Provide development teams with an independent billing component that would allow their app to be profitable while saving significant amounts of project resources recreating the solution.

Become the payment processing tool of choice for one of the top ten projects on Cardano, and process payments for 5% of all projects in the ecosystem.

Assist in popularizing the usage of fungibles as payment (ie, Hosky, Snek)

Empower legacy NFT collections to reinvigorate their audience with opportunities to gamify redemption.

Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

• Q1
• Open Source Billing Server: A NodeJS server that the community can clone in order to jumpstart facilitating payments for their own web apps. Instead of serving API requests for billing tasks, it runs on chronologically triggered functions that query task queues and perform several kinds of blockchain related tasks. When tasks are in progress, completed, set for retry, or failed, the task status is updated so that a web frontend can confirm that a certain payment has gone through.
• 3 work sprints covering estimated 215 hours
• Starting 10/8/23, target launch 11/2/23
• Projected cost: ₳ 31,820 ($7,955)
• Secure NoSQL Billing Database: A collection of article trees on an independent MongoDB Atlas cluster that serve as data storage for the billing server. Unrelated to a particular frontend, this database instance solely serves the function of storing billing tasks, migrating tasks to archives, and storing sensitive hot wallet information. While the database we use for this project cannot become public, a cleaned version of this sister component to the billing server will also be open source.
• 3 work sprints covering estimated 200 hours
• Starting 11/5/23, target launch 11/28/23
• Projected cost: ₳ 18,628 ($4,657)
• Billing Registration Task and Reactions: Create an internal wallet, store the keys securely, and associate it with a user profile ID. Create frontend interfaces to instigate task requests and API routes for honoring status requests.
• 3 work sprints covering estimated 421 hours
• Starting 12/11/23, target launch 1/18/24
• Projected cost: ₳ 74,460 ($18,615)
• Q2
• Detect Payment Task and Reactions: Confirm detection of a transaction on the blockchain matching multiple conditions, and take post-payment actions such as moving assets from a hot wallet to the sender. When a user registers an account on the demo app, a task for payment will be made that will trigger the sending of a login token, which will elevate the user permissions and allow them to use the full features of the app. If the payment is overdue, the user becomes downgraded to a free tier uninvolved with the billing server.
• 8 work sprints covering estimated 904 hours
• Starting 1/21/24, target launch 5/4/24
• Projected cost: ₳ 51,664 ($12,916)
• Make Transfer Task and Reactions: Attempt to transfer assets from a server-controlled hot wallet to another address, in the case of a user account withdrawal (Withdraw task type) or a recurring subscription payment (Charge type). Optionally, update status attributes of a specific user profile object depending on success or failure of a Charge type task.
• 4 work sprints covering estimated 625 hours
• Starting 5/7/24, target launch 7/18/24
• Projected cost: ₳ 35,716 ($8,929)
• Q3
• Integrate a Web App: Create a live demonstration of proper usage of all aspects of the billing server and its task queue with a web app. Create wallets for registered users, and allow users to configure reactions to incoming payments such as sending of tokens or temporary access to media. Thirdly, the web app will demonstrate the Make Charge task type by making access to the app a paid monthly subscription.
• 5 work sprints covering estimated 370 hours
• Starting 7/21/24, target launch 9/2/24
• Projected cost: ₳ 21,144 ($5,286)
• Q4
• Public Launch
• 1 work sprint covering estimated 90 hours
• Target launch date, 9/5/24
• Projected cost: ₳ 5,140 ($1,285)

Timelines for milestones are based on work-hour estimates for the work sprints involved in completing each. For details please see the proposal worksheet for this project.

Please describe the deliverables, outputs and intended outcomes of each milestone.

1. Open Source Billing Server
2. Initialize Billing Server Framework: Set up an instance of the billing framework on proper hosting and initialize the code with internal configuration tables and secure environment variables.
3. Establish Secure DB Calls: Insert a secure process.env variable for the MongoDB access key into the web app API, the resource (tokengating) server and the billing server. Test all read/write functions to the database by the billing server and the API server that serves the web app. This includes user billing data, internal wallet data and task statuses for all three queues; Create Wallet, Detect Payment, Make Charge/Withdraw.
4. Create and Test Task Loops: Add multiple tasks to each of the task queue tables (Create Wallet, Detect Payment, Make Charge) and ensure that the billing server is able to read and write to those tables. Test the configuration table that dictates the frequency of running batch checks on each task type.
5. Secure NoSQL Billing Database
6. Initialize Database Account: Initial setup of the MongoDB database account such as remote access settings for the web API, resource (tokengating) API, and billing server.
7. Billing Data Tables Setup: Create the necessary data objects for the web API and token-gate API (resource server) to push new objects to all three billing task types. Create relational data tables for relating internal wallets to arbitrary user identifiers, user subscription statuses and service tiers. Primary DB articles are Users, Gates, Wallets, Wallet Keys, User Billing Logs, Wallet Creation Tasks, Detect Payment Tasks, Withdrawal Tasks, Charge User Tasks.
8. Billing Database Security Audit: Before proceeding with real use of the data tables, utilize a database and API security consultant to advise on security protocols for access of data articles from the web API, gate API and billing server.
9. Billing Registration Task and Reactions
10. Task Reactions: Create Wallet: The billing server iterates through the task queue for Create Wallet, generating wallets and associating them with given user identifiers. Adds event logging associated with each internal wallet with creation being the first log event.
11. Wallet Creation Upon Registration: When new users register on the demo app, the frontend sends a request to the web API server to create a new billing task type, Create Wallet, and associates that wallet with the user ID.
12. Post-Registration Login Token: After successful account registration, the web API server should create another task for the billing server, type Detect Payment. This post-registration task should be configured to wait for a deposit from any address to the user's internal hot wallet, and transfer an unused login token from the app's own wallet to the sender.
13. Detect Payment Task and Reactions
14. Task Reactions: Detect Payment: At a high frequency, iterate the task queue for Detect Payment. Determine that all the required and optional conditions are met for the gate payment. Check the longform report for all payment conditions. When the payment is confirmed complete, the status is updated in the arhived version of the task table and the task is deleted from the active task table, to keep the active table small and fast. The gate resource server will ping this table for specific tasks on behalf of a wallet-based OAuth frontend, and once paid the resource server can create an authentication code to the callback website to access the gate payload. The task may also include server-side followup actions to send assets from the gate creator's internal wallet to the address of the user who passed the gate.
15. Create Gate: Payment Options: Create a frontend interface by which users create configuration options for token-gated resources, and include options for requiring payment for gates to pass. Allow options to specify the token type, ADA, NFT or FT. Provide a quantity requirement option. Provide option for follow-on actions for sending tokens out of the user's internal wallet to the sender when a gate payment is made. Hot wallet sending options include ADA, specific NFTs, a quantity of fungibles, or a random NFT from a series.
16. API Route: Create Gate With Payment Options: When the web app facilitates the creation of a new gate, process the request by creating a new resource object (the token gate) along with its conditions, which can include a combination of domain restrictions, asset ID trigger, policy ID trigger, and payment requirements.
17. User Registration Initial Task: When creating a new user via API request, the web API server creates a task for the billing server under the queue for Detect Payment. This task is configured to await payment beyond a minimum amount and then transfer an asset from a hot wallet belonging to the app. The hot wallet contains unused login tokens that are sent to the depositor which then upgrades their account the next time they log in, from Registered to Active.
18. Gate Payment Interfaces: Create a web app that facilitates the OAuth flow for third-party websites to obtain token-gated payloads such as videos for holders of specified tokens. If a selected token gate is configured to require payment before passing, send a request to the resource (tokengating) server to create a new task in the Detect Payment queue and receive an OK return with the task ID. The UI will then generate a transaction popup using the Lucid library for the amount required by the gate object, to the address belonging to the user who created the gate. Once signed, the app renders the task status modal, which will periodically send requests to the resource server for updates on the task. Once the task comes back as complete, the return package will contain an authentication code for the gate payload, which is passed to the callback website. That auth token is used by third party sites owned by the app users to fetch gate payloads for web3 utility on their own websites. For the purpose of this demo app the utility will be videos.
19. API Route: Get Valid Gates: Respond to the OAuth app for requests for valid token gate objects depending on the user's wallet contents and the calling domain. Returned gate data should include payment requirements if any, so the OAuth modal knows to initialize a transaction popup for the user's signature. Payment details include the internal wallet of the user who created the token gate, and the amount required for the gate to pass.
20. Get Gate Payment Status: Respond to task status requests from the OAuth app for Detect Payment type tasks for token gating conditions.
21. API Route: Execute Gate: The callback website of the wallet OAuth flow is a website owned by the user, the designer of token gates on the website. With an auth code provided in the callback URL, the on-page script will make an Execute Gate call to the resource server for that payload. Since working authentication codes for gate resources are only provided when all conditions of the token gate are met, it is presumed at this point that gates requiring payment have been paid.
22. Make Transfer Task and Reactions
23. Task Reactions: Withdrawal: The billing server iterates through the task queue for Withdrawal requests at a high frequency to transfer assets from a hot wallet associated with a user to an address provided by the user.
24. Task Reactions: Charge: A Charge type task is created by the web API serving the frontend app when a user selects a different subscription service tier from the My Profile menu of the demo app. The billing server reacts to Charge type tasks by transferring an amount related to a given user's service tier from the user's internal wallet to the app main revenue wallet, and creating a follow-up task for the next billing cycle, frequency configured internally on billing server. If this task fails, the billing server "downgrades" the user's service level to Free, which affects how the user interacts with the demo app.
25. API Route: Update Subscription Level: Process requests from the web app My Profile page to modify the subscription tier in user object data. In the same request, search for and modify any existing Charge task related to that user or create a new one. Delete the charge task and demote the user status if the subscription level requested is Free.
26. My Profile: Update Subscription Level: Provide options on the My Profile section of the demo app to see and modify subscription level and see account health status, and send an API request to the web app API.
27. Integrate a Web App
28. My Wallet Interface: Create a web app menu where users can see internal wallet balance and a grid of tokens with counts, if the hot wallet contains assets. Create a Withdrawal mechanism that sends a request to the web API to initialize a withdrawal. The app should request an internal wallet transaction history from the web API, which will fetch log entries related to the internal wallet of that user.
29. API Route: Withdrawals: Process requests to withdraw assets from internal wallets adding a task to the Withdrawal queue for the billing server.
30. My Wallet Interface: On the demo app, create a menu revealing internal wallet attributes and providing the ability to withdraw funds through a Withdraw button. List internal wallet assets that have been loaded and ready to send out.
31. My Profile, Subscription Options: On the demo app, add a section for user payment status, billing history, and a dropdown to select a different "service tier" or free.
32. Web API, Subscription Change: On request from the web app, update the pay tier level of a user and modify any upcoming payment tasks for that user in the billing server task queue for Make Charge. If it is a change to the Free tier, delete any billing tasks. If it is a change to a paid tier, either modify the amount in the existing billing task without changing its date, or create the first recurring charge task for the account.
33. Public Launch
34. Prepare for Launch: Prepare for the public launch by announcing on social channels, scheduling interviews and partnering with other projects that may want to utilitze an instance of the open source billing server.

Please provide a detailed budget breakdown of the proposed work and resources.

The cost of this proposal is a one-time price that will produce a multi-use, open source Cardano billing server and, to demonstrate its use, a self-service Cardano app that can be used by the entire community to pay-gate creative content. It has the potential to allow all NFT projects and web-based content creators to monetize films, animations, performances and other forms of video to non-token holders with simple ADA payments. The flexibility of this server would let development teams gamify NFT redemption or reward users with a transfer of fungible tokens. The hope is that this billing server can be incorporated into the majority of common use-case requirements for NFT utility projects.

All team members have committed to a baseline cost of living for the duration of the project. All hard costs have been plotted out, and the hourly rate for labor amounts to approximately $14 per hour. We do not plan to outsource development work, and this proposal will allow the team to focus on the project around the clock until it is completed.

Who is in the project team and what are their roles?

Dane McBride

Fullstack developer and project manager

Dane creates operational business strategies from competitive and internal analyses of e-commerce brands. As a Plutus Pioneer student he devotes his time to learning smart contracts for use in B2B services to grow utility and tooling on Cardano.

Relevant Experience: In over 14 years of experience in competitive consumer industries, Dane was in charge of strategy development and execution, managing large-scale technical projects with teams of up to thirty-five people. Dane is bringing a mix of Cardano blockchain experience, self-taught coding skills and digital marketing background to the project. Dane was in the Plutus Pioneer Program to lead Haskell development for Cardano projects.

How does the cost of the project represent value for money for the Cardano ecosystem?

The labor costs for this involve mostly in-house development work that amounts to $14 per hour, and we have a budget set for 180 hours with a backend developer with strong experience with the Cardano node SDKs to ensure that the billing server proposed can perform blockchain-based functions quickly and securely.

The hard costs for this proposal are all research-backed and itemized according to the timeframe they are needed. The author has a high degree of confidence that a working project matching the description of this proposal can be executed within the allotted time because of the low cost of labor and the conservative nature of the work-hour estimates given to each work sprint.