Story Protocol
Do you know why your local radio station can play any song you request, without having to negotiate each time?
Answer: statutory licensing. If the station pays a fee, they can play the song.
Imagine we had that flexibility for everything.
That's the Story Protocol's promise.
Our tech keeps improving, and this is our best tour pack yet. Get ready for a real shortcut to deep understanding.
Grand overview of Story's "Proof of Creativity" Protocol: IPAssets are owned by IPAccounts, which are manipulated by several Modules and organized by Registries. With an AccessControl system spread throughout.
Each IPAsset is an on-chain NFT. But it's not that simple:
IP assets are NFTs. They are tracked by IP accounts. But all are counted in the central IPAssetRegistry.
If you have ownership of some IP, then you have the NFT. That NFT gets its own account. An IPAccount. Not the account of IP you have the IP is the account! And it can have its own NFTs.
We don't have any example IPAccount implementations in this repo.
Of the general interface: there is some boilerplate. But the main thing of interest is that they also let you execute functions as the account.
Next are modules. Each module does a lot of stuff, but there's not much to say about the module interface in general.
There is, however, a centralized registry of all modules.
Finally, there's the access control system.
It's pretty powerful. It assigns permission for a particular account to call a particular function on a specific contract. You won't see much in the way of onlyOwner or onlyTreasurer modifiers in this protocol. Nope. The magic restricted modifier does everything.
Now let's look at Story Protocol's ModuleRegistry.
The ModuleRegistry tracks the mapping from the module name to its address, from the address to its type, and from the type to a 32-bit hash of the interface.
There are functions to register a module and check if it's registered, as expected.
Most code deals directly with specific modules, and thus has no need for the ModuleRegistry.
So really the purpose of this function... and effectively the main functionality of this entire contract is to stop people from trying to use the AccessController to control interactions between two non-modules.
What makes the Story Protocol's chain different from all other chains?
It has a built-in graph DB. Can trace derivative IP of derivative IP.
I've found no documentation of the IP_GRAPH precompile. Fortunately, we can glean a lot by looking at the code.
The first method is getAncestorIpsAccount. Each IP NFT has an associated IPAccount address. Give it that address; learn just how many works it transitively draws from. If that IP account is an image generation AI model, then this is the corpus size. Glad to not compute that on-chain.
Next is hasAncestorIp. Takes two addresses; checks if one is a derivative of another I think there's a line from a Disney Princess pen back to Steamship Willy, but a long one. Again, glad not to run that in Solidity.
The IP_GRAPH has edges. These edges are labeled with weights for royalty percentages. The royalty percentages have two types: Liquid Absolute Percentage, and Liquid Relative Percentage. There's a setter for these weights.
Finally, you can check whether a parent edge exists with hasParentIp. Presumably, this is the non-transitive version of hasAncestorIp.
And that's it! There's more where that came from. Check out the complete Story Protocol audit pack:
