TECHNICAL CASE STUDY / BITCOIN LIQUID · ONCHAIN MEDIA

JungleLab · Liquid digital assets
A creator marketplace with ownership anchored to the Liquid Network.

A web-based platform for artists and collectors to publish digital work, issue Liquid assets, discover collections and trade peer-to-peer. The system connects media storage, token metadata, wallet functionality and transaction-level marketplace rules.

ROLECo-built with Adam from Raretoshi · Product and engineering
STATUSHistorical project · Platform closed after two years
DELIVERY EVIDENCE / ENGINEERING MATURITY

What reached the real world.

Delivered outcomes come first. The remaining categories show what is implemented, what has test evidence, what is deployed and what is still staged or planned.

DELIVERED

What reached users, operators or an upstream project — the outcome, not just the code.

  • JungleLab operated as a live marketplace during its historical two-year run; the platform is now closed
IMPLEMENTED

Capabilities evidenced in source code or project documentation.

  • SvelteKit/Vite marketplace with Hasura/PostgreSQL backend components
  • IPFS media content addressing and Liquid asset issuance linkage documented in the project README
  • Liquid wallet, peer-to-peer atomic swap and 2-of-2 signing-service workflows documented
TEST EVIDENCE

Automated test coverage or documented test evidence; not a blanket passing-build guarantee.

  • The repository includes Cypress as a development dependency; no passing test run is claimed here
DEPLOYED

Live product surfaces or historically operated deployments, with scope stated.

  • Historical platform operated as JungleLab and Raretoshi curated instances; both are presented as historical context, not current availability
PLANNED / STAGED

Known release boundaries, future work or areas not claimed as complete.

  • No current roadmap is represented; this is a retrospective case study of a closed platform
THE PROBLEM

Why this needed
to be engineered.

Digital creators need a way to publish media and prove which onchain asset represents it, while retaining a direct relationship with collectors. A marketplace also needs trading, wallet access and royalty rules without taking custody of user funds.

Connect a SvelteKit marketplace to a Hasura/Postgres data layer, IPFS media storage and Liquid Network issuance. Store the content identifier in the asset's issuance contract so the published artwork and token remain cryptographically linked. Use peer-to-peer atomic swaps and a constrained signing service for sales and royalty enforcement.

SYSTEM ARCHITECTURE

How the pieces fit together.

01

SvelteKit application for artist and collector profiles, discovery, listings and activity feeds

02

Hasura/PostgreSQL for relational application data and GraphQL access

03

JWT authentication through Hasura Backend Plus

04

Fastify Node.js service for application APIs and supporting integrations

05

IPFS for content-addressed media storage; CID derived from the media SHA-256 hash

06

LiquidJS wallet functionality, mnemonic backup/import and Liquid transaction construction

07

Liquid Asset Registry and Esplora integration for external asset recognition and chain data

08

Coinos API for BTC/Lightning to L-BTC conversion

09

2-of-2 signing service to enforce royalty and auction holding-period conditions

TECHNOLOGY CHOICES

Tools chosen for the job.

SvelteKitSvelteViteTailwind CSSPostgreSQLHasura GraphQLHasura Backend PlusFastifyIPFSLiquidJSEsploraLiquid Asset RegistryCoinos API
DECISION 01

Bind media to the issued asset

Uploaded media is stored on IPFS and receives a content identifier derived from its SHA-256 hash. That CID is embedded in the Liquid asset issuance contract, linking the token to the content.

DECISION 02

Use content addressing for media

IPFS provides a content identifier rather than relying on a mutable application URL as the artwork's identity.

DECISION 03

Keep trades peer-to-peer

Atomic swaps allow bids and sales to settle between users without requiring the platform host to escrow their funds.

DECISION 04

Enforce marketplace rules at signing

A 2-of-2 signing server only signs transactions that satisfy configured royalty and auction holding-period conditions.

DECISION 05

Make the wallet part of the creator experience

The web wallet supports L-BTC and Liquid assets, with backup and import using a 12-word BIP mnemonic.

ENGINEERING CHALLENGES

Problems solved along the way.

CHALLENGE 01

Verifiable media provenance

The application has to preserve the relationship between an uploaded artwork, its IPFS content identifier and the Liquid asset created to represent it.

CHALLENGE 02

Non-custodial marketplace flows

Peer-to-peer atomic swaps avoid the marketplace operator becoming the escrow holder for bids and sales.

CHALLENGE 03

Royalty and auction enforcement

The signing service adds transaction-level checks so royalty and time-lock conditions are enforced before a transaction is signed.

CHALLENGE 04

External wallet and asset interoperability

Publishing selected metadata to the Liquid Asset Registry helps external wallets recognise assets; Esplora provides chain data and Coinos supports conversion into L-BTC.

SOURCE & VERIFICATION

Inspect the work.

JungleLab was co-built by the user and Adam from Raretoshi over approximately two years. The platform has since closed, and the user moved on to other projects. This is a retrospective case study, not a live product. The codebase draws on the wider Liquid ecosystem; the case study distinguishes the product the team built from upstream components and dependencies. The repository package manifest identifies an early SvelteKit 1.0.0-next and Svelte 3-era stack.

NEXT / START A PROJECT

Have a similar challenge?

Tell me what you are trying to build. We can scope the right next step.