back
How Story Drives IP Authenticity
Story
15 April 2025
1. Problem Statement
Is a specific piece of IP legitimate?
This is the foundational question Story aims to answer.
Legitimacy is a form of digital scarcity; in IP, scarcity underpins value. As humans and AI generate and publish IP at an unprecedented scale, legitimacy becomes the signal that helps us distinguish originality from noise.
So, how do we define legitimacy in this new paradigm?
We believe legitimacy comes down to three core components:
- Origin
- Is the author verifiably who they claim to be?
- Was the method of creation as claimed?
- Originality
- Is the IP the result of original creation, or is it derivative or duplicative?
- Compliance
- Is the IP legal and culturally appropriate for public display?
While not exhaustive, these factors offer a practical foundation. If we can verify authorship, method, originality, and compliance, we can establish trust in the legitimacy of any IP. That trust becomes the bedrock for marketplaces, licensing, provenance, and attribution.
2. Solution
Overview
Story uses a decentralized, multi-layered system to validate IP legitimacy, built on two core components:
- The Story Attestation Service (SAS): SAS leverages a network of detection providers—each focused on different media types—to deliver publicly verifiable legitimacy signals. Applications can also submit their own attestations ("apptestations") to verify provenance. Optional KYC/KYB attestations are being considered.
- The Dispute Module: The Dispute Module offers a modular process for resolving IP conflicts—blending on-chain transparency with off-chain processes.
Together, they enable low-friction IP provenance and conflict resolution, supporting registration workflows while letting participants decide which attestations they trust.
These components form the IP Validation Service (IPVS), a decentralized marketplace for trust. We envision an expanding network of signal contributors—each offering verifiable, domain-specific assessments of IP.
Rather than blocking duplicates, which risks front-running, Story enables signal-based differentiation, helping legitimate IP surface organically.
Example Attestations by Legitimacy Component:
| Legitimacy Component | Attestation Example |
|---|---|
| Origin: Is the author who they claim to be? | KYC/KYB providers |
| Origin: Was the IP created in the way claimed? | Apptestations confirming provenance |
| Originality: Is this original work? | Infringement detection (e.g., Yakoa, Pex) |
| Compliance: Is this legal/appropriate to display? | Providers like Google NSFW classifiers |
Technical Component 1 – Backend
Story attestations operate in two phases:
- Off-chain verification: Querying detection providers to evaluate originality or infringement
- On-chain recording: Submitting the verified result to the blockchain for permanence
The system needs to be designed to handle:
- Polling the blockchain for key IP events (e.g., license attachment or remix)
- Process each event independently for off-chain verification – routing content to appropriate providers
- Managing failures and retries gracefully
- Persisting results for historical traceability
- Broadcasting successful checks to the blockchain
We use Temporal for reliable workflow orchestration, split into two primary flows:
Workflow 1: Infringement Check & Persistence
- Blockchain Polling: A dedicated Poller monitors the target blockchain via a cron job, fetching new blocks and scanning for relevant events from the IP Registry contract and License contract.
- Workflow Triggering: For each relevant event, the Poller initiates an "Infringement Check Workflow" via Temporal, passing the event data.
- Temporal Orchestration: Temporal schedules this workflow on available Workers.
- Worker Execution Activities:
- Data Prep And Enrichment: Extracts media details (identifier, type).
- Provider Interaction: Calls Yakoa (video/image) or Pex (audio) based on type. Handles API interactions and retries.
- Result Persistence: Saves the original event data and the infringement status to our database.
Workflow 2: On-Chain Attestation Broadcast
- Cron Job: Periodically poll the database for attestations ready to be broadcast.
- We only broadcast positive attestation, i.e., non-infringing IPs.
- Sign and Broadcast:
- Activity: Fetch Batch: Retrieve a batch of attestations ready to be broadcast onchain
- Activity: Broadcast Transaction:
- Connects to an RPC node
- Formats the batch transaction
- Securely retrieves the necessary private key for signing via Hashicorp Vault
- Signs the transaction with appropriate gas settings.
- Submits the signed transaction to the blockchain network.
- This activity includes robust error handling and retry logic managed by Temporal, which is crucial for dealing with blockchain network fluctuations, nonce management, and gas price issues.
- Polling for tx confirmation: update the database record with the transaction hash of the on-chain attestation.
This system is built for reliability, composability, and scale—ensuring robustness across Web2 and Web3 components.
Technical Component 2 – Smart Contracts
Attestations are anchored on-chain using the Ethereum Attestation Service (EAS), a permissionless protocol for creating and verifying attestations about any subject matter.
EAS provides two key smart contracts:
- SchemaRegistry.sol – allows anyone to define structured schemas for specific attestations.
- Mainnet:
0x5F983ab12EE78535C9067dE1CDFc7C511320fB7d - Aeneid Testnet:
0x2a3565551548abfcdeB9983230D9CAcBb8c6c16c
- Mainnet:
- EAS.sol – lets users publish attestations based on those schemas.
- Mainnet:
0x5bF79CECE7D1C9DA45a9F0dE480589ecCE1B48c8 - Aeneid Testnet:
0xDcd40C896274E7e9776A48deB0fA34999935Ee55
- Mainnet:
Both schema registration and attestations are fully permissionless—any application can define or use custom attestation formats.
Example: Creating an Infringement Attestation
Let’s walk through a real example of how a content validation provider attests that an IP is not infringing:
A new schema is registered via
SchemaRegistry.sol. See example tx.Schema ID:
0x9f898eca4ae41fb754e11c0062de5a4c6f35b52baa22df17bffa20a0d9fad28eExample schema fields:
address ipId, string ipUri, uint64 attestationDate, string providerName, string providerUrl, bool infringementDetected, string infringementDetails, string customData
Once a schema is created, the final step is to submit an attestation based on that schema. This involves interacting with the EAS.sol contract by invoking the
attest()function. The resulting transaction hash reflects an on-chain attestation made using the above schema.
Frontend applications can query EAS to display legitimacy signals, indicating whether a piece of IP has been flagged or verified as original.
This simple but flexible system allows developers to build customized trust layers directly into their user interfaces.
3. Current State
Current SAS Providers
- Yakoa: Provides AI-driven detection of visual duplication and forgeries
- Pex: Tracks unauthorized use of audio and video assets across the web
Current Metadata Requirements
To enable automated checks, IP creators must supply:
| Property Name | Type | Description |
|---|---|---|
mediaUrl | string | Direct URL to content (image/audio) |
mediaHash | string | SHA-256 hash of content |
mediaType | string | Type of media (audio, video, image), based on mimeType. See the allowed media types here. |
If these fields are missing, no infringement check is triggered.
Known Limitations
media.*fields must be set before commercial terms are applied(commercialUse = true)- Detection relies on already-known, indexed media
4. Plans for the Future
We are actively expanding SAS in three key areas:
1. Identity
- KYC/KYB oracle integrations
- Creator-to-social profile linking (Farcaster, Lens)
2. Infringement
- More media types: text, 3D, video
- Tiered providers: required vs. optional
3. Apptestations
- Apps can attest to:
- Creator identity and profile
- Whether IP was created inside the app
- The method/tooling used to create IP
Join as a SAS Provider
If you validate IP through detection, identity, or provenance, we’d love to collaborate.
