Onboarding design partners
The operating platform for regulated cannabis retail.
Point of sale, inventory, compliance, commerce, and payments on one operating layer — built for retailers whose store does not reduce to a cart and a catalog.
- One canonical checkout shared by web and native iPad
- Package-level inventory from receiving to sellable stock
- Tenant and location isolation enforced in the data layer
- Durable event streams, not just a reporting export
Cart
Why it is built this way
Three things most cannabis POS platforms cannot say.
Every vendor claims reliability and compliance. These are the specific, checkable versions of those claims.
The register does not stop
Offline-first is an architecture, not a fallback screen. Carts, tenders, and inventory writes queue on the device and reconcile automatically when the connection returns.
Read moreAn audit trail you can verify
Events are canonicalized, Merkle-rooted, signed, and chained to the previous anchor. Verification recomputes the root — you do not have to trust that the history is intact.
Read moreCompliance decided, not reported
Purchase limits evaluate through a deterministic, versioned ruleset at the moment of sale, with the reason recorded on the transaction.
Read moreLocal resilience
Never lose a sale to a dropped connection.
The register keeps working when the internet does not. Every operation queues locally and reconciles cleanly on reconnect — and local hub services keep pairing and printing alive in the meantime.
- Sale #4821synced
- Inventory adjustsynced
- Cash dropsyncing
- Sale #4822queued
Reconciling 4 operations · no data loss
- ANCHOR 0041214:02:11Zevents1,284 eventsprev root6b81…dd03merkle root9f2c…a417
- ANCHOR 0041314:32:11Zevents1,097 eventsprev root9f2c…a417merkle rootc740…1e9b
- ANCHOR 0041415:02:11Zevents1,411 eventsprev rootc740…1e9bmerkle root3ad5…77f2
Compliance
Evidence a regulator can check without trusting us.
Audit events are canonicalized to a stable encoding, hashed into a Merkle root, signed, and linked to the previous anchor. Verification recomputes the root independently and reports a mismatch rather than a pass.
Commerce
One catalog behind every surface a customer sees.
Your online store, your in-store screens, and the marketplaces you list on all read the same catalog and the same live sellable position — so a sold-out item is sold out everywhere.
- Online storein sync
- In-store menusin sync
- Marketplacesin sync
- Registerin sync
Built for your operation
One store and five stores do not fail the same way.
The platform is the same. The problems worth solving first are not.
Single-store operators
Run the whole store without a back-office team.
- Reconciling the drawer and the system takes longer than it should
- Purchasing decisions are made from memory and a spreadsheet
Multi-location retailers
Compare stores honestly and move stock between them.
- Each store has drifted into its own way of naming and counting things
- Transfers between locations lose fidelity somewhere in the middle
Scaling operators
Integrate deeply and keep your own systems.
- Vendor reporting does not answer the question you actually asked
- Getting raw transaction data out is an export, a wait, and a CSV
Where we are
Onboarding design partners.
SMOKESTACK is pre-general-availability. We are working directly with a small group of retailers to harden the platform in live operations before broader release. There is no self-serve signup, and demos are run by our team in a dedicated demo environment rather than handed out as a sandbox. If you are running a dispensary and want to shape what this becomes, that is exactly who we want to talk to.
Talk to the teamQuestions
The awkward ones, answered.
If the answer is no, we would rather you read it here than find out on a call.
Can I sign up and start using it today?
No. SMOKESTACK is pre-general-availability and we are onboarding a small number of design partners directly. There is no self-serve signup, and we would rather tell you that here than after a demo.
How do demos work?
Demos are run by our team in a dedicated demo environment, on a call. We do not hand out a self-serve sandbox, because a cannabis retail platform shown without context tends to answer the wrong questions. Book a time and we will walk through the workflows that match your operation.
What does the register do when the internet goes down?
It keeps selling. Carts, tenders, and inventory writes queue locally on the device, and local hub services keep pairing and printing available. When connectivity returns, queued operations sync and reconcile automatically.
Which states are supported?
Purchase-limit rules are implemented as versioned, testable rulesets per jurisdiction. New Mexico is implemented today. Adding a jurisdiction means authoring and testing a ruleset rather than modifying the platform, which is the part that determines how quickly we can support yours.
What makes your audit trail different?
Audit events are canonicalized to a stable encoding, hashed into a Merkle root, signed, and chained to the previous anchor. Verification recomputes the root independently, so tampering shows up as a mismatch. You do not have to take our word that the history is intact — you can check it.
See it running on real workflows.
Demos are run by our team in a dedicated demo environment, walked through live on a call — so you see the parts that matter to your operation, not a generic tour.