It’s surprising for a blockchain protocol being in production for several years already, that there are no existing, self-custodial solutions to integrate DOT as payments into any of the major eCommerce platforms.
Like, are we seriously talking about adoption when there’s no readily available tooling to sell material objects for DOTs?
We found it the hard way: we’ve allocated only a week for our shop.kampe.la to go live prior to us announcing Kampela DevKits preorders at Sub0. And we’ve barely made it — having to quickly hack a DOT payments processing system for OpenCart instead of our original plan of “nah, we just deploy the most-used of the existing ones” (there were none; neither there were any for Magento or Shopify).
With this application, we are proposing to fix this. We will build plugins for top 3 eCommerce SaaS platforms and top 5 FOSS eCommerce engines to support seamless and self-custodial DOT payments processing: set price in DOTs or use your platform’s currency converter (providing the exchange rates for that is out of scope for the current application), ask visitor’s wallet extension to sign the transaction (or just provide them an address to pay to if none found), wait for the transaction to finalize — and get your order marked as “paid” in the admin backend of your shop.
Development would require 16 weeks with a team of 4 developers: Rust Backend Engineer, JS/PHP/Ruby Frontend Engineer, an Integrations Engineer/DevOps, and UI/UX Designer.
All work results will be provided as FOSS-licensed repos on Github, with released artifacts being published in relevant plugin marketplaces if applicable — and verbose, easy to follow deployment instructions provided when there is none.
Our expectation is that enabling people receive DOTs as payment in eCommerce will have a positive (even if hard to predict under current market conditions) impact on adoption, while putting DOT in the same league with BTC and ETH (while being significantly more convenient due to short block times and deterministic finality) when it comes to receiving crypto payments without need for trusted intermediaries.
Our team has both the proven track record of shipping Treasury-funded projects in timely manner (Kampela 1 2 3 4, metadata project) and has already developed a first iteration (actually, more of an MVP) of the system for our shop.kamle.la storefront.
Instead of building a monolithic plugin, we use a two-component architecture: shop engine plugin and a separate payment processing daemon. This allows a high percentage of code reuse across multiple engines to support, while allowing us to leverage the preexisting logical flows in the shop engines (existing mostly to interact with TradFi payment providers via some external API).
The payment processing daemon is written in Rust and implements the pretty common “derive a unique address for each transaction” payment attribution pattern. Daemon is a self-contained application with zero external dependencies, capable of running in a container in case of a Docker/K8s deployment, and configurable via environment variables (12factor.net style).
The logical flow here is the following:
transactionID for it.⚠️ WARNING⚠️ Extension stores for SaaS platforms are fully controlled by their vendors. If the owners don't approve, we can't provide Kalatori plugins. However, we'll still publish all relevant sources on Github under an appropriate FOSS licence and leave it up to each individual SaaS customer to resolve their deployment issues with the vendor.
Milestone 1 (2 weeks): Publish first proof of concept store demo code (OpenCart)
Milestone 2 (8 weeks): FOSS-based stores implementations
Milestone 3 (6 weeks): Proper supply chain safeguards on all published code; SaaS implementations or proposals to overcome encountered blockers
Due to the easily parallelizable nature of the project, we anticipate all resources being evenly utilized throughout the project's duration.
Rust Backend Engineer: €18 800/month
Frontend Engineer: €17 100/month
Integrations Engineer/DevOps: €17 100/month
UI/UX Designer (part-time): €6 000/month
Total: €236 000
As usual with our treasury applications, the company receiving the funds is Alzymologist Oy, 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.
Edited 2023-11-03 renamed at requests of community, the internally used name "Kalatori" is silly indeed.
Edited 2023-11-04 As usual with our Treasury proposals, we're taking a carefully calculated and iterative approach. Therefore, adding support of AssetHub tokens (and USDC in particular), while definitely being on our radar — is out of scope for this pretty minimalistic "Iteration 1" proposal. Other things we're considering further down the road are supporting secondary assets (with automatic price conversions via some secure mechanism of fetching the exchange rates) and on/offramp integrations.
It’s surprising for a blockchain protocol being in production for several years already, that there are no existing, self-custodial solutions to integrate DOT as payments into any of the major eCommerce platforms.
Like, are we seriously talking about adoption when there’s no readily available tooling to sell material objects for DOTs?
We found it the hard way: we’ve allocated only a week for our shop.kampe.la to go live prior to us announcing Kampela DevKits preorders at Sub0. And we’ve barely made it — having to quickly hack a DOT payments processing system for OpenCart instead of our original plan of “nah, we just deploy the most-used of the existing ones” (there were none; neither there were any for Magento or Shopify).
With this application, we are proposing to fix this. We will build plugins for top 3 eCommerce SaaS platforms and top 5 FOSS eCommerce engines to support seamless and self-custodial DOT payments processing: set price in DOTs or use your platform’s currency converter (providing the exchange rates for that is out of scope for the current application), ask visitor’s wallet extension to sign the transaction (or just provide them an address to pay to if none found), wait for the transaction to finalize — and get your order marked as “paid” in the admin backend of your shop.
Development would require 16 weeks with a team of 4 developers: Rust Backend Engineer, JS/PHP/Ruby Frontend Engineer, an Integrations Engineer/DevOps, and UI/UX Designer.
All work results will be provided as FOSS-licensed repos on Github, with released artifacts being published in relevant plugin marketplaces if applicable — and verbose, easy to follow deployment instructions provided when there is none.
Our expectation is that enabling people receive DOTs as payment in eCommerce will have a positive (even if hard to predict under current market conditions) impact on adoption, while putting DOT in the same league with BTC and ETH (while being significantly more convenient due to short block times and deterministic finality) when it comes to receiving crypto payments without need for trusted intermediaries.
Our team has both the proven track record of shipping Treasury-funded projects in timely manner (Kampela 1 2 3 4, metadata project) and has already developed a first iteration (actually, more of an MVP) of the system for our shop.kamle.la storefront.
Instead of building a monolithic plugin, we use a two-component architecture: shop engine plugin and a separate payment processing daemon. This allows a high percentage of code reuse across multiple engines to support, while allowing us to leverage the preexisting logical flows in the shop engines (existing mostly to interact with TradFi payment providers via some external API).
The payment processing daemon is written in Rust and implements the pretty common “derive a unique address for each transaction” payment attribution pattern. Daemon is a self-contained application with zero external dependencies, capable of running in a container in case of a Docker/K8s deployment, and configurable via environment variables (12factor.net style).
The logical flow here is the following:
transactionID for it.⚠️ WARNING⚠️ Extension stores for SaaS platforms are fully controlled by their vendors. If the owners don't approve, we can't provide Kalatori plugins. However, we'll still publish all relevant sources on Github under an appropriate FOSS licence and leave it up to each individual SaaS customer to resolve their deployment issues with the vendor.
Milestone 1 (2 weeks): Publish first proof of concept store demo code (OpenCart)
Milestone 2 (8 weeks): FOSS-based stores implementations
Milestone 3 (6 weeks): Proper supply chain safeguards on all published code; SaaS implementations or proposals to overcome encountered blockers
Due to the easily parallelizable nature of the project, we anticipate all resources being evenly utilized throughout the project's duration.
Rust Backend Engineer: €18 800/month
Frontend Engineer: €17 100/month
Integrations Engineer/DevOps: €17 100/month
UI/UX Designer (part-time): €6 000/month
Total: €236 000
As usual with our treasury applications, the company receiving the funds is Alzymologist Oy, 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.
Edited 2023-11-03 renamed at requests of community, the internally used name "Kalatori" is silly indeed.
Edited 2023-11-04 As usual with our Treasury proposals, we're taking a carefully calculated and iterative approach. Therefore, adding support of AssetHub tokens (and USDC in particular), while definitely being on our radar — is out of scope for this pretty minimalistic "Iteration 1" proposal. Other things we're considering further down the road are supporting secondary assets (with automatic price conversions via some secure mechanism of fetching the exchange rates) and on/offramp integrations.
Threshold
Threshold