Samaritan

[thewoodfish]

Project Abstract

Samaritan is a decentralized backend-as-a-service (BaaS) platform that offers Firebase-like APIs for building real-time Web3 applications.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[thewoodfish]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Hey @thewoodfish thanks for the application. One question I have right off the bat is, what is the current demand for Firebase usage right now from dApp devs? For example I know that Axie Infinity has been using it for data and game state, so I'm just curious if there are many other popular projects that are using Firebase as a backend?

In other words, are you seeing a trend here in which dApps are increasingly adopting a hybrid architectural model?

[thewoodfish]

Thanks for the honest question @keeganquigley .
Yes, we’re seeing more dApps adopt hybrid architectures — combining decentralized logic with centralized tools like Firebase or Supabase for speed and ease of development.

Axie Infinity has used Firebase for game state and real-time updates.
Lenster (a Lens Protocol client) and other Lens-based apps have used Supabase for session management, search, and off-chain actions.
Some DAO tools and dashboards (like early Snapshot forks) use Firebase for live data and admin views.
Orbis and some Farcaster clients use centralized services to manage indexing, notifications, and real-time collaboration features.

Developers choose these tools not because they align with Web3 values, but because they’re fast, well-documented, and easy to plug in.

Samaritan brings that same developer experience — real-time database, wallet-based auth, and decentralized storage — in a self-hosted (by choice), modular way that aligns with Web3 principles. Over time, we’ll expand it with plug-and-play modules like presence, queues, and CRDT utilities to cover even more backend needs for dApp developers.

[keeganquigley]

Thanks @thewoodfish sounds good to me, I'm personally willing to support it given the team's track record. I will mark the application as ready for review and ping the rest of the committee for comment.

[muddlebee]

Supabase is an open-source alternative to Firebase that provides a complete backend-as-a-service, combining a scalable, feature-rich PostgreSQL database with user authentication, file storage with access controls (ACLs), and real-time APIs.

SamaritanDB is an interesting concept built on IPFS, but I'm doubtful how well it will scale and how practical it is for real-world production use compared to Supabase.

Note: I have used Supabase in many of my apps :)

[thewoodfish]

Thanks for the feedback — really appreciate you sharing your experience with Supabase (it’s a great tool).

We’re not trying to replace Supabase or PostgreSQL in traditional app stacks — instead, Samaritan focuses specifically on real-time, collaborative apps in decentralized contexts, where wallet-based identity, offline-first sync, and self-hosting are essential.

Unlike a relational DB, SamaritanDB is a document-based sync layer, built for cases where:

• You want to sync shared state across devices/users in real time.

• You don’t want to rely on central servers (e.g., chat, multiplayer, DAO tools).

• You want to grant access with a wallet signature — not username/password.

We agree IPFS has limitations at scale, which is why our architecture is pluggable. Storage backends can be IPFS, local disk, or S3-compatible systems — depending on the use case. What we care most about is that the interface is decentralized, composable, and portable, not locked into a single backend.

Think of it less as a replacement for Postgres, and more like a Firebase Firestore for Web3 — where developers can build collaborative, data-driven dApps using the same tools they love, but on their own terms.

We’re building for a different layer of the stack — but we definitely share the goal of giving developers superpowers.

[thewoodfish]

Thanks @thewoodfish sounds good to me, I'm personally willing to support it given the team's track record. I will mark the application as ready for review and ping the rest of the committee for comment.

Thank you very much @keeganquigley . We await their contributions.

[semuelle]

Hey @thewoodfish, thanks again for the application and sorry for the wait. I'm happy to see SwarmNL being put to good use. However, with the approximately 100k USD requested between SwarmNL and this, I would expect more of a connection to Polkadot beyond wallet login.

Have you identified any projects in the Polkadot ecosystem that would directly benefit from it or would be interested in using it? Have you talked to any Polkadot developers about Samaritan's pros and cons and how it could compete with or replace existing solutions?

[thewoodfish]

Thank you very much @semuelle. We're working on getting you the data and adequate feedback.

[thewoodfish]

Hi @semuelle ,
Thanks for the thoughtful feedback — and absolutely fair points.

While Samaritan initially included decentralized storage, we’ve intentionally narrowed the scope to focus on what we now see as a much more valuable and composable contribution to the Polkadot ecosystem:

What Samaritan is now:
A real-time backend layer for dApps that includes:

• Wallet-based auth (Polkadot.js, Ethereum)
• Live document sync (SwarmNL + CRDTs)
• Smart contract event listeners (Substrate/ink!)
• Function triggers that can both react to on-chain events and call back into smart contracts (a true two-way bridge)

This means any dApp or parachain team building off-chain dashboards, multiplayer tools, DAO infra, or workflows that depend on chain events can use Samaritan as a plug-and-play backend.
Projects building with ink! smart contracts are a prime audience, and we're also looking at integrations with identity pallets and chains like KILT and Litentry, where event-based workflows make sense.
Samaritan isn’t trying to replace anything native to Polkadot. Rather, it fills a critical off-chain gap

[thewoodfish]

@keeganquigley and @semuelle. We are waiting patiently for your feedback.
Thank you.

[keeganquigley]

thanks @thewoodfish will ping the committee again internally.

[keeganquigley]

@thewoodfish in the meantime can you please complete KYB verification for the Algorealm entity? Thank you!

[thewoodfish]

Thank you @keeganquigley. The KYB has been completed and submitted for verification.
Thank you!

[keeganquigley]

thanks @thewoodfish just emailed you regarding this.

[thewoodfish]

Thank you @keeganquigley. I have replied your mail as required.
Thank you!

[thewoodfish]

Dear sirs, @takahser and @semuelle . We patiently await your feedback and approval.
Thank you very much.

[Noc2]

Thanks a lot for the application, and sorry for the delay. It sounds like an interesting project overall, but my main concern is the product market fit and whether you will be able to create a successful business model. Who will be your customer, and have you already done some market research?

[thewoodfish]

Hi @Noc2 , thank you for your feedback. Your concerns are very valid and the answers are really simple 😀.

1. Product market fit.
   Honestly, right now, if a dApp team wants to react to what’s happening on-chain (like an NFT being minted or a DAO vote ending) and also push changes or actions back to the chain, they have to:

• Stand up their own backend server.
• Configure and write custom event listeners for Substrate.
• Host (or buy) a database and manage syncing.
• Glue everything together securely.

This is a lot of work for small teams or hackathon projects, and even established projects burn time on infrastructure that doesn’t differentiate them. Here are simple real application people build:

• NFT platforms – auto-generate an artist profile when their first NFT is minted, and push on-chain updates when they complete KYC or verification.
• DAOs – run off-chain tasks (like publishing a report) when a proposal passes, and post a status update back on-chain.
• Gaming – instantly update leaderboards when scores are submitted on-chain, and trigger reward payouts when milestones are reached.
• DeFi dashboards – update a user’s off-chain portfolio view as soon as their staking or swaps happen, and send on-chain alerts when thresholds are hit.
• Community tools – sync live collaborative docs (like a shared roadmap) for DAO members, gated by wallet address.
  Etc.
  I strongly believe the product market fit is strong because many Polkadot builders already need this, but they’re rolling their own messy version. Samaritan gives them a plug-and-play, Polkadot-native solution.
  More, it encourages people to build on Polkadot because of the ease and great dev experience. WE WILL FOCUS HEAVILY ON THE DEVELOPER EXPERIENCE AND THE EASE FROM SETUP TO DEPLOYMENT. With everything being modular, intuitive and easy to use, everyone will want to build on polkadot. It's a no brainer!

[thewoodfish]

Samaritan is built for teams in the Polkadot ecosystem that need a simple way to connect on-chain events with real-time off-chain logic—without running complex backend infrastructure. We have identified several parachain categories and real projects that would benefit directly:

NFT Platforms – Unique Network, Bit.Country

• Example: An artist mints an NFT → Samaritan listens to the event and automatically generates their off-chain profile and artwork preview.

• Value: Removes the need for these platforms to build their own event processing and sync systems.

DAOs – Astar Network, Talisman

• Example: A governance vote passes → Samaritan triggers off-chain actions like generating meeting minutes or updating a roadmap, then confirms back on-chain.
• Value: Enables automated DAO workflows without extra servers.

Gaming – Ajuna Network, Mythical Games

• Example: A player reaches a score threshold → Samaritan updates the live leaderboard instantly and triggers an NFT reward mint.
• Value: Gives games responsive real-time UX and keeps on-chain rewards in sync with gameplay.

DeFi Dashboards – Acala, Parallel Finance

• Example: A user stakes tokens → Samaritan updates their dashboard instantly and sets alerts to automatically protect collateral ratios via on-chain calls.
• Value: Improves UX with instant updates and automated risk management.

Community Tools – Phala Network, Litentry

• Example: Contributors edit a shared live doc → Samaritan syncs changes across all participants, and on milestone completion posts progress on-chain.
• Value: Bridges off-chain collaboration with on-chain accountability.

Why teams need this now
Most Polkadot projects already run a chain, a frontend, and an RPC layer—but lack a ready-to-use bridge for on-chain ↔ off-chain event flows. Samaritan fills that gap with:

1. Bi-directional contract triggers (on-chain events → off-chain functions, and vice versa)
2. Real-time collaboration tools powered by wallet-based identity
3. No vendor lock-in or central server reliance

This means parachain teams can launch richer, more interactive dapps faster, without building their own event listeners, function runners, or sync engines from scratch.

[thewoodfish]

Now to the business model which i find really cool because it opens up a world of possibilities:

1. Subscriptions
2. Plugin marketplace

Samaritan’s subscription model is straightforward:

• We host the service, so developers can start building right away without running their own backend (Ofcourse, there is a free tier e.g for hackathons teams)
• They pay a monthly fee for usage — like renting the “brains” of their Web3 app.
• Small teams might pay $5–$10/month to handle a few hundred users.
• Bigger apps handling thousands of events or logins could pay $100–$200/month.
• The more they use (events processed, functions run, plugins installed), the higher the tier — just like AWS or Firebase, but for Web3.

The plugin marketplace makes it even better:

• Think of it like an app store for Samaritan.
• Developers or parachains can buy ready-made plugins (governance alerts, token-gated content, NFT drop automation) instead of coding from scratch.
• They pay a small fee per plugin — $5 here, $10 there — which adds up across their app’s features.
• Plugin creators can also earn money by selling their tools in the marketplace, creating a self-sustaining ecosystem.

It is not a wish or rocket science. It can be done. It will be done.

[Noc2]

Thanks for the detailed reply here. I have just one additional question: Have you already talked to some of the teams/people that might use this product?

[thewoodfish]

You're welcome @Noc2 ,
Yes, and we’ve received two major points of feedback:

• Composable and efficient: Teams like that Samaritan removes the need for a heavy backend or duplicate updates on-chain and off-chain, making development faster and cleaner, especially because it can provide real time capabilities.

• Web2-friendly onboarding: Developers see it as a smooth entry point into Web3 and Polkadot. They can start building without deep blockchain expertise, and later integrate smart contracts without having to learn all the low-level details.