Please describe your proposed solution.

<u>Subbit.xyz</u>

> Featherweight channels for pay-as-you-go subscriptions and two party micro-payments

Subbit.xyz provides the incentive structure to culture an ecosystem of sustainably financed decentralized services.

Many services are cheap to provide per user, but not free. Via subbit.xyz, services can be delivered at a fair price to both the provider and subscriber while minimizing risk exposure. This is a missing piece in building an ecosystem of sustainably financed decentralized services.

<u>A subbit story</u>

Alice wants to be provided with a service, while Bob is a service provider.

The story starts with opening a subbit :

• Alice seeks out a service provider and finds Bob
• They agree on the terms of service
• Alice opens a subbit by sending a lump sum of ada to the subbit SC
• Bob makes his service available to Alice
• Each request Alice makes to Bob includes a code which, at a time of his choosing, Bob can use to redeem the correct amount from the subbit.

This last step continues until one or more of the following happens.

1) If the subbit funds cannot fund on-going service provision then either:

• Alice can send more ada to their subbit, an action which Bob can see on-chain, and the service agreement continues, OR
• Bob stops providing the service and uses the final code in redeeming his costs from the subbit

2) If Alice no longer wants the service then:

• Alice closes the subbit, an action which Bob can see on-chain
• Bob stops providing the service and has a fixed time interval in which to make a final claim
• After the deadline has elapsed, Alice can drain the remaining funds whether or not Bob has made a last claim

If Alice does not provide a valid code, then Bob does not provide his service. Conversely, if Bob does not provide the service then Alice closes the subbit.

The individual requests are small enough that if one party acts in a malicious way, the cost to the other party has a low upper bound.

The direct costs of using subbit are low:

• For Alice: the transaction fees for the subbit set-up, close, and drain
• For Bob: the transaction fees for each time he makes a redemption

Creating and validating the codes is no more than computing a cryptographic hash.

<u>Advantages over other methods</u>

On the L1:

A naive implementation on L1 faces two key issues:

• transaction fees too high
• dealing with the lag in transaction confirmation / handling rollbacks.

Possible mitigation include Alice paying in larger batches, or Bob providing service before he is confident he'll be paid. Here we have to compromise between risk and quality of service.

In addition both parties need to constantly check the state of the chain: far more resource intensive than using a channel subbit.xyz.

On hydra:

Using hydra for the use cases conceived here is analogous to using the infrastructure of high frequency trading to pay your phone bill. You could; it isn't a great use of resources.

Subbit.xyz by constrast is featherweight. For example, it is conceivable that Bob and Alice agree to a two week closing period. Provided that the value that Bob last saw on Alice's subbit covers the current requests, then he only needs to check the chain once per week. Bob could have the same service agreement with 10,000 Alices, and still only need to check the chain once per week. Compare this to running 10,000 instances of hydra.

Rely on Bob's reputation:

Leads to centralization and stifles innovation.

<u>Use cases</u>

Subbit.xyz isn't magically better for everything: it's a solution to a particular context.

What kind of service is subbit.xyz a good fit for?

• Two party: service subscriber, service provider
• On-going: service provision takes place over a period of time, rather than as a one off
• Not system critical: interruption of service is tolerable
• Atomically cheap: single request costs are small enough that the loss to either party is no more than an irritation
• No lock-in

Examples:

• Cardano services, such as chain queries and transaction-submission
• Serverless type APIs
• Data processing:
• ML services such as LLM responses
• Data streams
• Weekly average weather data from a remote location
• Hosting VMs

<u>Potential issues and mitigations</u>

The setup is premised on the fact that Alice does not wish to trust Bob very much.

But how can Alice verify Bob is providing a good service. He might just be making responses up. Mitigations to this will be context specific.

For example, in the case of liaising with a blockchain, Alice can cycle requests between different Bobs. If one Bob is inconsistent with the others, then she can investigate and end her arrangement with the unreliable Bob.

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

A blockchain only makes sense if it's decentralized. Cardano takes pride in its decentralization, and SPOs are the fundamental enablers of this. It works because there are incentive structures in place to ensure SPOs are remunerated for the service they provide.

Cardano is also a lean blockchain: much of the logic and data crunching is, by design, off-chain. In an early vision of Plutus, every user would be running their own fully synced node and chain db. For the vast majority of users and use-cases this idea is untenable. This has led to the effective centralization of many services and dapps.

We need decentralization to permeate beyond the base layer. SPOs have both the technical capability and resources to provide these at little if any extra cost, if the right tools were in place. Subbit.xyz are these tools. Subbit.xyz provides the right incentive structures for SPOs to offer additional services alongside their Cardano nodes.

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

Immediate term:

• Having an accepted proposal, reflecting a community consensus that we are identifying a genuine and critical problem, while also proposing a credible solution.

Short term:

• The components outlined, open sourced, and presented in an engageable way
• Statements of intent to use the components as described in external projects

Medium term:

• The usage of our components in projects
• Third parties wrapping their services (or otherwise) up in subbit.xyz
• Declarations that new business models are available because of the innovations of subbit.xyz
• The emergence of new decentralized services made possible because of subbit.xyz

Long term

• A financially sustainable, decentralized, and thriving ecosystem of service providers and consumers

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

Gimbalabs's raison d'etre is education and community. Everything produced in this project will be done with external parties in mind.

Subbit.xyz will be successful only if its outputs are utilizable by others. Utilized both directly, and also taken and extended as users need. We know that the key to making this happen is lowering the barrier to entry as much as possible.

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

James Dunseith

• Gimbalabs Co-Founder
• Teacher, Coach, and Smart Contract Developer with extensive experience in creating engaging learning experiences and facilitating problem-solving.

Waalge

• SC consultant, previously built guchi.io
• Math PhD, former full stack dev and ML/NLP reseacher

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

The main goals are reaching the milestones and producing the output stated elsewhere in this proposal.

The aspect which we believe poses the only significant risk to the project's success is that of ease-of-use.

• Can we make the process of deploying subbit.xyz easy enough that it isn't a barrier to adoption?
• Can we make the process of building on and integrating with subbit.xyz as easy as if it were a mature tech?

Engaging future users and stakeholders from the beginning of the process will allow us to validate whether the direction of development is addressing this issue.

The process of developing the validators, transaction building functionality, and testing is understood.

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.

In weeks

• The subbit validator (or family of) written in aiken together with adequate testing (1-6)
• Transaction building functionality in at least two popular frameworks (1-8)
• The subbit dandelion service (8-20)
• Several examples of terms of service agreements (8-12)
• Front-end subbit client (10-22)
• An e2e example of a dapp with using Dandelion services with subbit (18-22)
• Finessing documentation coherently between components (20-24)
• Tutorials on how to wrap an existing service into a subbit framework (20-24)

In our experience developing smart contract applications, like many developing in other emerging contexts, is most successfully approached as an iterative process, rather than say, waterfall style. The above are ballpark figures and we anticipate learnings from a later stage may lead to changes to an earlier output. For this reason the time windows above are deliberately overlapping.

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

By 4 weeks:

• Materials outlining the vision of Subbit.xyz
• Established channels of community engagement
• A list of parties or interest and early adopters
• Publicly available first version of the technical spec of the subbit validator, and first draft of implementation

By 8 weeks:

• The subbit validator written in aiken
• Transaction building functionality in at least two popular frameworks
• Running tests
• All documented, open-source, and available to all

By 12 weeks:

• Published examples of terms of services
• Delivered along with guides as to how they can be formulated

and presented, and how a single terms of service could be used by multiple providers

• A design of the subbit server/client for Dandelion

By 20 weeks:

• A provider-side subbit Dandelion service
• Tutorial on how an SPO can deploy Dandelion with subbit

By 24 weeks:

• An e2e example together with demo of subbit in action
• Documentation redrafted to ensure it reflects the latest stage of development in a coherent manner.

This process will involve reflecting and addressing community feedback on content produced to date

• Tutorials covering how different stakeholders can use subbit: subscribers, providers and developers

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

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

Waalge - technical lead

James - integrations lead

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

Subbit.xyz and the solutions that will follow will culture an ecosystem of sustainably financed decentralized services. Subbit.xyz is service agnostic and the tools and resources for others to build on top of subbit.xyz are an essential part of this project. It is an enabler of new business models. It is catalyst in and of itself. We have confidence the ultimate RoI will be high.

Elements of what is proposed here require an amount of novel engineering, shy of full R&D but beyond a run-of-the-mill project. Accurate estimates of time and resources in such cases is hard. We've done this to the best of our current understanding.