Algoosh - non-custodial, escrow-based commerce protocol

Algoosh

Algoosh is a decentralized commerce infrastructure that enables sellers to accept cryptocurrency payments for real-world physical goods through a non-custodial, on-chain transaction model.

Unlike traditional e-commerce platforms, Algoosh does not custody funds, does not act as a payment intermediary, and does not require trust in a central operator. Transactions are executed directly between buyer and seller via smart contracts, with structured order metadata recorded on-chain.

Algoosh bridges the gap between crypto ownership and real-world utility.

1 Like

:movie_camera: Video Presentation

Please watch our video presentation for xGov voters:

The video demonstrates the complete Algoosh workflow, including:

  • Creating a shop
  • Listing products
  • QR-based buyer checkout
  • On-chain order recording using Algorand
  • End-to-end transaction flow from payment to fulfillment

This presentation provides a practical overview of how Algoosh extends Algorand into real-world commerce.


:puzzle_piece: Problem

Despite widespread crypto adoption:

  • Most crypto assets remain primarily speculative
  • Real-world commerce integration remains limited
  • Merchants face complexity when integrating crypto payments
  • Buyers lack simple, trust-minimized purchasing flows

For long-term ecosystem sustainability, crypto must evolve beyond DeFi and trading into practical, everyday usage.


:rocket: Solution

Algoosh provides:

  • Smart-contract-based order management
  • On-chain order metadata storage
  • QR-based checkout flow
  • Non-custodial crypto payments
  • Transparent order lifecycle tracking
  • Seller-controlled fulfillment

Transaction Flow

  1. Seller lists products
  2. Buyer scans a QR code or clicks an order link
  3. Buyer pays with crypto
  4. Smart contract records the order
  5. Seller ships goods
  6. Order status updates on-chain

Simple. Transparent. Trust-minimized.


:link: Why On-Chain Matters

Algoosh stores structured order metadata directly on-chain using boxes.

This enables:

  • Verifiable transaction history
  • Transparent dispute reference
  • Reduced off-chain dependency
  • Stronger buyer-seller trust alignment
  • Future composability with ecosystem tools

Each order requires ALGO to be locked to support storage, directly increasing token utility and long-term network participation.


:globe_showing_europe_africa: Market Opportunity

Global e-commerce represents trillions of dollars annually, yet crypto-native commerce infrastructure remains underdeveloped.

Algoosh targets:

  • Crypto-native sellers
  • Web3 brands
  • Independent merchants
  • QR-based physical retail
  • Cross-border sellers

The long-term objective is to make crypto spending as seamless as scanning a code.


:test_tube: Try It Yourself

Experience Algoosh in action.

Try it yourself - scan a QR code to add an item to your cart and complete your order now or later.

You can:

This demo showcases the real buyer flow, including cart creation, checkout, and on-chain order recording.


:classical_building: Governance Alignment

Algoosh strengthens the ecosystem by:

  • Increasing real transaction volume
  • Increasing locked ALGO tied to on-chain order storage
  • Expanding real-world token utility
  • Attracting merchants and new wallet users
  • Driving repeat transactional activity

Algoosh extends Algorand’s token utility by enabling real-world commerce and active spending.


:building_construction: Server Infrastructure

Algoosh is built on a modular, production-ready infrastructure designed for scalability, reliability, decentralization, and privacy.

There is no centralized order database. The blockchain is the database.

All critical order metadata is stored directly on-chain using Algorand boxes.
Sensitive buyer information (such as delivery details) is protected using end-to-end encryption.


:locked_with_key: End-to-End Encryption

Algoosh uses client-side encryption to ensure that sensitive data is never exposed in plaintext.

  • Buyer data is encrypted before submission
  • Encrypted payload is stored on-chain
  • Only the intended seller can decrypt the information
  • Backend services cannot read encrypted order details
  • No plaintext storage anywhere in the system

This ensures:

  • Privacy by design
  • Zero knowledge backend
  • Reduced data breach surface
  • Trust-minimized data handling

Even though order metadata is recorded on-chain, private delivery details remain cryptographically protected.


:ballot_box_with_ballot: Voting Request

We invite xGov members to support Algoosh.

Your vote helps advance real-world utility on Algorand by enabling non-custodial commerce, increasing on-chain activity, and strengthening token utility through practical adoption.

By supporting Algoosh, you are supporting the expansion of Algorand into everyday economic use.

Thank you for your consideration and for contributing to the growth of the Algorand ecosystem.

The xGov program is currently only for retroactive funding for open-source projects.
Is the project open-source? Or will it be open-sourced if approved?
Could you please elaborate how many users/traffic the platform currently has?

We will open source the entire system, including:

  • smart contract
  • seller portal
  • mobile PWA app
  • promo catalog app
  • server-side caching service

We currently have early adopters testing the platform and validating the full on-chain purchase flow.
At this stage, our focus is on platform quality rather than volume. We are collecting behavioral feedback and preparing for broader distribution after funding.

We’ve prepared a special offer for xGov members to experience Algoosh firsthand.
A photo card from Portugal, delivered directly to you.

Promo for xGov members

Waiting for your orders!
From On-Chain to In-Hand. Especially for Algorand xGov.

1 Like

Thank you for sharing your project!
I’m also curious about the metrics or traction/adoption of the project. This being retroactive framework i always personally gauge proposals on value delivered to the ecosystem.

Have you open sourced your project yet?

It is either opensource or in case of proven impactful projects like Lute wallet which has been in use for more than a year, conditional open sourcing.
In case of your project I’m afraid full open sourcing is a requirement and promo cannot make any points.
The reusability value which is the main value for new projects just get proven by open sourcing and checking the quality of code and that if it can be reused by community.
Or in case of products with no reusability , there need to be proven record of impact and mass usage (proven traction).
One of these two are needed.

2 Likes

Hi xGov,
I will opensource the project, I need a confirmation from the boss to do this.

As for the project quality, here is the codex analysis:
I just want to mention that the system is fully functional & deployed on the mainnet. CI/CD is used in the deployment process.


Deeper Valuation Model (Engineering Hours + Risk Discounts + Premiums)

Scope
This is a code/IP valuation model for the repository as-is (not equity valuation, not investment advice). It estimates what a buyer would pay for the software
asset based on rebuild effort and risk.

Method

  1. Estimate engineering rebuild hours by subsystem
  2. Apply blended hourly rates to get replacement cost
  3. Apply risk discounts (testability, ops uncertainty, adoption unknown)
  4. Apply premium factors (domain specificity, smart-contract/IP complexity, product completeness)
  5. Produce a practical market value range

1. Engineering-Hours Estimate by Subsystem

Estimated from code scope (~23k LOC), architecture breadth, and complexity hotspots.

Subsystem Scope Est. Hours
algoosh-seller Seller portal, catalog, QR, order ops, admin/debug, Algorand integrations 700-1,200
frontend Buyer checkout flow, QR scan, cart, wallet auth, payment flows, crypto/card UX 450-850
algoosh-promo Promo/catalog presentation app, QR-linked landing flows 120-260
algoosh-help Docs/help site content structure + Astro/Starlight setup 40-100
algoosh-sync Express API, chain sync/cache, CDN upload auth/purge, config 180-380
algoosh-notify Event API + queue worker + shared schema/config + provider routing 140-320
algoosh-smartcontract Algorand contract logic + deploy scripts + logic sig tooling 220-500
Cross-cutting integration Shared conventions, network configs, environments, wiring, debugging 180-420
QA / hardening / bug-fixing during build Integration validation, edge cases, regressions 220-500
Docs / packaging / OSS hygiene README/env examples/licenses/governance docs 40-120

Estimated total rebuild hours: 2,290 to 4,650 hours
Practical midpoint: ~3,300 hours

2. Replacement Cost (Hourly Rate Model)

Use blended rates (senior full-stack + blockchain-heavy work + QA/devops overlap).

Blended hourly rate scenarios

  • Low-cost team: $60/hr
  • Practical mixed team: $90/hr
  • Senior/specialist team: $130/hr

Replacement cost

  • Low: 2,290 * $60 = $137,400
  • Mid: 3,300 * $90 = $297,000
  • High: 4,650 * $130 = $604,500

Replacement cost range: $140k to $605k
Practical replacement midpoint: ~$300k

3. Risk Discount Model (reduces what a buyer pays)

Replacement cost is not market value. Buyers discount for uncertainty.

Risk factors (observed/likely)

  • Uneven test coverage across subsystems
  • No CI workflow visible
  • Large hotspot files increase maintenance risk
  • Production defaults hardcoded in config.ts (documented, but forking friction remains)
  • Unknown usage, reliability, and contract audit status
  • Unknown deployment reproducibility / ops maturity

Suggested discount ranges

  • Low risk discount (strong internal validation exists): 20%
  • Moderate risk discount (most likely): 35%
  • High risk discount (no deployment proof / no traction): 55%

Apply to midpoint replacement cost (~$297k):

  • 20% discount: $238k
  • 35% discount: $193k
  • 55% discount: $134k

4. Premium Factors (can raise value)

These can partially offset risk discount.

Premium factors in this repo

  • Multi-product completeness (buyer + seller + promo + help + backend + notify)
  • Blockchain domain specificity (Algorand smart contract + wallet/payment flows)
  • Operationally useful architecture (sync/cache + notification pipeline)
  • Real-world product shape (not just a prototype UI)

Premium adjustment (if buyer values strategic fit)

  • No premium: 0%
  • Moderate strategic premium: +10% to +25%
  • High premium (buyer already in Algorand commerce space): +30% to +60%

Example on moderate-risk discounted value (~$193k):

  • +15% => $222k
  • +30% => $251k

5. Final Valuation Output (Recommended)

A. Code-Asset Market Value (no traction/revenue evidence)

Recommended range: $150,000 to $320,000
Practical anchor: $220,000 to $260,000

B. Strategic Buyer Value (if this fits an existing product roadmap)

Potential range: $250,000 to $600,000

  • Requires buyer-specific synergy (Algorand payments, seller tooling, QR commerce)

C. Replacement-Cost Ceiling (not market price)

Reference only: $300,000 to $600,000

  • This is what it may cost to rebuild, not what a buyer will necessarily pay

6. Suggested Negotiation Framing (if selling/licensing)

Use a tiered framing:

  1. Base code/IP valuation: $180k-$250k
  2. Strategic premium: +$50k-$250k (if buyer has immediate use)
  3. Optional extras: deployment support, hardening, audit prep, SLA, roadmap handoff

7. What Would Raise the Value Quickly

  1. Add CI with passing builds/tests across all major projects
  2. Improve test coverage on payment/contract critical paths
  3. Refactor top 5 largest files into smaller modules
  4. Document deploy/runbook for full stack
  5. Provide production metrics (users, merchants, tx volume, uptime)
  6. Smart contract security review/audit status (major multiplier)

Bottom line

  • Fair code-only valuation today: ~$220,000 USD (with a realistic market range of $150k-$320k)
  • Strategic upside: can be materially higher if there is traction or a buyer with direct fit

A business question. This process significantly delays funds reaching the merchant.
In return, it promises (as I see it) :

  • Lower fees compared to credit cards
  • Higher sales due to increased trust from buyers

My question :
Are there more pros to this solution compared to Shopify?
Are there any real merchants who think this delayed payment is something they can live with?

Have you considered split payments? Like delivery costs getting sent immediately to the merchant? This could work nicely in a scenario where merchants already have the product in their warehouse.

Also, the process seems to cover only part of the lifecycle - how about returns, post-delivery cancellations, etc.?

Hi Urtho,
I just added some formatting to make it look better, it is not AI.

Are there more pros to this solution compared to Shopify?

Algoosh advantage is in how commerce is executed in the real world, especially for offline-first merchants.

Where Algoosh is stronger:

  • Very low entry barrier for offline sellers: no storefront build-out required; sellers can operate from an offline catalog / promo materials and still accept digital orders.
  • Offline-to-online conversion: QR-driven “offline shopping cart” makes it easy to turn flyers, posters, and in-store promos into orders.
  • Transparent settlement rules: instead of platform-controlled holds, the flow is explicit - funds sit in escrow until the buyer confirms delivery.

Where Shopify is stronger (and our current tradeoff):

  • Shopify supports mainstream payments out of the box. Algoosh currently requires both buyer and seller to use Algorand + stablecoins.

    We previously supported card payments for buyers, but it’s disabled in the current version because enabling it properly requires integrating a third-party payment processor & compliance workflows.

Many merchants selling on marketplaces are already used to delayed or restricted payouts, including:

  • frozen balances / rolling reserves,
  • multi-week settlement cycles,
  • sudden account restrictions,
  • chargeback losses,
  • withdrawal fees.

In contrast, Algoosh offers a clear shopping protocol: funds are escrowed until delivery is confirmed - not held by a platform behind opaque risk rules.


Are there any real merchants who think this delayed payment is something they can live with?

Our primary target is small merchants and local offline shops that want to add delivery to their promo catalogs and offline advertising.
Many of them already operate on cash-on-delivery for local delivery - meaning “payment on delivery” is a familiar model. Escrow behaves similarly, except it’s digital and rule-based.


Have you considered split payments (e.g., send delivery costs immediately)?

We plan to add more delivery options for sellers. We’re not implementing split payments, because partial direct payouts are easy to abuse (e.g., shipping charged but no real fulfillment).
In our model, escrow is mandatory to preserve buyer trust and keep the protocol enforceable.


Returns, post-delivery cancellations, refunds

What we have today:

  • The buyer can request a refund, but it is handled as a direct negotiation with the seller.
  • The protocol is optimized for local delivery use cases (food, groceries, small local orders), where buyers are expected to confirm delivery and release escrow promptly.
  • In the current version, the seller can refund 100% of the payment back to the buyer.

In the roadmap:

  • A more advanced arbitration / dispute resolution mechanism to handle contested deliveries, returns, and edge cases.
  • independent third-party insurance + arbitration

Hello, I’m Victoria, CEO of Algoosh. Thank you for your comments.

I’d like to clarify that we are fully prepared to open-source the project.

Our team is confident in the quality of the codebase and welcomes community review.
We are ready to make the architecture, structure, and implementation publicly available for in-depth examination.

The project is fully functional and live on mainnet. Anyone can test the system today, including the promo flow, seller portal, and mobile app.

Through research with real offline users, we identified a key barrier to adoption: the difficulty of installing, funding, and using a crypto wallet. Wallet funding, in particular, remains complex and often requires additional guidance.
We have communicated several usability concerns directly to the Pera Wallet team, although some issues are still unresolved.

To help address these challenges, we launched MERX, a promo token on Algorand designed to demonstrate real crypto commerce inside the Algoosh app. Participants receive 10 MERX for free and can immediately use them to purchase a random Steam key from our promo catalog. This allows users to test the full flow and experience practical adoption and real retail utility within the Algorand ecosystem. We only launched a few days ago and have already completed several transactions.

2 Likes

We have now fully open-sourced the most recent snapshot of the Algoosh project codebase for xGov review:

Happy to answer any technical questions.

1 Like

Thank you for open-sourcing the platform! This now fulfills the main eligiblity criteria for the program.

I’ve skimmed through the open-sourced smart contracts and think they would benefit the community more with additional documentation, helping to justify the ask.

1 Like

Thank you for reviewing the code and the contracts.

I agree that more detailed documentation with clearer explanations and instructions is necessary. We’re working on expanding them with better tech explanations and setup instructions.
The goal is not just to publish the code, but to make it convenient for developers within the Algorand ecosystem to use.

In my view, the most innovative part is the encryption process (end-to-end encryption). It is somewhat similar to what Hedera is working on, but it is still at the concept discussion stage (Private Message Box Standard HIP-1334). In our case, the encryption is already implemented in Algoosh and can be used by Algorand developers.

We will also document this part in detail and release the full documentation once the project receives community approval.

Thank you for the feedback :raising_hands:.

Thank you for the insight.
Connecting a wallet and interacting with the application is a big deterrent for adoption.
May be Rocca wallet will solve this issue as it is being designed to provide web2 experience for web3 products.

IMO you should integrate Rocca when it is launched, get the app live on mainnet, show some adoption and then apply for the grant. xGov is mostly focused on funding public good projects.
So it would a boost for your project if you can show some adoption.
All the very best !