FAQ

"Is on-chain IP real?"

Story isn't replacing the legal system, it's providing on-chain rails to make the legal system more efficient for creative IP.

We have worked with world class legal teams to craft a real, off-chain legal contract called the Programmable IP License (PIL💊) that has simple terms allowing creators to state who can remix, monetize, and create derivatives of their IP and at what cost.

We've then built business logic on-chain (in the form of smart contracts) to automate & enforce those terms. This creates a tight mapping between the legal world and our on-chain terms.

"My asset is off-chain. How do I register it as IP on Story Protocol?"

You would mint an NFT that represents your off-chain asset, and register that NFT on Story.

"I am selling an off-chain asset (eg. merch). How do I make sure that automatic royalty flow is enforced?"

Automatic royalty flow can be enforced off-chain. Although the royalty infrastructure is on-chain, the associated license is valid beyond the chain. To legally abide by the license any derivative work will need to pay royalties on-chain to the IP Account that is attached to your IP Asset, or face consequences like in the real world (e.g. being taken to court for abusing a license) according to the terms set out by the license.

Furthermore, one of the terms of the Programmable IP License (PIL💊) is that licensees are obligated to provide revenue data for off-chain transactions (e.g. merch) to licensors, if there's a revenue share involved.

"What is a simple example?"

Before Story, if you wanted to create a comic with someone else’s Azuki NFT and your Pudgy NFT, you would first need to hope the Azuki has a license and then find & contact the owner. You would also need to research your license terms for your Pudgy. Since you’re not a legal expert, you would probably need a lawyer to create a new contract between the two IPs. This creates a burden on anything ever getting created legally, because few people have the time, expertise, or money for that except large studios. Thus IP is not easily composable.

With Story, Azuki & Pudgy holders can register their IP as IP Assets and then set terms - using the PIL - outlining how people can license and remix their IP. If your Pudgy is registered on Story, anyone can see those terms on-chain and license your Pudgy automatically using the licensing module, which generates a real license agreement. You can then register the resulting comic as a derivative, and any revenue that flows in can be distributed between you and the IP holders automatically.

"What are the challenges?"

The natural question arises: "What if I'm a bad actor and I ignore all of this and just Right Click Save As?"

First, its underestimated the extent to which people want to follow the law. This is why PIL is so important - all of the
IP is not just on-chain, it is tied to a real legal contract! If people rip off your IP, they can be sued in court. However this "happy path" doesn't always happen. When things go wrong, we want to provide as many layers of escalation before resorting to off-chain arbitration.

Thus, we've created the Dispute Module that allows anyone to flag violating content on-chain. If the dispute is
successful, that IP will be flagged and no longer able to monetize or generate licenses.

The worst case scenario on Story is the best case scenario anywhere else: legal arbitration. Creators using us can always use the traditional legal system as a backstop. This is a situation we want to avoid, but one that's necessary for creators to have trust in the system.

"Why does this need to be its own L1?"

There are a few reasons we decided - or rather were forced - to build an L1:

• Improved graph traversing for efficient IP graph search, written directly in the execution client. Other L1s are simply not able to handle 1000s of parents with complicated licensing & royalty details in one transaction efficiently.
• Max composability by having license data on-chain, allows for 100s of IPs to remix at once.
• Potential rollup support with bespoke X-CHAIN data (e.g. Initia's model) for Web2 apps with millions of transactions requiring rollups. Also support Web2 apps running their own validators for max incentive alignment.
• Future roadmap for tokenization of IPs on Story Network (more info to come).
• EVM equivalence for Solidity dev.

And finally...

• Future validator-enshrined L1 tech like native oracles for NFTs and off-chain RWA IPs (Cosmos SDK vote extensions).

"Why is Story making improvements at the validator level?"

The alternative is running an adjacent system outside the L1 to provide these features, which will strictly be less decentralized than the L1 itself. By making these features native to L1 (validators), we can have sufficient decentralization, guaranteed execution, and less system to maintain.

Namely, if the adjacent system goes down (so disputes and oracles stop) but the L1 works fine, it'd be a huge problem. This can be remedied with re-staking like AVS but the tech is not battle-tested and there's no precedence of success using re-staking (EIGEN token is still in work).

One big incentive alignment Story can have: IP companies running validators & providing custom off-chain IP data to the network natively via validator-enshrined features.

Or a law firm automating disputes and broadcasting them to other validators. After an agreement of disputes, validators can immediately block transactions that include disputed IPs, which is not possible with an adjacent system providing (unless we have preconf, which is a debated topic in the Ethereum land).

"You mention needing an L1 to improve upon the efficiency of an IP graph. Why not build an L2 with off-chain graph indexing?"

The IP graph must be on-chain because certain on-chain features require the ability to traverse and aggregate the IP graph. For example, royalty and revenue distribution need to occur on-chain through the IP graph. Using off-chain graph indexing would make these on-chain features either unfeasible or overly complex, as it would necessitate involving an oracle.

Similarly, the dispute module can check if an IP has been flagged due to its ancestor being flagged by traversing the IP graph directly on-chain, and then take immediate action such as aborting a transaction that would license a disputed IP without the need of an oracle.