Edit 2024-03-08: Milestone 2

Frontend:

• https://github.com/Alzymologist/Kalatori-frontend (several engines)
• https://github.com/Alzymologist/Kalatori-solidus
• https://github.com/Alzymologist/KalatoriMagento

Backend

https://github.com/Alzymologist/Kalatori-backend two versions of daemon, for balances and assets based chains to be merged later

---

Edit 2024-01-24: Milestone 1

Frontend and backend minimal prototypes were updated to moderns state of chains and published.

---

This is a next iteration of our previous (failed) Referendum #228. We’ve incorporated the community feedback and updated our scope and roadmap accordingly. Please refer to that application for more background and motivation info, it stays the same between applications.

Kalatori (finnish kala + tori): fish market

There’s currently no ready to use tool to receive AssetHub tokens (or even “native” DOT/KSM) if you’re running an eCommerce application and don’t want to trust some third parties to just receive the payments on your behalf.

With Kalatori, we intend to fix that, and deliver to the community a set of free, opensource plugins for the major eCommerce engines which would allow shop owners to receive both AssetHub-powered and “chain-native” tokens in exchange for the goods/services they are selling, without having to trust their money to any intermediaries in the process.

Kalatori builds on top of our experience in building an (MVP-quality) payment processing for shop.kampe.la.

Following the feedback from the community, in this proposal we are adding support for the AssetHub-provided tokens, with stablecoin assets deemed sufficient by the Polkadot governance (USDT, USDC) being the primary focus here — since sufficiency adds an option to pay for the transaction fees with the asset itself, solving the infamous “second currency needed to pay the fees” UX problem.

After investigating our target audience more thoroughly, we’ve also decided to focus more on implementing the standards-compliant invoicing and reporting for crypto payments in the shops receiving payments with Kalatori — which is a non-trivial task, and otherwise might end up a big roadblock in Kalatori (and thus Polkadot) adoption.

Solution architecture

We keep the previously proposed design with the shared payment gateway daemon (in Rust) processing the payments in background, while exposing a tiny unified RPC layer for the shop plugins (in PHP) to communicate with. The major change in comparison with what we’ve been proposing in #228 would be extending the RPC semantics to allow the shop to indicate the currency to be used for payments — and extra some configuration options on the daemon’s side to give users control over which tokens on which chains do they want to support.

Costs, milestones and deliverables

The project is estimated to take 18 weeks and have total costs of €280,350. That breaks down into milestones as following:

Milestone 1: First store integration published.

OpenCart integration (and Kalatori payment gateway daemon) sources are published on Github.

2 weeks, €23,950

Milestone 2: All FOSS-based stores implementations are published.

Remaining plugins for FOSS engines (WooCommerce, Magento, PrestaShop, Solidus); packaged artifacts for deployment; installation documentation; production-grate test suite. We will also start talking to real-world shop owners about deployment and feedback.

6 weeks, €92,400

Milestone 3: SaaS implementations

SaaS eCommerce platforms plugins; we will aim to list Kalatori plugins in official extension stores, while documenting and publishing failed attempts.

6 weeks, €106,950

Milestone 4: Final touches

Internal security review, packaging for turnkey deployments, final bugfixes and tuning.

4 weeks, €57,050

For more verbose milestone timeline and costs breakdown please check out our this document.

FAQ

Haven’t you received some other grants for some other projects?

Yes, we’ve been granted funds by Treasury to develop both our Kampela project ([1], [2], [3], [4]) and associated metadata change RFC for Substrate ([5]). We’ve delivered everything we’ve promised in those grant applications, without missing a single deadline — and expect to continue this streak with Kalatori project as well.

Will you be able to ship?

We think so; our conduct working on Treasury grants (as well as teammembers’ prior reputations both within and outside of the Polkadot ecosystem) so far provides enough evidence to this confidence or ours.

Are you going to spend any effort on business development to see that this plugin actually going to get adoption?

Yes; this was one of the major takeaways for us from our previous application. We still don’t consider ourselves a commercially-driven business with a mature BD team (and would rather keep our engineering-first culture in the foreseeable future) — but we’ve allocated some resources to work on adoption of our solution, and will be covering the results in our milestone reports. We’re also looking forward to collaborating with other ecosystem actors on further promoting Kalatori and its integrations.

Aren’t you just developing something to help you sell your Kampela devices?

For https://shop.kampe.la we’ve indeed developed an MVP of the Kalatori project (please go and check it out) — and learned a lot from building and deploying it in production. We’re happy with that solution as it is now — but the codebase would need some additional work to be ready for use by others (both in terms of removing hardcoded constants, improving tests coverage, writing documentation and building and packaging the artifacts) before being ready for public release. This is exactly what we’re going to do as our Milestone 1. There’s no retroactive funding in our application.

Would shop owners be capable of deploying this additional Rust daemon?

This is a legitimate question — in absence of a centralized third party deploying one’s own payment gateway is an extra step which is not common. And in some sense, that’s exactly the point, since most competing solutions are custodial, while we’re trying to empower self-sovereign individuals to handle their own transactions and keys. While some friction here would be inevitable, we are planning to minimize it as much as possible by providing publicly available Docker images, Kubernetes manifests and one-click deployment buttons for some of the major infrastructure providers.

What would happen if a SaaS eCommerce platform won’t allow you to publish Kalatori in their proprietary plug-in store?

Unfortunately, we have no control over large international eCommerce corporations, so we couldn’t have committed to anything which would include their actions. We believe that being a legitimate EU-registered company in good standing would give us enough legal leverage to at least try to object to them refusing Kalatori from their markets — but if it goes to the legal battles, no way we’re going to afford those on our own as a business. We would thoroughly document and publish all our interactions, though, preparing the grounds for Polkadot community taking an action there as a whole.

Are you committed to be maintaining this code after the grant work is over?

We would definitely maintain the code, review the PRs and fix the security issues as soon as we learn about any — we’re planning to maintain our standing as a reputable engineering player in the Polkadot space after all. We cannot promise to be active in developing new features for the project without extra funding, though. But if there will be a need for some additional features in the community, either us or any other party can apply for another Treasury grant to extend Kalatori with those — it’s a publicly available, FOSS-licensed software, after all.

Is there going to be a custodial SaaS solution to act as an alternative self-hosted non-custodial Kalatori installations?

In this proposal we’re aiming strictly at providing a non-custodial, self-sovereign solution for processing payments with Polkadot. At the same time, it seems possible to build a custodial SaaS platform implementing the same APIs (and even reusing our existing codebase and plugins), so there might be a market opportunity to anyone who would be willing to take on the risks and responsibilities of doing so in safe and regulations-compliant manner.

How secure is your gateway daemon?

The codebase of the daemon is written in Rust, and we are planning to employ all the tools (including all kinds of testing and fuzzing) and engineering capabilities (and our Rust team consists mostly of ex-Parity engineers) at our disposal to maintain its security. We will conduct a full internal security review of the codebase and publish the results. Unfortunately, we wouldn’t be able to afford any third-party security audit for Kalatori without tripling the price tag of this grant application — but we would be happy to collaborate with any parties interested in funding such an initiative, outside of the work outlined in here.

About us

Alzymologist Oy is a registered Finnish company (Business ID: 3162030-9). All personnel listed above would be directly employed by Alzymologist Oy, and all relevant Finnish taxes are already included in the figures.