Rough system diagram
Marketplace of decks
reading experience
card draw
deck view

Unfortunately there has been a breaking change with the attempted integration of Subwallet support.

We will work to migrate this project off of the current solidity and moonbeam set up to correct for the breaking change.

At this time the core functionality of project is offline.

tl;dr

I built a DRM-friendly ERC-1155 styled content-access pass system that enables digital creators (starting with tarot deck artists) to monetize their work through standardized, interoperable content passes. Apps can load encrypted content using on-chain proofs of access, and multiple stakeholders (artists, app developers, curators) can be compensated fairly via smart-contract incentives.

The Journey

I entered this project with no wallet, no smart-contract experience, and only a hunch:
digital tarot cards should exist, and blockchain might solve the problems that kept them from thriving.

Despite a strong community of tarot collectors and a steady flow of talented artists, digital tarot decks have never had a sustainable operating model. I personally know people (artists and collectors) who would benefit from a healthier digital ecosystem.

As I dug deeper, a pattern emerged:
ERC-1155–style content access passes could form the basis of a blockchain-native DRM system.
This lets artists mint access tokens for their work while letting applications load and interpret that work consistently.

Although my first use case was tarot decks, the model generalizes well to ebooks, audiobooks, comic books, and all of the digital goods I don't have familiarity with(music sample packs?).

For this POC, I focused on tarot 🃏

How It Works

Authoring Content

A creator uses the contract to define a “content item” with three core URIs (stored off-chain via IPFS/Arweave or, for the demo, local assets):

Payload URI – the encrypted content itself
Public manifest URI – metadata, presentation details, thumbnails, “book cover”
Handling specification URI – a schema that tells apps how to use the payload (e.g., tarot deck spec, EPUB spec)

This structure lets any compatible app discover how to interpret and render the content.

Minting & Using Passes

Once the content item exists, consumers can buy or claim access passes.

Apps can then:

Check the user’s on-chain pass
Fetch the encrypted payload
Decrypt and load it into the app’s context

For tarot, this enables apps for:

mobile daily-reading journals
AR tarot experiences
multiplayer or social reading platforms
anything a developer wants, backed by an ecosystem of artists

By standardizing this pipeline, creators get reliable monetization while developers get plug-and-play content.

Multistakeholder Incentives

While exploring smart-contract patterns, I learned I could implement:

Affiliate/referrer rewards
Treasury fees

These support:

apps integrating in-app purchases
platform sustainability (storage, encryption services, ecosystem growth)
community-driven funding for new features or standards

Everyone participating in the value chain can be compensated fairly.

Looking Forward

Potential

This approach can empower small creators, especially niche or independent artists, to earn meaningful income from digital content without relying on centralized platforms.

Work Ahead

On-chain

Migrating contract logic to ink!
Deploying to Paseo testnet and prepping for Polkadot mainnet
Improving efficiency and simplifying creator setup flows

Off-chain

Refining the tarot deck handling specification with real community input
Hardening the encryption/decryption workflow
Building developer-friendly tools for content ingestion and validation

Appreciations & Asks

I’m incredibly grateful for the Polkadot community. Especially the folks I met in Toronto! I’ve only been involved for about 10 days, and the support and encouragement have been amazing.

I’d love feedback on: