From 99d3d25d3c8ff3f1e0ada86bc3a6a68a261ba0f4 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Tue, 31 Dec 2024 00:36:23 +0300 Subject: [PATCH 01/10] =?UTF-8?q?=D0=9D=D0=B0=D1=87=D0=B0=D0=BB=20=D1=80?= =?UTF-8?q?=D1=83=D1=81=D1=81=D0=BA=D0=B8=D0=B9=20=D0=BF=D0=B5=D1=80=D0=B5?= =?UTF-8?q?=D0=B2=D0=BE=D0=B4=20=D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0=BD?= =?UTF-8?q?=D1=82=D0=B0=D1=86=D0=B8=D0=B8=20Story?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/Concepts/ip-asset/index.md | 59 +++++++++++++++++---------------- docs/Concepts/overview.md | 43 +++++++++++++++--------- 2 files changed, 57 insertions(+), 45 deletions(-) diff --git a/docs/Concepts/ip-asset/index.md b/docs/Concepts/ip-asset/index.md index 7854311..96c4d0e 100644 --- a/docs/Concepts/ip-asset/index.md +++ b/docs/Concepts/ip-asset/index.md @@ -10,50 +10,51 @@ metadata: next: description: '' --- -> 🐦 Skip the Read +> 🐦 Читать не обязательно > -> Get a quick 1-minute overview of IP Assets [here](https://twitter.com/jacobmtucker/status/1785765362744889410). +> Краткая 1-минутная выжимка про IP-активы тут [here](https://twitter.com/jacobmtucker/status/1785765362744889410). -IP Assets are the foundational programmable IP metadata on Story. Each IP Asset is an on-chain ERC-721 NFT (representing an IP). Yes, that means your Azuki or Pudgy Penguin is already eligible for registration into our protocol, and don't worry, there is no wrapping involved. +IP-активы - это основополагающие программируемые IP-метаданные в Story. Каждый IP-актив - это ERC-721 NFT (представляющая IP). Да, это означает, что ваш Azuki или Pudgy Penguin уже может быть зарегистрирован в нашем протоколе, и не переживайте, никаких обёрток. -If your IP is off-chain, you would simply mint an ERC-721 NFT to represent that IP first, and then register it as an IP Asset. +Если ваша IP находится вне цепочки, вы просто сначала минтите (анг. mint) ERC-721 NFT для представления этой IP, а затем регистрируете её как IP-актив в Story. -An IP Asset also has an associated [IP Account](doc:ip-account), which is a modified ERC-6551 (Token Bound Account) implementation. It is a separate contract bound to the IP Asset for controlling permissions around interactions with Story's modules or storing the IP's associated data. +IP-актив также имеет связанный с ним [IP Аккаунт](doc:ip-account), который представляет собой модифицированную реализацию ERC-6551. Это отдельный контракт, связанный с IP-активом для контроля разрешений на взаимодействие с модулями Story или хранения связанных с IP данных. -## Registering an IP Asset +## Регистрация IP-актива -An IP Asset is created by registering an ERC-721 NFT into Story's global [IP Asset Registry](doc:ip-asset-registry). +IP-актив создается путем регистрации ERC-721 NFT в глобальном [Реестре IP Активов] Story (doc:ip-asset-registry). -If you'd like to jump into code examples/tutorials, please see [How to Register IP on Story](doc:how-to-register-ip-on-story). +Если вы хотите перейти к примерам кода/учебникам, пожалуйста, посмотрите [Как зарегистрировать IP в Story](doc:how-to-register-ip-on-story). -## NFT vs. IP Metadata +## Метаданные NFT vs IP -On Story, your IP is an NFT that gets registered on the protocol as an IP Asset. However, both NFTs and IP Assets have their own metadata you can set, so what's the difference? +В Story ваша IP - это NFT, которая регистрируется в протоколе как IP-актив. Однако и у NFT, и у IP-активов есть свои метаданные, которые вы можете установить сами, так в чем же разница? -| | Standard | What is it? | + +| | Стандарт | Что это? | | :------ | :------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **NFT** | [Standard ERC721 NFT Metadata](https://github.com/ethereum/ercs/blob/master/ERCS/erc-721.md) | Things like name, image, collection info, etc | -| **IP** | [IPA Metadata Standard](doc:ipa-metadata-standard) | More specific to Story, this includes information about the author of the work, its relationship to other works, attributes like app-specific metadata & AI remixing attributes, etc | +| **NFT** | [ERC721 Стандарт Метаданных](https://github.com/ethereum/ercs/blob/master/ERCS/erc-721.md) | Имя, картинка, информация о коллекции etc | +| **IP** | [IPA Стандарт Метаданных](doc:ipa-metadata-standard) | Более специфичные для Story данные, например информация об авторе работы, его связи с другими работами, атрибуты, такие как метаданные для конкретных приложений и атрибуты ремикширования AI, и т. д. | -All other metadata, such as the ownership, legal, and economic details of an IP Asset are handled by our protocol directly. For example, the protocol stores data associated with parent-child relationships through the [📜 Licensing Module](doc:licensing-module), the monetary flow between IP Assets through the [💸 Royalty Module](doc:royalty-module), and the legal constraints/permissions of an IP Asset with the [💊 Programmable IP License (PIL)](doc:programmable-ip-license). +Все остальные метаданные, такие как сведения о собственности, юридических и экономических аспектах IP-актива, обрабатываются нашим протоколом напрямую. Например, протокол хранит данные, связанные с отношениями между родителями и детьми (анг. parent-child), через [📜 Модуль Лицензирования](doc:licensing-module), денежные потоки между IP-активами через [💸 Модуль Роялти](doc:royalty-module), и юридические ограничения/разрешения IP-актива с помощью [💊 Программируемой IP Лицензии (PIL)](doc:programmable-ip-license). -### Adding NFT & IP Metadata to IP Asset +### Добавление метаданных NFT и IP к IP-активу -> 📘 Working Code Example +> 📘 Пример кода > -> To see how to implement proper metadata for the NFT & IP, in both the SDK and smart contracts directly, check out [How to Register IP on Story](doc:how-to-register-ip-on-story). +> Чтобы увидеть, как правильно реализовать метаданные для NFT и IP, как в SDK, так и в смарт-контрактах напрямую, ознакомьтесь с [Как зарегистрировать IP в Story](doc:how-to-register-ip-on-story). -In practice, whether you are using the SDK or our smart contract directly, our protocol asks you to provide 4 different parameters: +На практике, независимо от того, используете ли вы SDK или наш смарт-контракт напрямую, наш протокол просит вас предоставить 4 различных параметра: -* View the `WorkflowStructs.sol` contract [here](https://github.com/storyprotocol/protocol-periphery-v1/blob/main/contracts/lib/WorkflowStructs.sol). +* Посмотреть контракт `WorkflowStructs.sol` [здесь](https://github.com/storyprotocol/protocol-periphery-v1/blob/main/contracts/lib/WorkflowStructs.sol). ```sol WorkflowStructs.sol -/// @notice Struct for metadata for NFT minting and IP registration. -/// @dev Leave the nftMetadataURI empty if not minting an NFT. -/// @param ipMetadataURI The URI of the metadata for the IP. -/// @param ipMetadataHash The hash of the metadata for the IP. -/// @param nftMetadataURI The URI of the metadata for the NFT. -/// @param nftMetadataHash The hash of the metadata for the IP NFT. +/// @notice Структура метаданных для минта NFT и регистрации IP. +/// @dev Оставьте nftMetadataURI пустым, если не минтите NFT. +/// @param ipMetadataURI URI метаданных для IP. +/// @param ipMetadataHash Хэш метаданных для IP. +/// @param nftMetadataURI URI метаданных для NFT. +/// @param nftMetadataHash Хэш метаданных для IP NFT. struct IPMetadata { string ipMetadataURI; bytes32 ipMetadataHash; @@ -62,7 +63,7 @@ struct IPMetadata { } ``` -* `ipMetadataURI` - a URI pointing to a JSON object that follows the [IPA Metadata Standard](doc:ipa-metadata-standard) -* `ipMetadataHash` - hash of the `ipMetadataURI` JSON object -* `nftMetadataURI` - a URI pointing to a JSON object that follows the [Standard ERC721 NFT Metadata](https://github.com/ethereum/ercs/blob/master/ERCS/erc-721.md) -* `nftMetadataHash` - hash the `nftMetadataURI` JSON object \ No newline at end of file +* `ipMetadataURI` - URI, указывающий на JSON-объект, соотвествующий [IPA Стандарт Метаданных](doc:ipa-metadata-standard) +* `ipMetadataHash` - хэш JSON-объекта `ipMetadataURI`. +* `nftMetadataURI` - URI, указывающий на JSON-объект, который следует [ERC721 Стандарт Метаданных](https://github.com/ethereum/ercs/blob/master/ERCS/erc-721.md) +* `nftMetadataHash` - хэш JSON-объекта `nftMetadataURI`. \ No newline at end of file diff --git a/docs/Concepts/overview.md b/docs/Concepts/overview.md index f6d90e9..6c30db1 100644 --- a/docs/Concepts/overview.md +++ b/docs/Concepts/overview.md @@ -10,28 +10,30 @@ metadata: next: description: '' --- -Story's "Proof-of-Creativity" protocol introduces a revolutionary open **Programmable IP layer**, elevating IP to a first-class entity in the blockchain ecosystem. At the heart of this system is the [🧩 IP Asset](doc:ip-asset) and its associated [⚙️ IP Account](doc:ip-account), a smart contract designed to serve as the core identity for each IP. This account-centric approach enables the storage and management of IP-related data, as well as the execution of diverse functions to manipulate that data via [🧱 Modules](doc:story-modules). -# Architecture +Протокол Story "Подтверждение Креативности (англ. Proof-of-Creativity)" представляет революционный открытый **Программируемый IP-слой**, возводящий IP в ранг первостепенной, основной сущности в экосистеме блокчейна. В основе этой системы лежит [🧩 IP Актив](doc:ip-asset) и связанный с ним [⚙️ IP Аккаунт](doc:ip-account), смарт-контракт, призванный служить основной идентификацией для каждого IP. Такой подход, ориентированный на учетную запись, позволяет хранить и управлять данными, связанными с IP, а также выполнять различные функции для манипулирования этими данными с помощью [🧱 Модули](doc:story-modules). + + +# Архитектура -Let's briefly introduce the layers mentioned in the above diagram: +Давайте вкратце разберём слои, упомянутые в приведенной выше диаграмме: -## [🧩 IP Asset](doc:ip-asset) +## [🧩 IP Актив](doc:ip-asset) -An IP Asset is an on-chain NFT, which represents an IP. If your IP is already on-chain (like an Azuki or Pudgy Penguin), it is already ready to be registered on Story. If your IP is off-chain, you would simply mint an NFT to represent it and then register it as an IP Asset on Story. +IP-актив - это NFT на блокчейне (анг. on-chain), который представляет IP. Если ваш IP уже находится на блокчейне (например, Azuki или Pudgy Penguin), он уже готов к регистрации в Story. Если ваш IP находится вне блокчейна (анг. off-chain), вам просто нужно создать его NFT представление, а затем зарегистрировать его как IP-актив в Story. -Upon registering an NFT as an IP Asset, an associated IP Account is created. +При регистрации NFT в качестве IP-актива создается соответствующий IP-аккаунт. -## [⚙️ IP Account](doc:ip-account) +## [⚙️ IP Аккаунт](doc:ip-account) -IP Accounts are smart contracts that are tied to an IP Asset, and do two main things: +IP-аккаунты - это смарт-контракты, которые привязаны к IP-активу, они выполняют две основные задачи: -1. Store its associated IP Asset's data (such as the associated License Tokens and Royalty Tokens) created from an IP -2. Facilitates the utilization of this data by various modules. For example, licensing, revenue/royalty sharing, remixing, and other critical features are made possible due to the IP Account's programmability. +1. Хранят данные связанного IP-актива (например, связанные с ним токены лицензий и токены роялти), созданного на основе IP. +2. Облегчает использование этих данных различными модулями. Например, лицензирование, распределение доходов/роялти, ремикширование (анг. remixing) и другие важные функции становятся возможными благодаря программируемости IP-аккаунта. -## [🧱 Modules](doc:modules-1) +## [🧱 Модули](doc:modules-1) Modules are customizable smart contracts that define and extend the functionality of IP Accounts. Modules empower developers to create functions and interactions for each IP to make IPs truly programmable. @@ -42,12 +44,21 @@ We already have a few core modules: 3. [❌ Dispute Module](doc:dispute-module) 4. [👥 Grouping Module](doc:grouping-module) -## [🗂️ Registry](doc:registry) +Модули - это настраиваемые смарт-контракты, которые определяют и расширяют функциональность IP-аккаунтов. Модули позволяют разработчикам создавать функции и взаимодействия для каждого IP, чтобы сделать IP по-настоящему программируемыми. + +У нас уже имеется несколько основных модулей: + +1. [📜 Модуль лицензирования](doc:licensing-module) +2. [💸 Модуль роялти](doc:royalty-module) +3. [❌ Модуль споров](doc:dispute-module) +4. [👥 Модуль группировки](doc:grouping-module) + +## [🗂️ Реестры](doc:registry) -The various registries on Story function as a primary directory/storage for the global states of the protocol. Unlike IP Accounts, which manage the state of specific IPs, a registry oversees the broader states of the protocol. +Различные реестры в Story функционируют как основной каталог/хранилище глобальных состояний протокола. В отличие от IP-аккаунтов, которые управляют состоянием конкретных IP-адресов, реестр контролирует более глобальные состояния протокола. -## [💊 Programmable IP License (PIL)](doc:programmable-ip-license) +## [💊 Программируемая IP Лицензия (PIL)](doc:programmable-ip-license) -The PIL is a real, off-chain legal contract that defines certain **License Terms** for how an IP Asset can be legally licensed. For example, how an IP Asset is commercialized or remixed, and who is allowed to do that and under what conditions. +PIL - это реальный (анг. off-chain) юридический договор, определяющий **Лицензионные Условия** того, как IP-актив может быть законно лицензирован. Например, как IP-актив коммерциализируется или ремикшируется (анг. remixed), кому и на каких условиях разрешается это делать. -We have mapped these same terms on-chain so you can easily attach terms to your IP Asset for others to seamlessly and transparently license your IP. +Мы отобразили эти же условия на блокчейне, чтобы вы могли легко прикрепить условия к вашему IP-активу, а другие могли легко и прозрачно лицензировать вашу IP. From 67aef68739a344f24ec44793afb854315ffeb4f7 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Tue, 31 Dec 2024 01:34:52 +0300 Subject: [PATCH 02/10] some --- docs/Concepts/dispute-module/index.md | 117 +++++++++--------- docs/Concepts/ip-account.md | 6 +- docs/Concepts/ip-asset/index.md | 4 +- .../ip-asset/ipa-metadata-standard.md | 55 ++++---- docs/Concepts/ip-asset/ipa-modifications.md | 64 +++++----- docs/Concepts/overview.md | 11 +- 6 files changed, 125 insertions(+), 132 deletions(-) diff --git a/docs/Concepts/dispute-module/index.md b/docs/Concepts/dispute-module/index.md index b73ad2e..656a107 100644 --- a/docs/Concepts/dispute-module/index.md +++ b/docs/Concepts/dispute-module/index.md @@ -1,5 +1,5 @@ --- -title: ❌ Dispute Module +title: ❌ Модуль Споров excerpt: '' deprecated: false hidden: false @@ -10,29 +10,29 @@ metadata: next: description: '' --- -The Dispute Module creates a way for users to raise and resolve disputes through arbitration. +Модуль споров даёт возможность пользователям начинать и разрешать споры через арбитраж. -## Dispute Terminology +## Терминология Споров -The main components of the arbitration system are: +Основными компонентами арбитражной системы являются: -* **Arbitration Policies:** the arbitration policy refers to the set rules/process/entities that combined will decide on a dispute. Currently the only supported arbitration policy is the [UMA Arbitration Policy](doc:uma-arbitration-policy). -* **Arbitration Penalty:** what happens to an IP Asset after it has been "tagged". An IPA is not deemed "tagged" unless the dispute is decided to be correct. Once tagged, an IPA will not be able to: - * mint licenses - * link to any parents - * claim royalties - * and all of its existing licenses become unusable -* **Tags:** refers to which "labels" can be applied to IP Assets in the protocol. The allowed tags are whitelisted by protocol governance. The initial set of tags is planned to be: +* **Арбитражная Политика:** Арбитражная политика относится к набору правил/процессов/субъектов, которые в совокупности будут принимать решение по спору. В настоящее время единственной поддерживаемой арбитражной политикой является [Арбитражная Политика UMA](doc:uma-arbitration-policy). +* **Арбитражный штраф:** что происходит с IP-активом после того, как он был «помечен». IPA не считается «помеченным» до тех пор, пока спор не будет признан корректным. После того, как IPA будет помечен, он не сможет: + * создавать лицензии + * ссылаться на родителей (анг. parents) + * требовать роялти + * и все его существующие лицензии становятся непригодными для использования +* **Тэги:** относится к тому, какие «метки» могут быть применены к IP-активам в протоколе. Разрешенные метки вносятся в белый список руководством протокола. Первоначальный набор меток планируется следующим образом: @@ -44,7 +44,7 @@ The main components of the arbitration system are: @@ -52,22 +52,22 @@ The main components of the arbitration system are: @@ -77,7 +77,7 @@ The main components of the arbitration system are: @@ -85,67 +85,68 @@ The main components of the arbitration system are:
- Dispute Tag + Тэг - Explanation + Объяснение
- Refers to registration of IP that already exists. + Регистрация IP, которая уже существует
`IMPROPER_USAGE` - Examples (non-exhaustive): - Territory, - Channels of Distribution, - Expiration, - Irrevocable, - Attribution, - Derivatives, - Limitations on Creation of Derivatives, - Commercial Use, - Sublicensable, - Non-Transferable, - Restriction on Cross-Platform Use + Примеры (неисчерпывающие): + Территория, + Каналы распространения, + Срок действия, + Безвозвратность, + Атрибуция, + Производные, + Ограничения на создание производных, + Коммерческое использование, + Сублицензируемая, + Непередаваемые, + Ограничение на кросс-платформенное использование - Refers to improper use of an IP Asset across multiple items (examples on the left). These items can be found in more detail in the [💊 Programmable IP License (PIL)](doc:programmable-ip-license) legal document. + Относится к ненадлежащему использованию IP-актива по нескольким пунктам (примеры слева). Более подробно эти пункты можно найти в юридическом документе [💊 Программируемая IP Лицензия (PIL)](doc:programmable-ip-license).
- Refers to missing payments associated with an IP. + Отсутствие платежей, связанных с IP
`CONTENT_STANDARDS_VIOLATION` - No-Hate\ - Suitable-for-All-Ages - No-Drugs-or-Weapons - No-Pornography + Без ненависти\ + Подходит для всех возрастов + Без наркотиков и оружия + Без порнографии - Refers to "No-Hate", "Suitable-for-All-Ages", "No-Drugs-or-Weapons" and "No-Pornography". These items can be found in more detail in the [💊 Programmable IP License (PIL)](doc:programmable-ip-license) legal document. + Относится к «Без ненависти», «Подходит для всех возрастов», «Без наркотиков или оружия» и «Без порнографии». Более подробно эти пункты можно найти в юридическом документе [💊 Программируемая IP Лицензия (PIL)](doc:programmable-ip-license).
-## Dispute Process Flow +## Процесс Рассмотрения Споров ![](https://files.readme.io/a1dc371-image.png) -### Raise Dispute +### Начать Спор -The `raiseDispute` function is permissionless and allows any address to raise a dispute against any IP Asset registered on the protocol. The dispute initiator has to: +Функция `raiseDispute` не требует особых разрешений и позволяет любому адресу возбудить спор против любого IP-актива, зарегистрированного в протоколе. Инициатор спора должен: -1. Select which "tag" it is raising a dispute on which will be applied to the IP Asset if the arbitration decision is positive. This means an IP Asset is officially "tagged" only when the proposed tag is confirmed as correct ("positive decision" in the diagram above). -2. Submit the dispute evidence for evaluation -3. Other conditions custom to each arbitration policy - such as payment rules, etc. +1. Выбрать «метку», по которой он поднимает спор, которая будет применена к IP-активу в случае положительного арбитражного решения. Это означает, что IP-актив официально «помечается» только тогда, когда предложенная метка подтверждается как правильная («положительное решение» на диаграмме выше). +2. Представить доказательства спора для оценки +3. Другие условия, индивидуальные для каждой арбитражной политики - например, правила оплаты и т. д. -### Set Dispute Judgement +### Вынести Решение По Спору -The `setDisputeJudgement` can only be called by whitelisted addresses and allows the caller to set the dispute judgment. Can only be called once as dispute decisions are immutable. If 3rd parties want to offer the possibility for recourse they can do so on their end and relay the final judgment. +Функция `setDisputeJudgement` может быть вызвана только адресами из белого списка и позволяет вызывающему установить решение по спору. Может быть вызвана только один раз, так как решения по спорам неизменяемы. Если третьи лица хотят предложить обращение в суд, они могут сделать это на своей стороне и передать окончательное решение. -### Tag Derivative If Parent Infringed +### Отметить Производные Если Родитель Нарушил Права -If the `setDisputeJudgement` has tagged an IP as infringing then any address can call `tagDerivativeIfParentInfringed` to apply the same tag as the parent to the derivatives all the way down the derivative chain. +Если `setDisputeJudgement` пометила IP как нарушающую авторские права, то любой адрес может вызвать `tagDerivativeIfParentInfringed`, чтобы применить ту же метку, что и к родителю, к производным по всей цепочке производных. -> 📘 Looking Ahead +> 📘 В перспективе > -> In the future, the idea is that any derivative IP Asset of an infringed IP Asset would automatically be tagged without needed someone to call `tagDerivativeIfParentInfringed`. This is currently a limitation that we are aware of. +> В будущем предполагается, что любой производный объект IP от нарушевшего правила объекта IP будет автоматически маркироваться без необходимости вызывать `tagDerivativeIfParentInfringed`. В настоящее время это ограничение, о котором мы знаем. -The derivatives are then tagged directly without any need for judgment given that it is considered that if a parent IP license has been infringed then all derivatives that come from that license are also implicitly in an infringement situation. +Тогда производные помечаются напрямую, без необходимости суждения, поскольку считается, что если родительская лицензия IP была нарушена, то все производные, которые происходят из этой лицензии, также неявно находятся в ситуации нарушения. + +**Пример**: IP-актив 7 сначала помечается как нарушающий («PLAGIARISM») с помощью `setDisputeJudgement`. Только после того, как он прошёл через процесс спора, IPA 3, 1 и 0 могут быть помечены через `tagDerivativeIfParentInfringed` любым адресом без необходимости проходить через новый процесс спора. -**Example**: IPA 7 is first tagged ("PLAGIARISM") as infringing via `setDisputeJudgement` after having gone through a dispute process. Only after that can IPAs 3, 1, and 0 can be tagged via `tagDerivativeIfParentInfringed` by any address without needing to go through a new dispute process. ![](https://files.readme.io/ee69754-image.png) -### Resolve Dispute +### Разрешение Спора -Resolving a dispute removes the tag from the IP Asset. Since there are two ways in which a tag can be applied, there are two ways for it to be resolved: +Разрешение спора удаляет метку с IP-актива. Поскольку существует два способа применения метки, есть два способа ее разрешения: -1. Tag was applied via the`setDisputeJudgement` function +1. Метка была применена с помощью функции `setDisputeJudgement`. -In a case where a dispute judgment was positive, then a tag was applied. After the tag has been applied to an IP Asset, the **dispute initiator** can, if he/she believes the matter to be resolved and the tag to no longer apply, choose to remove it by calling `resolveDispute`. For example, if one party owed money to the dispute initiator and paid the full amount after the dispute judgment then the tag could be cleared and the IP Asset would have a clean slate again. +В случае, если решение по спору было положительным, то есть была применена метка. После того как метка была применена к IP-активу, **инициатор спора** может, если он/она считает, что вопрос решен и метка больше не нужна, удалить ее, вызвав функцию `resolveDispute`. Например, если одна из сторон задолжала инициатору спора деньги и выплатила всю сумму после вынесения решения по спору, метка может быть удалена, и IP-актив снова будет чист. -If the dispute initiator chooses to not resolve, then the tag that was defined in `setDisputeJudgement` remains in force. +Если инициатор спора решает не разрешать спор, то тег, определенный в `setDisputeJudgement`, остается в силе. -2. Tag was applied via the`tagDerivativeIfParentInfringed` function +2. Метка была применена с помощью функции `tagDerivativeIfParentInfringed`. -If an IP has been previously tagged as infringing via `tagDerivativeIfParentInfringed`, such tag can be removed via `resolveDispute` in a permissionless way as long as the parent is no longer considered an infringing IP Asset. +Если IP была ранее помечена как нарушающая авторские права с помощью функции `tagDerivativeIfParentInfringed`, такая метка может быть удалена с помощью функции `resolveDispute` без каких-либо особых разрешений, если родитель больше не считается нарушающим права IP-активом. -This mechanism of permissionless resolving disputes exists to make it easier to propagate down the derivative chain and remove infringement tags from derivative IPs when the parent has resolved its original dispute and is no longer considered as being in an infringing situation, and therefore neither are its derivatives. +Этот механизм безусловного разрешения споров существует для того, чтобы облегчить распространение по цепочке производных и удаление меток нарушения с производных IP, когда родитель разрешил свой первоначальный спор и больше не считается нарушающим права, а значит, и его производные тоже. -If no address chooses to resolve, then the tag that was applied from the parent to the derivative remains in force. +Если ни один из адресов не решит разрешить спор, то тег, который был применен от родителя к производному, останется в силе. -### Cancel Dispute +### Отмена спора -In a case where a dispute was raised but the matter has been resolved before the dispute judgment, the dispute initiator can cancel the dispute. However, depending on the conditions of each arbitration policy, there may be non-refundable fees that are not recouped on cancellation. \ No newline at end of file +В случае, когда спор был поднят, но вопрос был решен до вынесения решения по спору, инициатор спора может отменить спор. Однако в зависимости от условий каждой арбитражной политики могут быть предусмотрены невозвратные сборы, которые не возвращаются при отмене. \ No newline at end of file diff --git a/docs/Concepts/ip-account.md b/docs/Concepts/ip-account.md index 91321e2..3269d28 100644 --- a/docs/Concepts/ip-account.md +++ b/docs/Concepts/ip-account.md @@ -1,5 +1,5 @@ --- -title: ⚙️ IP Account +title: ⚙️ IP Аккаунт excerpt: '' deprecated: false hidden: false @@ -10,9 +10,9 @@ metadata: next: description: '' --- -> 🐦 Skip the Read +> 🐦 Читать не обязательно > -> Get a quick 2-minute overview of IP Accounts [here](https://twitter.com/jacobmtucker/status/1787603252198134234). +> Краткая 2-минутная выжимка про IP-аккаунты тут [тут](https://twitter.com/jacobmtucker/status/1787603252198134234). When an [🧩 IP Asset](doc:ip-asset) is registered, it is given an associated **IP Account**. An IP Account is a modified ERC-6551 (Token Bound Account) implementation. It is a separate contract bound to the IP Asset for controlling permissions around interactions with Story's modules or storing the IP's associated data. Upon registration, an IP Asset is assigned a unique ID. This ID is the address of the IP Account that is bound to the IP Asset. diff --git a/docs/Concepts/ip-asset/index.md b/docs/Concepts/ip-asset/index.md index 96c4d0e..aea9550 100644 --- a/docs/Concepts/ip-asset/index.md +++ b/docs/Concepts/ip-asset/index.md @@ -1,5 +1,5 @@ --- -title: 🧩 IP Asset +title: 🧩 IP Актив excerpt: '' deprecated: false hidden: false @@ -12,7 +12,7 @@ next: --- > 🐦 Читать не обязательно > -> Краткая 1-минутная выжимка про IP-активы тут [here](https://twitter.com/jacobmtucker/status/1785765362744889410). +> Краткая 1-минутная выжимка про IP-активы тут [тут](https://twitter.com/jacobmtucker/status/1785765362744889410). IP-активы - это основополагающие программируемые IP-метаданные в Story. Каждый IP-актив - это ERC-721 NFT (представляющая IP). Да, это означает, что ваш Azuki или Pudgy Penguin уже может быть зарегистрирован в нашем протоколе, и не переживайте, никаких обёрток. diff --git a/docs/Concepts/ip-asset/ipa-metadata-standard.md b/docs/Concepts/ip-asset/ipa-metadata-standard.md index 6059c58..89a6fd2 100644 --- a/docs/Concepts/ip-asset/ipa-metadata-standard.md +++ b/docs/Concepts/ip-asset/ipa-metadata-standard.md @@ -1,5 +1,5 @@ --- -title: IPA Metadata Standard +title: IPA Стандарт Метаданных excerpt: '' deprecated: false hidden: false @@ -10,27 +10,28 @@ metadata: next: description: '' --- -> 🚧 Warning: Still Under Discussion +> 🚧 Внимание: Все еще обсуждается > -> We are still figuring out the best way to define an IPA Metadata Standard. For the sake of transparency, the following document is our thoughts so far but is subject to change as we progress towards releasing our public Mainnet. +> Мы все еще пытаемся выяснить, как лучше определить стандарт метаданных IPA. В целях прозрачности нижеприведенный документ представляет собой наши мысли на данный момент, но может быть изменен по мере продвижения к выпуску нашего публичного Mainnet. -This is the JSON metadata that is associated with an IP Asset, and gets stored inside of an IP Account. You must call `setMetadata(...)` inside of the IP Account in order to set the metadata, and then call `metadata()` to read it. +Это JSON метаданные, которые ассоциируются с IP-активом и хранятся в IP-аккаунте. Вы должны вызвать `setMetadata(...)` внутри IP-аккаунта, чтобы установить метаданные, а затем вызвать `metadata()`, чтобы прочитать их. -# Attributes & Structure + +# Параметры и Структура @@ -46,7 +47,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -60,7 +61,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -74,7 +75,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -88,7 +89,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -102,9 +103,9 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -118,7 +119,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -132,7 +133,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -146,7 +147,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -160,7 +161,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -174,7 +175,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -188,7 +189,7 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i @@ -202,13 +203,13 @@ This is the JSON metadata that is associated with an IP Asset, and gets stored i
- Property Name + Название Параметра - Type + Тип - Description + Описание
- Title of the IP + Заголовок IP.
- Description of the IP + Описание IP.
- Type of the IP Asset, can be defined arbitrarily by the creator. I.e. “character”, “chapter”, “location”, “items”, "music", etc + Тип IP-актива, может быть определен автором произвольно. Например, «персонаж», «глава», «локация», «предметы», «музыка» и т. д.
- The detailed relationship info with the IPA’s direct parent asset, such as `APPEARS_IN`, `FINETUNED_FROM`, etc. See more examples [here](https://docs.story.foundation/docs/ipa-metadata-standard#relationship-types). + Подробная информация об отношениях с прямым родительским активом IPA, например `APPEARS_IN`, `FINETUNED_FROM` и т.д. Дополнительные примеры смотрите [здесь] (https://docs.story.foundation/docs/ipa-metadata-standard#relationship-types).
- Date/Time that the IP was created (either ISO8601 or unix format). + Дата/Время создания IP (ISO8601 или unix формат). - This dateCreated field can be used to specify historical dates that aren’t on-chain. For example, Harry Potter was published on June 26. + Это поле можно использовать для указания дат, которые не содержаться в блокчейне. Например, Гарри Поттер был опубликован 26 июня.
- Supporting image. Could be used as a “wrapper” image for things related to branding or watermarks. + Вспомогательное изображение. Может использоваться в качестве «оберточного» изображения для брендинга или водяных знаков.
- An array of information about the creators. Creator type defined below. + Массив информации о создателях. Тип "создатель" определен ниже.
- An array of supporting media. Media type defined below. + Массив вспомогательных носителей. Тип "носитель" определен ниже.
- An array of key-value pairs that can be used for arbitrary mappings. Attribute type defined below. + Массив пар ключ-значение, которые могут быть использованы для произвольного сопоставления. Тип атрибута определен ниже.
- This is assigned to verified application from Story Protocol directly (on a request basis so far). We will map each App ID to a name + Присваивается проверенному приложению из Story Protocol напрямую (пока что на основе запроса). Мы сопоставим каждый идентификатор приложения с именем
- Any tags that can help surface this IPA + Любые теги, которые могут помочь в этом IPA.
- Allows you to set Do Not Train for a specific agent + Позволяет установить режим «Не обучать» для конкретного агента.
-## Type Definitions +## Определения типов ```typescript IpCreator type IpCreator = { @@ -260,11 +261,11 @@ type IPRobotTerms = { } ``` -## Relationship Types +## Типы Отношений -The different relationship types that can be used for the `relationships` attribute. +Различные типы отношений, которые могут быть использованы для атрибута `relationships`. -### Story Relationships +### Отношения Story 1. **APPEARS\_IN** - A character APPEARS\_IN a chapter. @@ -307,7 +308,7 @@ The different relationship types that can be used for the `relationships` attrib 20. **LEADS\_INTO** - An event LEADS\_INTO the climax.?\ **PARALLEL - story** happening in parallel or around the same timeframe -### AI Relationships +### Отношения AI 1. **TRAINED\_ON** - A model is TRAINED\_ON a dataset. @@ -349,7 +350,7 @@ The different relationship types that can be used for the `relationships` attrib 20. **ADAPTS\_TO** - A fine-tuned model ADAPTS\_TO new data. -# Example Use Cases +# Примеры Использования ```json Harry Potter { diff --git a/docs/Concepts/ip-asset/ipa-modifications.md b/docs/Concepts/ip-asset/ipa-modifications.md index bc1bbc9..369e9b8 100644 --- a/docs/Concepts/ip-asset/ipa-modifications.md +++ b/docs/Concepts/ip-asset/ipa-modifications.md @@ -1,7 +1,7 @@ --- -title: IP Modifications & Restrictions +title: Модификация & Ограничения IP deprecated: false -exerpt: Learn about the modifications and restrictions for IP Assets. +exerpt: Узнайте больше про модифицаию и ограничения IP-активов. hidden: false metadata: title: '' @@ -10,23 +10,23 @@ metadata: next: description: '' --- -# IP Asset Modifications +# Модификация IP-активов -IP Assets can be modified/customized a few ways. For example, by [setting the License Config](doc:license-config-hook) which allows you to change a few things as you'll see below, changing its metadata, and more. These things can **always be changed unless there is a certain condition**. +IP-активы можно модифицировать/настроить несколькими способами. Например, с помощью [установки конфигурации лицензии](doc:license-config-hook), которая позволяет вам изменить некоторые вещи, как вы увидите ниже, изменить метаданные и многое другое. Эти вещи **всегда могут быть изменены, если нет определенных условий**. @@ -34,7 +34,7 @@ IP Assets can be modified/customized a few ways. For example, by [setting the Li
- Action + Действие - Conditions + Условие - Via The... + Меняется в...
- Modify License Minting Fee + Изменить комиссию за минт лицензии @@ -42,13 +42,13 @@ IP Assets can be modified/customized a few ways. For example, by [setting the Li - [License Config](doc:license-config-hook) + [Конфигурация Лицензии](doc:license-config-hook)
- Modify Licensing Hook + Изменить Хук Лицензии @@ -56,47 +56,47 @@ IP Assets can be modified/customized a few ways. For example, by [setting the Li - [License Config](doc:license-config-hook) + [Конфигурация Лицензии](doc:license-config-hook)
- Modify `commercialRevShare` + Изменить `commercialRevShare` - Cannot **decrease** `commercialRevShare` percentage. You can only increase it. + Нельзя **уменьшить** `commercialRevShare`. Можно только увеличить. - [License Config](doc:license-config-hook) + [Конфигурация Лицензии](doc:license-config-hook)
- Disable/Enable the License + Отключить/Включить Лицензию - License can be disabled or re-enabled at any time. + Лицензия может быть включена или выключена в любой момент. - *Note that disabling a license disallows future licenses from being minted, but does not affect existing ones.* + *Примечание: отключение лицензии запрещает минт лицензий в будущем, но не влияет на существующие лицензии.* - [License Config](doc:license-config-hook) + [Конфигурация Лицензии](doc:license-config-hook)
- Modify Metadata + Изменить Метаданные - Cannot modify if the metadata is **frozen**. This is done by calling `freezeMetadata` in the [CoreMetadataModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/metadata/CoreMetadataModule.sol). + Невозможно модифицировать, если метаданные **заморожены**. Это делается вызовом `freezeMetadata` в [CoreMetadataModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/metadata/CoreMetadataModule.sol) @@ -106,22 +106,22 @@ IP Assets can be modified/customized a few ways. For example, by [setting the Li
-## License Hook Modifications +## Модификация Хука Лицензии -The IP can be further customized or modified using the [License Hook](https://docs.story.foundation/docs/license-config-hook#/licensing-hook). This is a function that gets set within the License Config that gets called before a [License Token](doc:license-token) (or more simply, a "license") is minted. There are various features you can implement with the License Hook, and are **always modifiable**: +IP можно дополнительно настроить или модифицировать с помощью [Хук Лицензии](https://docs.story.foundation/docs/license-config-hook#/licensing-hook). Это функция, задаваемая в Конфигурации Лицензии, которая вызывается перед тем, как [Токен Лицензии](doc:license-token) (или, проще говоря, «лицензия») будет "отчеканена". С помощью Хука Лицензии можно реализовать различные функции, которые **всегда можно изменять**: -| Feature | Description | +| Функция | Описание | | ------------------- | ------------------------------------------------------------------------------------------------------------------- | -| Dynamic License Fee | You can dynamically set the price of a license. For example, it can be updated dynamically via bonding curve logic. | -| Total # of Licenses | You can abort the function based on a maximum number of license tokens that can be minted. | -| Specific Receivers | You can restrict minting of license to a specific receiver. | -| More... | Additional licensing hook features can be implemented as required. | +| Динамическая стоимость лицензии | Вы можете динамически устанавливать стоимость лицензии. Например, она может динамически обновляться. | +| Общее число лицензий | Вы можете прервать функцию, основываясь на максимальном количестве токенов лицензий, которые могут быть созданы. | +| Конкретные получатели | Вы можете запретить минт лицензии конкретному получателю. | +| Ещё... | Дополнительные функции хука лицензирования могут быть реализованы по мере необходимости. | -# Group IPA Restrictions +# Ограничения групповых IPA -In addition, [Group IPAs](doc:grouping-module) are subject to the following additional restrictions: +Кроме того, на [групповые IPA](doc:grouping-module) распространяются следующие дополнительные ограничения: -| Action | Restriction | +| Действие | Ограничение | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Add IP Asset to a Group | You can only add an IP Asset to a group if that group is not "locked". A group becomes locked once the first license token is minted from it or a derivative is linked to it. | -| Remove IP Asset from a Group | You can only remove an IP Asset from a group if that group is not "locked". A group becomes locked once the first license token is minted from it or a derivative is linked to it. | \ No newline at end of file +| Добавление IP-актива в группу | Вы можете добавить IP-актив в группу только в том случае, если эта группа не «заблокирована». Группа становится заблокированной, когда из нее выпускается первый лицензионный токен или к ней привязывается производная. | +| Удаление IP-актива из группы | Группа становится заблокированной, когда из нее выпускается первый лицензионный токен или к ней привязывается производная. | \ No newline at end of file diff --git a/docs/Concepts/overview.md b/docs/Concepts/overview.md index 6c30db1..6fa88bd 100644 --- a/docs/Concepts/overview.md +++ b/docs/Concepts/overview.md @@ -1,5 +1,5 @@ --- -title: 🔍 Overview +title: 🔍 Краткий обзор excerpt: '' deprecated: false hidden: false @@ -35,15 +35,6 @@ IP-аккаунты - это смарт-контракты, которые пр ## [🧱 Модули](doc:modules-1) -Modules are customizable smart contracts that define and extend the functionality of IP Accounts. Modules empower developers to create functions and interactions for each IP to make IPs truly programmable. - -We already have a few core modules: - -1. [📜 Licensing Module](doc:licensing-module) -2. [💸 Royalty Module](doc:royalty-module) -3. [❌ Dispute Module](doc:dispute-module) -4. [👥 Grouping Module](doc:grouping-module) - Модули - это настраиваемые смарт-контракты, которые определяют и расширяют функциональность IP-аккаунтов. Модули позволяют разработчикам создавать функции и взаимодействия для каждого IP, чтобы сделать IP по-настоящему программируемыми. У нас уже имеется несколько основных модулей: From ec8b465987c86604e736635ceb04b2482eaef12e Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Tue, 31 Dec 2024 19:25:04 +0300 Subject: [PATCH 03/10] dispute module + licensing module --- .../dispute-module/uma-arbitration-policy.md | 142 +++++++++--------- docs/Concepts/licensing-module/index.md | 42 +++--- .../licensing-module/license-config-hook.md | 139 ++++++++--------- .../licensing-module/license-template.md | 49 +++--- .../licensing-module/license-terms.md | 36 +++-- .../licensing-module/license-token.md | 41 +++-- 6 files changed, 215 insertions(+), 234 deletions(-) diff --git a/docs/Concepts/dispute-module/uma-arbitration-policy.md b/docs/Concepts/dispute-module/uma-arbitration-policy.md index 0e1d579..d0dc712 100644 --- a/docs/Concepts/dispute-module/uma-arbitration-policy.md +++ b/docs/Concepts/dispute-module/uma-arbitration-policy.md @@ -1,5 +1,5 @@ --- -title: UMA Arbitration Policy +title: Арбитражная политика UMA excerpt: '' deprecated: false hidden: false @@ -10,55 +10,55 @@ metadata: next: description: '' --- -> 🚧 Warning: Only in v1.3 +> 🚧 Внимание: Только в версии 1.3 > -> The UMA Arbitration Policy is only available in v1.3 of our protocol, which is not yet documented. +> Арбитражная политика UMA доступна только в версии 1.3 нашего протокола, которая пока не задокументирована. > 📘 UMA > -> For detailed information on how UMA's dispute resolution works, [visit their website](https://uma.xyz/). +> Для подробной информации о том, как работает механизм разрешения споров UMA, [посетите их сайт](https://uma.xyz/). -This arbitration policy is a dispute resolution mechanism that follows [UMA's](https://uma.xyz/) rules. Below we share a high-level overview of how the UMA dispute process works. - -## Smart Contract Flow Diagram +Эта арбитражная политика представляет собой механизм разрешения споров, который следует правилам [UMA](https://uma.xyz/). Ниже мы приводим краткий обзор того, как работает процесс разрешения споров UMA. +## Схема Работы Смарт-контракта ![](https://files.readme.io/e0dfb0a226bdd29ab3adede7d1df7d6662497331e1b92319ee1ad8344dc5dfa3-image.png) -1. Raise Dispute - The first step to initiate a dispute against an IP Asset is to call the `raiseDispute` function on [DisputeModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/dispute/DisputeModule.sol). This function will in turn call `assertTruth` on UMA's `OptimisticOracleV3.sol`. To initiate a dispute the dispute initiator will need to post a bond of at least the minimum bond defined by UMA for the selected currency. -2. (Optional) Dispute Assertion / Counter Dispute - After the `raiseDispute` call there is a period of time called liveness in which a counter dispute can be submitted. The liveness period is split in two parts: (i) the first part of the liveness period in which only the IP owner can counter dispute and (ii) a second part in which any address can counter dispute - which can be done by calling `disputeAssertion` on `ArbitrationPolicyUMA.sol`. To counter a dispute the caller will need to post a bond of the same amount and currency that was used by the dispute initiator when raising a dispute. -3. Settle Assertion - 1. If nobody submitted a counter dispute then when the liveness period is over, any address can call `settleAssertion` on UMA's `OptimisticOracleV3.sol`. - 2. If somebody has submitted a counter dispute before the liveness period is over, then the dispute is escalated to UMA decision makers who will judge and make a decision on whether the IP is infringing or not. After the decision has been made, then any address can call `settleAssertion` on UMA's `OptimisticOracleV3.sol`. - -## Dispute Evidence Submission Guidelines - -When raising a dispute or making a counter dispute, both parties can submit dispute evidence. Dispute evidence refers to a text document that UMA will use & read from to make a judgement on the dispute. +1. Возбуждение спора - Первый шаг для инициирования спора против IP-актива — это вызов функции `raiseDispute` в контракте [DisputeModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/dispute/DisputeModule.sol). Эта функция вызывает метод `assertTruth` в контракте UMA `OptimisticOracleV3.sol`. Чтобы инициировать спор, инициатору необходимо внести залог, который должен быть не меньше минимальной суммы, определённой UMA для выбранной валюты. +2. (Опционально) Контрспор / Подтверждение спора - После вызова `raiseDispute` начинается период активности (анг. liveness), в течение которого можно подать контрспор. Период активности делится на две части: +(i) первая часть, в течение которой только владелец IP может подать контрспор; +(ii) вторая часть, в течение которой любой адрес может подать контрспор, вызвав функцию `disputeAssertion` в контракте `ArbitrationPolicyUMA.sol`. +Чтобы подать контрспор, необходимо внести залог в той же валюте и размере, что и инициатор спора. +3. Урегулирование заявления + 1. Если никто не подал контрспор, то после окончания периода активности любой адрес может вызвать функцию `settleAssertion` в контракте UMA `OptimisticOracleV3.sol`. + 2. Если контрспор был подан до окончания периода активности, спор передаётся на рассмотрение арбитров UMA, которые примут решение о том, нарушает ли IP права или нет. После вынесения решения любой адрес может вызвать функцию `settleAssertion` в контракте UMA `OptimisticOracleV3.sol`. -### Document Characteristics +## Руководство по подаче доказательств спора -Every document should have the following characteristics: +При возбуждении спора или подаче контрспора обе стороны могут предоставить доказательства спора. Доказательства спора — это текстовый документ, который будет использован UMA для принятия решения по спору. -* It should be a text document. Can have images or video if necessary. +### Требования к документу -* It should be uploaded on IPFS. +Каждый документ должен соответствовать следующим требованиям: -* It should not take the reviewer more than 2 hours to review the dispute evidence document - the reviewer's time is limited and the evidence could be deemed invalid if it would take too much time to review. Best efforts will be applied to solve a dispute but please keep it concise to have your dispute evidence be valid. +* Это должен быть текстовый документ. При необходимости он может содержать изображения или видео. +* Документ должен быть загружен в IPFS. +* Его рассмотрение не должно занимать у арбитра больше двух часов. Время арбитра ограничено, и доказательства могут быть признаны недействительными, если их рассмотрение займёт слишком много времени. Старайтесь кратко излагать доказательства, чтобы они были действительными. -Depending on what the type of the Dispute Tag is, you also need to include extra evidence: +В зависимости от тега спора (анг. Dispute Tag) необходимо предоставить дополнительные доказательства: @@ -70,18 +70,18 @@ Depending on what the type of the Dispute Tag is, you also need to include extra @@ -91,31 +91,31 @@ Depending on what the type of the Dispute Tag is, you also need to include extra @@ -125,14 +125,14 @@ Depending on what the type of the Dispute Tag is, you also need to include extra @@ -142,23 +142,23 @@ Depending on what the type of the Dispute Tag is, you also need to include extra @@ -166,6 +166,6 @@ Depending on what the type of the Dispute Tag is, you also need to include extra
- Dispute Tag + Тег спора - Dispute Evidence Contents + Содержание доказательств - Dispute review process + Процесс рассмотрения доказательств
- Inputs: - A. Showcase or pointer to the pre-existing IP that is being infringed upon by the disputed IP - B. Proof that the pre-existing IP has an earlier registration or public appearance date prior to the disputed IP registration date. + Входные данные: + A. Пример или ссылка на ранее существующую IP, которая нарушена спорной IP. + B. Доказательства, что ранее существующая IP зарегистрирована раньше, чем спорная IP. - 1. Check if the pre-existing is the same or very similar to the disputed IP using input A - * Mickey Mouse with 1 pixel difference is an infringement - * Mickey Mouse with a new hat is an infringement unless it’s a derivative of Mickey Mouse - 2. Check the registration date of the pre-existing IP using input B - 3. Confirm that the disputed IP has a later registration date by checking on the Hub - 4. Confirm that the disputed IP is not a derivative of the pre-existing IP by checking on the Hub + 1. Проверьте, является ли ранее существующая IP идентичной или очень похожей на спорную IP, используя данные A. + * Микки Маус с разницей в 1 пиксель — это нарушение. + * Микки Маус в новой шляпе — это нарушение, если это не производная IP от Микки Мауса. + 2. Проверьте дату регистрации ранее существующей IP, используя данные B. + 3. Подтвердите, что спорная IP зарегистрирована позже, проверив данные в Хабе. + 4. Подтвердите, что спорная IP не является производным от ранее существующей IP, проверив данные в Хабе.
`IMPROPER_USAGE` - Examples (non-exhaustive):\ - Territory - Channels of Distribution - Expiration - Irrevocable - Attribution - Derivatives - Limitations on Creation of Derivatives - Commercial Use - Sublicensable - Non-Transferable - Restriction on Cross-Platform Use + Примеры (неисчерпывающие)\ + Территория, + Каналы распространения, + Срок действия, + Безвозвратность, + Атрибуция, + Производные, + Ограничения на создание производных, + Коммерческое использование, + Сублицензируемая, + Непередаваемые, + Ограничение на кросс-платформенное использование - Inputs:\ - A. text: PIL term that has been violated - B. text: description of the violation - C. text: proof of violation + Входные данные:\ + A. Текст: Указание нарушенного пункта лицензии PIL. + B. Текст: Описание нарушения. + C. Текст: Доказательства нарушения. - 1. Read the associated PIL term description on the PIL license official document using input A - 2. Read the violation description using input B - 3. Decide on the veracity of the proof presented by checking on associated platforms when possible using input C + 1. Прочитайте описание нарушенного пункта в официальном документе лицензии PIL, используя данные A. + 2. Ознакомьтесь с описанием нарушения, используя данные B. + 3. Проверьте достоверность представленных доказательств, используя данные C.
- Inputs:\ - A. text: description of each of each payment the disputed IP received that should have been shared with its ancestors - B. text: proof of payments + Входные данные:\ + A. Текст: Описание каждого платежа, который должен был быть передан предшествующим IP (анг. ancestors), но не был. + B. Текст: Доказательства по платежам. - 1. Check veracity of the proof of payments by checking on the associated platforms when possible using input A and B - 2. If proof of payments are deemed to be real, confirm that the payment has indeed not been made onchain by checking on blockchain explorer + 1. Проверьте достоверность доказательств платежей, используя данные A и B. + 2. Если доказательства платежей реальны, подтвердите, что эти платежи действительно не были выполнены на блокчейне, используя блокчейн-обозреватель (анг. blockchain explorer).
`CONTENT_STANDARDS_VIOLATION` - No-Hate\ - Suitable-for-All-Ages - No-Drugs-or-Weapons - No-Pornography + Без ненависти\ + Подходит для всех возрастов + Без наркотиков и оружия + Без порнографии - Inputs:\ - A. text: the content standard point that has been violated - B. text: description of the violation - C. text: proof of violation + Входные данные:\ + A. Текст: Нарушенный пункт стандартов содержания. + B. Текст: Описание нарушения. + C. Текст: Доказательства нарушения. - 1. Read the associated content standards description on the official content standards section in the PIL using input A - 2. Read the violation description using input B - 3. Decide on the veracity of the proof presented by checking on associated platforms when possible using input C + 1. Прочитайте описание нарушенного пункта в официальном документе PIL, используйте данные A. + 2. Ознакомьтесь с описанием нарушения, используя данные B. + 3. Проверьте достоверность представленных доказательств, используя данные C.
-> 📘 Note +> 📘 Примечание > -> As the process is still experimental, we can expect iteration and fine-tuning on the contents/formats of how the evidence should be submitted. \ No newline at end of file +> Процесс пока экспериментальный, и формат/содержание доказательств может изменяться и дорабатываться. \ No newline at end of file diff --git a/docs/Concepts/licensing-module/index.md b/docs/Concepts/licensing-module/index.md index 6dc33d6..e2446b2 100644 --- a/docs/Concepts/licensing-module/index.md +++ b/docs/Concepts/licensing-module/index.md @@ -1,6 +1,6 @@ --- -title: 📜 Licensing Module -excerpt: Learn about creating & attaching real legal license to your IP on Story. +title: 📜 Модуль Лицензирования +excerpt: Узнайте, как создавать и прикреплять настоящие юридические лицензии к вашей IP в Story. deprecated: false hidden: false metadata: @@ -10,37 +10,37 @@ metadata: next: description: '' --- -> ⏩ Skip the Read - 1 Minute Summary +> ⏩ Читать не обязательно - 1-минутное саммари > -> The Licensing Module allows you to create a real legal license from a **License Template** (which is the [Programmable IP License (PIL💊)](doc:programmable-ip-license)) and attach it to your IP Asset. This license, and the **License Terms** that define it, restrict how others can use your IP, commercialize it, and remix it. +> Модуль Лицензирования позволяет создавать юридически действительную лицензию на основе **Шаблона Лицензии** (например, Программируемая лицензия IP (PIL💊)) и прикреплять её к вашему IP-активу. Эта лицензия и определяющие её условия лицензии ограничивают, как другие могут использовать вашу IP, монетизировать её или создавать ремиксы. > -> If License Terms are attached to an IP Asset, anyone can mint a **License Token** (an ERC-721 NFT) from it which acts as the license to use that work based on the terms that define it. This token can then be burned to register a derivative work. This then establishes a parent-child relationship between assets, unlocking things like automatic royalty flow from the [💸 Royalty Module](doc:royalty-module). +> Если к IP-активу прикреплены условия лицензии, любой человек может создать **Токен Лицензии** (NFT стандарта ERC-721), который выступает в роли лицензии для использования этого произведения в соответствии с указанными условиями. Этот токен может быть уничтожен для регистрации производного произведения. Это создаёт родственно-дочерние связи между активами, открывая такие возможности, как, например, автоматический поток роялти через [💸 Модуль Роялти](doc:royalty-module). -The owner address of an IP Asset owns intellectual property rights such as creating derivatives, being commercially exploited, and being reproduced in different platforms. IP Assets can programmatically grant permissions for any users to exercise those rights with some autonomy via **License Tokens** (an ERC-721 NFT), which point to a particular set of conditions, known as **License Terms**. +Адрес владельца IP-актива обладает правами интеллектуальной собственности, такими как создание производных произведений, коммерческая эксплуатация и воспроизведение на различных платформах. IP-активы могут программно предоставлять разрешения другим пользователям для реализации этих прав с некоторой степенью автономии через **Токены Лицензии** (NFT стандарта ERC-721), которые указывают на определённый набор условий, известных как **Условия Лицензии**. The contracts in blue are built into the protocol. The contracts in white can be developed by the community or 3rd party vendor. - Blue: contracts built into the protocol. White: contracts developed by the community or 3rd party vendor. + Синий: Контракты встроены в протокол. Белый: Контракты могут быть разработаны сообществом или сторонними разработчиками. ## `LicensingModule.sol` -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/licensing/LicensingModule.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/licensing/LicensingModule.sol). -The `LicensingModule.sol` contract is the main entry point for the licensing system. It is responsible for: +Контракт `LicensingModule.sol` — это входной пункт системы лицензирования. Он отвечает за: -* Attaching License Terms to IP Assets -* Minting License Tokens -* Registering derivatives -* Setting License Configs +* Прикрепление условий лицензии к IP-активам +* Выпуск токенов лицензии +* Регистрацию производных активов +* Настройку конфигураций лицензий -## Further Readings +## Подробнее -The following document will walk through all of the major components of the Licensing Module as shown above: +Следующие документы помогут вам изучить все основные компоненты модуля лицензирования, перечисленные выше: -* [License Template](doc:license-template) -* [License Terms](doc:license-terms) -* [License Token](doc:license-token) -* [License Registry](doc:license-registry) -* [License Config / Hook](doc:license-config-hook) +* [Шаблон Лицензии](doc:license-template) +* [Условия Лицензии](doc:license-terms) +* [Токен Лицензии](doc:license-token) +* [Реестр Лицензий](doc:license-registry) +* [Конфигурация/Хук Лицензии](doc:license-config-hook) diff --git a/docs/Concepts/licensing-module/license-config-hook.md b/docs/Concepts/licensing-module/license-config-hook.md index ea1b957..d4c9932 100644 --- a/docs/Concepts/licensing-module/license-config-hook.md +++ b/docs/Concepts/licensing-module/license-config-hook.md @@ -1,8 +1,7 @@ --- -title: License Config / Hook +title: Конфигурация/Хук Лицензии excerpt: >- - An optional hook that can be attached to an entire IP Asset or specific - license for dynamic minting fees. + Дополнительный хук, который можно прикрепить к IP-активу или конкретной лицензии для динамического определения комиссий за выпуск. deprecated: false hidden: false metadata: @@ -13,100 +12,87 @@ next: description: "" --- -## License Config +## Конфигурация лицензии -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/lib/Licensing.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/lib/Licensing.sol). Optionally, you can attach a `LicensingConfig` to an IP Asset (for a specific `licenseTermsId` attached to that asset) which contains fields like a `mintingFee` and a `licensingHook`, as shown below. +Вы можете опционально прикрепить `LicensingConfig` к IP-активу (для определённых `licenseTermsId`, связанных с этим активом), который содержит такие параметры, как `mintingFee` и `licensingHook`, как показано ниже. ```sol Licensing.sol -/// @notice This struct is used by IP owners to define the configuration -/// when others are minting license tokens of their IP through the LicensingModule. -/// When the `mintLicenseTokens` function of LicensingModule is called, the LicensingModule will read -/// this configuration to determine the minting fee and execute the licensing hook if set. -/// IP owners can set these configurations for each License or set the configuration for the IP -/// so that the configuration applies to all licenses of the IP. -/// If both the license and IP have the configuration, then the license configuration takes precedence. -/// @param isSet Whether the configuration is set or not. -/// @param mintingFee The minting fee to be paid when minting license tokens. -/// @param licensingHook The hook contract address for the licensing module, or address(0) if none -/// @param hookData The data to be used by the licensing hook. -/// @param commercialRevShare The commercial revenue share percentage. -/// @param disabled Whether the license is disabled or not. -/// @param expectMinimumGroupRewardShare The minimum percentage of the group’s reward share -/// (from 0 to 100%, represented as 100 * 10 ** 6) that can be allocated to the IP when it is added to the group. -/// If the remaining reward share in the group is less than the minimumGroupRewardShare, -/// the IP cannot be added to the group. -/// @param expectGroupRewardPool The address of the expected group reward pool. -/// The IP can only be added to a group with this specified reward pool address, -/// or address(0) if the IP does not want to be added to any group. +/// @notice Эта структура используется владельцами IP для настройки конфигурации +/// при выпуске токенов лицензий для их IP через LicensingModule. +/// Когда вызывается функция `mintLicenseTokens` модуля LicensingModule, он считывает +/// эту конфигурацию для определения комиссии за выпуск и выполняет лицензионный хук, если он установлен. +/// Владельцы IP могут устанавливать эти конфигурации для каждой лицензии +/// или на уровне всей IP, чтобы конфигурация применялась ко всем лицензиям актива. +/// Если конфигурация установлена и на уровне лицензии, и на уровне IP, конфигурация лицензии имеет приоритет. struct LicensingConfig { - bool isSet; - uint256 mintingFee; - address licensingHook; - bytes hookData; - uint32 commercialRevShare; - bool disabled; - uint32 expectMinimumGroupRewardShare; - address expectGroupRewardPool; + bool isSet; // Установлена ли конфигурация + uint256 mintingFee; // Комиссия за выпуск токена + address licensingHook; // Адрес контракта хука, если он установлен, иначе address(0) + bytes hookData; // Данные, используемые хуком + uint32 commercialRevShare; // Доля коммерческих доходов в процентах + bool disabled; // Отключена ли лицензия + uint32 expectMinimumGroupRewardShare; // Минимальная доля вознаграждения группы + address expectGroupRewardPool; // Ожидаемый пул вознаграждений группы } ``` +Параметры, такие как `mintingFee` и `commercialRevShare`, могут переписывать свои дубликаты, указанные в условиях лицензии. Это позволяет производным IP-активам (которые обычно не могут изменить условия лицензии) изменить определённые поля. -Fields like the `mintingFee` and `commercialRevShare` overwrite their duplicate in the license terms themselves. A benefit of this is that derivative IP Assets, which normally cannot change their license terms, are able to overwrite certain fields. +Параметр `licensingHook` — это адрес смарт-контракта, реализующего интерфейс `ILicensingHook.sol`. В нём содержится функция `beforeMintLicenseTokens`, которая запускается перед выпуском токена лицензии, что позволяет вставить дополнительную логику. -The `licensingHook` is an address to a smart contract that implements the `ILicensingHook.sol` interface, which contains a `beforeMintLicenseTokens` function which will be run before a user mints a License Token. This means you can insert logic to be run upon minting a license. +Сам хук определен ниже в другом разделе. Он содержит информацию о лицензии, о том, кто выпускает токен лицензии и кто его получает. -The hook itself is defined below in a different section. You can see it contains information about the license, who is minting the License Token, and who is receiving it. +### Настройка конфигурации лицензии -### Setting the License Config +Вы можете настроить конфигурацию лицензии с помощью функции `setLicenseConfig` в контракте [LicensingModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/licensing/LicensingModule.sol). -You can set the License Config by calling the `setLicenseConfig` function in the [LicensingModule.sol contract](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/licensing/LicensingModule.sol). +Вы можете прикрепить конфигурацию лицензии ко всему IP-активу, чтобы она применялась ко всем условиям лицензий, принадлежащих этой IP. Если установлены обе конфигурации (на уровне IP и на уровне лицензии), приоритет отдаётся конфигурации лицензии. Вы можете установить конфигурацию на IP в целом, передав `licenseTemplate == address(0)` и `licenseTermsId == 0` в функцию `setLicenseConfig`. -You can also attach the License Config to an IP Asset as a whole, so it will execute on every license term that belongs to the IP. Note that if both an IP-wide config and license-specific config are set, the license-specific config will take priority. You can set a config on the IP as a whole by passing `licenseTemplate == address(0)` and `licenseTermsId == 0` to the `setLicenseConfig` function. -### Logic that is Possible with License Config -1. **Max Number of Licenses**: The `licensingHook` (described in the next section) is where you can define logic for the max number of licenses that can be minted. For example, reverting the transaction if the max number of licenses has already been minted. -2. **Disallowing Derivatives**: If you register a derivative of an IP Asset, that derivative cannot change its License Terms as described [here](https://docs.story.foundation/docs/license-terms#inherited-license-terms). You can be wondering: "What if I, as a derivative, want to disallow derivatives of myself, but my License Terms allow derivatives and I cannot change this?" To solve this, you can simply set `disabled` to true. -3. **Minting Fee**: Similar to #2 above... what about the minting fee? Although you cannot change License Terms on a derivative IP Asset (and thus the minting fee inside of it), you can change the minting fee for that derivative by modifying the `mintingFee` in the License Config, or returning a `totalMintingFee` from the `licensingHook` (described in the next section). -4. **Commercial Revenue Share**: Similar to #2 and #3 above, you can modify the `commercialRevShare` in the License Config. -5. **Dynamic Pricing for Minting a License Token**: Set dynamic pricing for minting a License Token from an IP Asset based on how many total have been minted, how many licenses the user is minting, or even who the user is. All of this data is available in the `licensingHook` (described in the next section). +### Примеры логики с конфигурацией лицензии -... and more. +1. **Ограничение количества лицензий**: Через `licensingHook` можно ограничить максимальное количество лицензий. Например, транзакция будет отменена, если достигнуто максимальное число лицензий. +2. **Запрет на производные**: Если вы зарегистрируете производный IP-актив, вы не сможете изменить его лицензионные условия, как описано [здесь] (https://docs.story.foundation/docs/license-terms#inherited-license-terms). Вы можете задаться вопросом: «А что, если я, как производный IP-актив, хочу запретить производные от себя, но мои Лицензионные условия разрешают производные, могу ли я это изменить?». Да, вы можете просто установить `disabled` в true. +3. **Комиссия за выпуск**: Аналагочино #2 выше... а что насчет комиссии? Хотя вы не можете изменить условия лицензии на родительском IP-активе (и, соответственно, плату за выпуск внутри него), вы можете изменить плату за выпуск для производного актива, изменив `mintingFee` в конфигурации лицензии или вернув `totalMintingFee` из `licensingHook` (описано в следующем разделе). +4. **Коммерческая доля дохода**: Аналогично #2 и #3 вы можете изменить `commercialRevShare` в конфигурации лицензии. +5. **Динамическое ценообразование**: Установите динамическую стоимость выпуска лицензии на основе количества уже выпущенных токенов, количества лицензий, которые запрашивает пользователь, или даже личности пользователя. Всё это доступно в `licensingHook` (далее). -### Restrictions +... и так далее. -If you update the License Config, you cannot decrease the `commercialRevShare` percentage. You can only increase it. +### Ограничения -## Licensing Hook +После обновления конфигурации лицензии нельзя уменьшать процент `commercialRevShare`. Его можно только увеличивать. -> 🗒️ Contract +## Хук Лицензирования + +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/licensing/ILicensingHook.sol#L26). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/licensing/ILicensingHook.sol#L26). -The `beforeMintLicenseTokens` function, which acts as a hook, is a function that can be called before a License Token is minted to implement custom logic and determine the final `totalMintingFee` of that License Token. The owner of an IP Asset must set the License Config (of which the hook is contained in), with their own implementation of the `beforeMintLicenseTokens` function, for this to be called. +Функция `beforeMintLicenseTokens`, которая выступает в качестве хука, вызывается перед выпуском токена лицензии для выполнения пользовательской логики и определения окончательной суммы комиссии `totalMintingFee` за выпуск токена. Владелец IP-актива должен настроить конфигурацию лицензии (в которой содержится хук) с собственной реализацией функции `beforeMintLicenseTokens`, чтобы она могла быть вызвана. -It can also be used to implement various checks and logic, as [outlined above](https://docs.story.foundation/docs/license-config-hook#logic-that-is-possible-with-license-config). +Хук также может быть использован для выполнения различных проверок и логики, как [описано выше](https://docs.story.foundation/docs/license-config-hook#logic-that-is-possible-with-license-config). -> 🚧 Warning! +> 🚧 Внимание! > -> Beware of potentially malicious implementations of external license hooks. Please first verify the code of the hook you choose because it may be not reviewed or audited by the Story team. +> Будьте осторожны с потенциально вредоносными реализациями внешних хуков лицензий. Сначала проверьте код выбранного хука, так как он может не быть проверен или аудирован командой Story. ```sol ILicensingHook.sol -/// @notice This function is called when the LicensingModule mints license tokens. -/// @dev The hook can be used to implement various checks and determine the minting price. -/// The hook should revert if the minting is not allowed. -/// @param caller The address of the caller who calling the mintLicenseTokens() function. -/// @param licensorIpId The ID of licensor IP from which issue the license tokens. -/// @param licenseTemplate The address of the license template. -/// @param licenseTermsId The ID of the license terms within the license template, -/// which is used to mint license tokens. -/// @param amount The amount of license tokens to mint. -/// @param receiver The address of the receiver who receive the license tokens. -/// @param hookData The data to be used by the licensing hook. -/// @return totalMintingFee The total minting fee to be paid when minting amount of license tokens. +/// @notice Функция вызывается LicensingModule при выпуске токенов лицензии. +/// @dev Хук может быть использован для различных проверок и определения стоимости выпуска. +/// @param caller Адрес вызывающего, который вызывает функцию mintLicenseTokens(). +/// @param licensorIpId ID IP-актива лицензиара, из которого выпускаются токены. +/// @param licenseTemplate Адрес шаблона лицензии. +/// @param licenseTermsId ID условий лицензии в шаблоне. +/// @param amount Количество выпускаемых токенов. +/// @param receiver Адрес получателя токенов. +/// @param hookData Данные, используемые хуком. +/// @return totalMintingFee Итоговая сумма комиссии за выпуск. function beforeMintLicenseTokens( address caller, address licensorIpId, @@ -118,17 +104,16 @@ function beforeMintLicenseTokens( ) external returns (uint256 totalMintingFee); ``` -Note that it returns the `totalMintingFee`. You may be wondering, "I can set the minting fee in the License Terms, in the `LicenseConfig`, and return a dynamic price from `beforeMintLicenseTokens`. What will the final minting fee actually be?" Here is the priority: - +Обратите внимание, что функция возвращает `totalMintingFee`. Вы можете задаться вопросом: «Я могу установить комиссию за выпуск в условиях лицензии, в конфигурации лицензии и вернуть динамическую стоимость из `beforeMintLicenseTokens`. Какая комиссия будет в итоге?» @@ -137,17 +122,17 @@ Note that it returns the `totalMintingFee`. You may be wondering, "I can set the diff --git a/docs/Concepts/licensing-module/license-template.md b/docs/Concepts/licensing-module/license-template.md index a5d65ec..f4fcd3b 100644 --- a/docs/Concepts/licensing-module/license-template.md +++ b/docs/Concepts/licensing-module/license-template.md @@ -1,8 +1,7 @@ --- -title: License Template +title: Шаблон Лицензии excerpt: >- - A legal framework, written in code ("programmable"), that defines various - licensing terms for an IP. + Юридическая структура, написанная в виде программируемого кода, которая определяет различные условия лицензирования для интеллектуальной собственности (IP). deprecated: false hidden: false metadata: @@ -12,37 +11,37 @@ metadata: next: description: '' --- -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract for the [💊 Programmable IP License (PIL)](doc:programmable-ip-license), the first and currently only example of a License Template, [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/licensing/PILicenseTemplate.sol). +> Ознакомиться со смарт контрактом [💊 Программируемой Лицензии IP (PIL)](doc:programmable-ip-license), первого и на данный момент единственного примера Шаблона лицензии, можно [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/licensing/PILicenseTemplate.sol). -A License Template is a legal framework, written in code ("programmable"), that defines various licensing terms for an IP. Such as: +Шаблон лицензии — это юридическая структура, написанная в виде программируемого кода, которая определяет различные условия лицензирования для IP. Примеры таких условий: -* "Is commercial use allowed?" - true/false (bool) -* "Is the license transferrable?" - true/false (bool) -* "If commercial, what % of royalty do I receive?" - number +* "Разрешено ли коммерческое использование?" - true/false (bool) +* "Можно ли передавать лицензию?" - true/false (bool) +* "Если коммерческое использование разрешено, какой процент роялти я получу?" - number -These terms and values differ per License Template. +Эти условия и их значения различаются в зависимости от Шаблона лицензии. -The first (and currently only) example of a License Template was developed by the Story team directly, and is called the Programmable IP License (PIL :pill:). +Первый (и на данный момент единственный) пример Шаблона лицензии был разработан командой Story и называется Программируемая Лицензия интеллектуальной собственности (Programmable IP License, PIL 💊). -> 💊 Programmable IP License Framework +> 💊 Программируемая структура лицензии IP > -> To learn about the first implementation of a License Template, [read this page](doc:programmable-ip-license-pil). +> Чтобы узнать больше о первой реализации Шаблона лицензии [читайте эту страницу](doc:programmable-ip-license-pil). -## License Template Requirements +## Требования к Шаблонам лицензий -License Templates are responsible for: +Шаблоны лицензий обязаны: -* Providing a link to the actual, off-chain, legal contract template, with all the parameters, their possible values, and the correspondent legalese, in `licenseTextUrl`. - * For a licensing framework to be compatible with Story Protocol, the legal text **must** be clear and parametrized, with each licensing parameter establishing the possible outcomes of each value. - * The parameter values in each License Template (called "License Template terms") drive the legal text for each license agreement. -* Defining a `struct` with the particular definitions of the parameters in accordance, which must be encoded into the License Terms struct (described below). -* Providing registration methods for the License Terms, and getters. -* **Verifying** that both the **minter** and the address **linking a derivative are allowed by the License Template terms to perform those actions**. - * These conditions could be enforced by the License Template itself or through hooks. They can range from limitations on the derivative creations, token-gating LNFT holders, creative control from licensors, KYC, etc. It's up to the implementation of each License Template. -* **Verifying that the License Terms are compatible if a derivative has or will have multiple parents** +* Предоставлять ссылку на фактический оффчейн-шаблон (англ. off-chain) юридического контракта со всеми параметрами, их возможными значениями и соответствующими юридическими формулировками в `licenseTextUrl`. + * Для того чтобы структура лицензирования была совместима с протоколом Story, юридический текст **должен** быть четким и параметризованным. Каждый параметр лицензии должен устанавливать возможные варианты его значений. + * Значения параметров в каждом Шаблоне Лицензии (так называемые "условия Шаблона Лицензии") определяют юридический текст для каждого лицензионного соглашения. +* Определять `struct` с конкретными определениями параметров в соответствии с шаблоном, который должен быть закодирован в структуре условий лицензии (описано ниже). +* Обеспечивать методы регистрации для условий лицензии и методы для их получения. +* **Проверять**, что как **минтер** (анг. minter), так и адрес, **связывающий производное произведение, имеют право совершать такие действия согласно условиям Шаблона Лицензии**. + * Эти условия могут быть реализованы самим Шаблоном Лицензии или с использованием хуков. Они могут включать ограничения на создание производных произведений, ограничение доступа по токенам LNFT, творческий контроль от лицензиаров, KYC и т. д. Всё это зависит от реализации каждого конкретного Шаблона Лицензии. +* **Проверять совместимость условий лицензии, если у производного произведения есть или будет несколько родителей.** -## Create Your Own Template +## Создайте свой собственный Шаблон -You can create your own License Template (like the PIL), but it must be approved by the Story team to be fully embedded into the protocol. +Вы можете создать свой собственный Шаблон лицензии (как PIL), но он должен быть одобрен командой Story, чтобы быть полностью встроенным в протокол. diff --git a/docs/Concepts/licensing-module/license-terms.md b/docs/Concepts/licensing-module/license-terms.md index 9366c41..9224e1a 100644 --- a/docs/Concepts/licensing-module/license-terms.md +++ b/docs/Concepts/licensing-module/license-terms.md @@ -1,8 +1,7 @@ --- -title: License Terms +title: Условия Лицензии excerpt: >- - A particular combination of values from a License Template that define how - others can interact with your IP. + Комбинация значений из Шаблона лицензии, которая определяет, как другие могут взаимодействовать с вашим IP-активом. deprecated: false hidden: false metadata: @@ -12,36 +11,35 @@ metadata: next: description: '' --- -> 🍦 Example License Terms +> 🍦 Пример условий лицензии > -> View some popular combinations of PIL License Terms, also known as "flavors", [here](https://docs.story.foundation/docs/pil-flavors#/). +> Ознакомьтесь с популярными комбинациями условий лицензии PIL, также известными как «вкусы», [здесь](https://docs.story.foundation/docs/pil-flavors#/). -License Terms are a particular combination of values from a [License Template](doc:license-template). Indeed, there can and will exist **multiple** License Terms (variations) for each License Template. You can imagine that a License Template generates many License Term variations. +Условия лицензии представляют собой конкретную комбинацию значений из [Шаблона Лицензии](doc:license-template). Фактически, для каждого Шаблона лицензии могут и будут существовать **множество** вариаций Условий лицензии. Можно представить, что Шаблон лицензии генерирует множество вариаций Условий лицензии. -Once registered, **License Terms are immutable — they can't be tampered with or altered**, even by the License Template that generated it. +После регистрации **Условия лицензии неизменяемы — их нельзя модифицировать или изменять** , даже Шаблоном лицензии, который их сгенерировал. -Additionally, License Terms have a unique numeric ID within the License Template they stem from. This makes License Terms reusable, meaning if someone creates License Terms with a specific set of values, it only needs to be created once and can be used by anyone else. +Кроме того, Условия лицензии имеют уникальный числовой идентификатор в рамках Шаблона лицензии, от которого они произошли. Это делает Условия лицензии повторно используемыми: если кто-то создаёт Условия лицензии с определённым набором значений, они создаются только один раз и могут использоваться кем угодно. -For example, a particular set of term values of the [Programmable IP License (PIL💊)](doc:programmable-ip-license-pil), such as non-commercial usage + derivatives allowed + free minting, defines a unique License Terms with an associated ID. +Например, определённый набор значений условий в [Программируемой Лицензии IP (PIL💊)](doc:programmable-ip-license-pil), таких как некоммерческое использование + разрешённые производные + бесплатный выпуск, определяет уникальные Условия лицензии с соответствующим идентификатором. -## License Terms Attached to IP Asset - -The owner of a root IP Asset can attach License Terms to signal to other users that they can mint License Tokens of those terms to create a derivative of this IP Asset. **Once License Terms are attached to an IP Asset, it is now considered "public" and anyone can mint a License Token using those terms.** +## Условия лицензии, прикреплённые к IP-активу +Владелец корневого IP-актива может прикрепить Условия лицензии, чтобы сигнализировать другим пользователям, что они могут выпускать Лицензионные токены с этими условиями для создания производных IP-активов. **Как только Условия лицензии прикреплены к IP-активу, он теперь считается "публичным", и любой может выпустить Лицензионный токен с использованием этих условий.** -## Inherited License Terms +## Наследуемые условия лицензии -On the other hand, derivative IP Assets inherit their License Terms from the parent IP Asset. This means that when an IP Asset registers itself as a derivative, it burns the License Token and inherits the associated License Terms. **The owner of this derivative cannot set new License Terms.** +С другой стороны, производные IP-активы наследуют свои Условия лицензии от родительского IP-актива. Это означает, что когда IP-актив регистрируется как производный, он сжигает Лицензионный токен и наследует связанные с ним Условия лицензии. **Владелец этого производного IP-актива не может устанавливать новые Условия лицензии.** -> 📘 Changing Certain License Terms on a Derivative +> 📘 Изменение определённых Условий лицензии для производной IP > -> You may be wondering: "if I cannot set new License Terms on my derivative, does that also mean I can't change the minting fee, or disallowing more derivatives, on my derivative?" +> Возможно, вы задаётесь вопросом: «Если я не могу установить новые Условия лицензии для своей производной IP, значит ли это, что я не могу изменить комиссию за выпуск или запретить создание новых производных?» > -> Thankfully, there is a way to get around this! Although you cannot change License Terms on a derivative IP, you can utilize the [License Config to implement special behaviors](doc:license-config-hook). +> К счастью, существует способ обойти это! Хотя вы не можете изменить Условия лицензии для производной IP, вы можете использовать [Конфигурацию лицензии для реализации особого поведения](doc:license-config-hook). -## Expiration +## Срок действия -License Terms support an `expiration` time. Once License Terms expire, any derivatives that abide by that license will no longer be able to generate revenue or create further derivatives. If an IP Asset is a derivative of multiple parents, it will expire when the soonest expiration time between the two parents is reached. \ No newline at end of file +Условия лицензии поддерживают параметр `expiration`. Как только Условия лицензии истекают, любые производные, соответствующие этой лицензии, больше не смогут генерировать доход или создавать новые производные. Если IP-актив является производным от нескольких родительских активов, его срок действия истечёт, когда наступит ближайшая дата истечения срока среди двух родительских активов. \ No newline at end of file diff --git a/docs/Concepts/licensing-module/license-token.md b/docs/Concepts/licensing-module/license-token.md index 850e5c3..b2fed6d 100644 --- a/docs/Concepts/licensing-module/license-token.md +++ b/docs/Concepts/licensing-module/license-token.md @@ -1,8 +1,7 @@ --- -title: License Token +title: Токен Лицензии excerpt: >- - An ERC-721 NFT that allows you to register your IP as a derivative of another, - based on the License Terms defined in the token. +ERC-721 NFT, который позволяет зарегистрировать вашу интеллектуальную собственность (IP) как производное от другой на основе Условий Лицензии, определенных в токене. deprecated: false hidden: false metadata: @@ -12,44 +11,44 @@ metadata: next: description: '' --- -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/LicenseToken.sol). +> Ознакомиться со смарт-контрактом можно [здесь](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/LicenseToken.sol). -A **License Token** is represented as an **ERC-721 NFT** and contains the specific [License Terms](doc:license-terms) it represents. Its associated `licenseTokenId` is global, as there is one License Token contract. +**Токен Лицензии** представлен в виде **ERC-721 NFT** и содержит конкретные [Условия Лицензии](doc:license-terms), которые он представляет. Его связанный `licenseTokenId` является глобальным, так как существует только один контракт Токена Лицензии. -Once License Terms are attached to an IP Asset, it becomes public so that anyone can mint a License Token for those terms. A License Token is burned when it is used to register another IP as a derivative of the original IP Asset. +После того как Условия лицензии прикрепляются к IP-активу, он становится общедоступным, что позволяет любому человеку создать Токен Лицензии с этими условиями. Токен Лицензии сжигается, когда он используется для регистрации другго IP как производного от оригинального актива. - A diagram showing what happens when a License Token is minted. + Диаграмма, показывающая процесс создания Токена Лицензии. -## Private Licenses +## Приватные лицензии -In order to mint a private License Token, the owner of a root IP Asset can issue License Tokens that have terms **not yet attached to the IP Asset itself**. It is important to also note that derivative IP Assets cannot issue private licenses because it is restricted to only issue licenses of its inherited terms. +Для создания приватного Токена Лицензии владелец корневого IP-актива может выпустить Токены Лицензии с условиями, которые еще не прикреплены к самому активу. Также важно отметить, что производные IP-активы не могут выпускать приватные лицензии, поскольку они ограничены выпуском лицензий только с унаследованными условиями. -## Transferability of the License Token +## Передаваемость Токена Лицензии -License Tokens might be transferrable or not, depending on the values of the License Terms terms they point to. +Токены Лицензии могут быть передаваемыми или нет, в зависимости от условий Условий Лицензии, к которым они привязаны. -Once a non-transferrable License Token is minted to a recipient, it is locked there forever. +После создания непередаваемого Токена Лицензии и передачи его получателю он остается привязанным к этому получателю навсегда. -## Registering a Derivative +## Регистрация производного -There are two ways to register a derivative IP Asset. +Есть два способа зарегистрировать производный IP-актив. -> 📘 Small Note +> 📘 Небольшое замечание > -> An IP Asset can only register as a derivative one time. If an IP Asset has multiple parents, it must register both at the same time. Once an IP Asset is a derivative, it cannot link any more parents. +> IP-актив может быть зарегистрирован как производный только один раз. Если у IP-актива несколько родительских активов, они должны быть зарегистрированы одновременно. После регистрации как производный, актив не может привязывать новые родительские активы. -### 1. Using an Existing License Token +### 1. Использование существующего Токена лицензии -A License Token is burned when it is used to register another IP as a derivative of the original IP Asset. +Токен лицензии сжигается, когда он используется для регистрации другого IP как производного от оригинального актива. -### 2. Registering a Derivative Directly +### 2. Прямая регистрация производного -You can also register a derivative directly, without the need for a License Token. Remember that if License Terms are attached to an IP Asset it is public to mint the License Token anyway, so this is simply a convenient way to go about it, thus skipping the middle step of minting a License Token. +Вы также можете зарегистрировать производный актив напрямую, без Токена Лицензии. Помните, что если Условия Лицензии прикреплены к IP-активу, он становится публичным, и любой может создать Токен Лицензии. Таким образом, это просто удобный способ избежать промежуточного шага создания Токена Лицензии. From 470b38172c2845ff58b234f068c225c8326f36d3 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Wed, 1 Jan 2025 19:18:33 +0300 Subject: [PATCH 04/10] PIL module --- .../Concepts/programmable-ip-license/index.md | 85 +++++--- .../programmable-ip-license/pil-flavors.md | 200 +++++++++--------- .../programmable-ip-license/pil-terms.md | 151 ++++++------- 3 files changed, 224 insertions(+), 212 deletions(-) diff --git a/docs/Concepts/programmable-ip-license/index.md b/docs/Concepts/programmable-ip-license/index.md index 7da2037..0d31bab 100644 --- a/docs/Concepts/programmable-ip-license/index.md +++ b/docs/Concepts/programmable-ip-license/index.md @@ -1,6 +1,6 @@ --- -title: 💊 Programmable IP License (PIL) -excerpt: Story Programmable IP License +title: 💊 Программируемая Лицензия IP (PIL) +excerpt: Программируемая Лицензия IP Story deprecated: false hidden: false metadata: @@ -10,56 +10,71 @@ metadata: next: description: '' --- -> ⏩ Skip the Read - 1 Minute Summary +> ⏩ Читать не обязательно - 1-минутное саммари > -> The Programmable IP License, also called the PIL, is a legal off-chain document based on US copyright law. It is the first and currently only example of a [License Template](doc:license-template), created by the Story team. A License Template is simply a legal document containing a set of pre-defined terms that people must set, like: +> Программируемая Лицензия IP (PIL) — это юридический документ вне блокчейна, основанный на законе США об авторском праве. Это первый и пока единственный пример [Шаблона Лицензии](doc:license-template), созданный командой Story. Шаблон Лицензии — это просто юридический документ с набором заранее определённых параметров, которые необходимо установить, например: > -> * `Commercial Use` - can someone use my work commercially? -> * `Minting Fee` - the cost of minting a license to use my work in your own works. -> * `Derivatives Attribution` - does someone have to credit me in their derivative works? +> * `Коммерческое использование` — может ли кто-то использовать мою работу в коммерческих целях? +> * `Плата за выпуск` — стоимость выпуска лицензии на использование моей работы в своих произведениях. +> * `Указание авторства производных` — должен ли кто-то указывать моё авторство в производных работах? > -> In code, these terms form a struct that represent their real, legal off-chain counterparts. +> В коде эти параметры формируют структуру данных, которая соответствует их юридическим аналогам вне блокчейна. > -> To see all of the terms defined by the PIL and their associated explanations in code, go [here](doc:pil-terms). To see example configurations ("flavors") of the PIL, go [here](doc:pil-flavors). +> Посмотреть все условия PIL и их связанные части в коде [тут](doc:pil-terms). Примеры конфигураций ("вариантов" анг. flavors) PIL [тут](doc:pil-flavors). -> 📘 PIL Legal Text +> 📘 Текст PIL > -> Check out the actual PIL legal text [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Testnet.pdf). It is very human-readable for a legal text! +> Ознакомьтесь с полным текстом PIL [здесь](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Testnet.pdf). Он написан простым и понятным языком как для юридического документа! -## The Background Story +## История создания -We designed Story Protocol's [Licensing Module](doc:licensing-module) to power the expansion of emerging forms of creativity, such as authorized remixes and co-creation. Our protocol can support any media format or project, ranging from user-generated social videos & images to Hollywood-grade collaborative storytelling. +We searched for a form of a "universal license" that could support these emerging activities at scale. Hat tip to [Creative Commons](https://creativecommons.org/mission/), [Arweave](https://mirror.xyz/0x64eA438bd2784F2C52a9095Ec0F6158f847182d9/AjNBmiD4A4Sw-ouV9YtCO6RCq0uXXcGwVJMB5cdfbhE), A16Z / [Can’t Be Evil,](https://a16zcrypto.com/posts/article/introducing-nft-licenses/) The [Token-Bound NFT License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf) and music rights organizations, among others. But we simply couldn't find one framework or agreement robust enough - so with our expert legal counsel (with special thanks to Ghaith Mahmood and Heather Liu) we created one ourselves! **Introducing the Story Protocol Programmable IP License (PIL:pill:), the first example of a [License Template](doc:license-template) on the protocol.** -Intellectual property owners can permit other parties to use, or build on, their work by granting rights in a license, which can be for profit or for the common good. In the media world, these licenses are generally highly tailored contracts, which vary by media formats and the unique needs of licensors - often requiring unique expertise (via lawyers) and significant resources to create. +[Модуль Лицензирования](doc:licensing-module) Story Protocol (Licensing Module) был создан для поддержки новых форм творчества, таких как разрешённые ремиксы и совместное создание. Протокол поддерживает любые форматы медиа и проекты — от пользовательских видео и изображений до создания контента уровня Голливуда. -We searched for a form of a "universal license" that could support these emerging activities at scale. Hat tip to [Creative Commons](https://creativecommons.org/mission/), [Arweave](https://mirror.xyz/0x64eA438bd2784F2C52a9095Ec0F6158f847182d9/AjNBmiD4A4Sw-ouV9YtCO6RCq0uXXcGwVJMB5cdfbhE), A16Z / [Can’t Be Evil,](https://a16zcrypto.com/posts/article/introducing-nft-licenses/) The [Token-Bound NFT License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf) and music rights organizations, among others. But we simply couldn't find one framework or agreement robust enough - so with our expert legal counsel (with special thanks to Ghaith Mahmood and Heather Liu) we created one ourselves! **Introducing the Story Protocol Programmable IP License (PIL:pill:), the first example of a [License Template](doc:license-template) on the protocol.** +Владельцы интеллектуальной собственности могут разрешать третьим сторонам использовать или развивать свои работы, предоставляя права по лицензии, будь то в коммерческих целях или на благо общества. В медиаиндустрии такие лицензии, как правило, представляют собой индивидуализированные контракты, которые зависят от формата медиа и нужд лицензиаров. Для их создания часто требуется юридическая экспертиза и значительные ресурсы. + +Мы искали «универсальную лицензию», которая могла бы поддерживать эти новые виды творчества. Вдохновение черпалось у [Creative Commons](https://creativecommons.org/mission/), [Arweave](https://mirror.xyz/0x64eA438bd2784F2C52a9095Ec0F6158f847182d9/AjNBmiD4A4Sw-ouV9YtCO6RCq0uXXcGwVJMB5cdfbhE), A16Z / [Can’t Be Evil](https://a16zcrypto.com/posts/article/introducing-nft-licenses/), [Лицензии для NFT](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf), и музыкальных правообладателей. + +Однако нам не удалось найти подходящий единый и достаточно универсальный шаблон. Вместе с опытными юристами (отдельное спасибо Гаиту Махмуду (Ghaith Mahmood) и Хизер Лю (Heather Liu)) мы создали собственный! **Представляем Программируемую Лицензию на интеллектуальную собственность (PIL 💊), первый пример [Шаблона Лицензии](doc:license-template) в рамках нашего протокола.** + +## Свойства PIL + +Протокол и лицензия тесно связаны друг с другом. Параметры, указанные в нашей лицензии, реализуются в блокчейне через Story Protocol, соединяя код и юридическую базу. Это обеспечивает прозрачность, автономность и отсутствие необходимости в разрешении для интеллектуальной собственности. + +Уникальные особенности PIL: + +* **Универсальность:** +Чтобы использовать открытые лицензии, стороны должны согласовать конкретную версию. Например, для Creative Commons соглашение о коммерческом использовании отличается от соглашения о некоммерческом использовании. PIL объединяет всё в единый, гибкий договор. + +* **Без разрешений (анг. permission-less):** +В духе Web3 наша лицензия подразумевает создание производных работ без необходимости запрашивать разрешение. Для некоторых известных брендов всё же можно включить параметр «одобрение перед созданием производных». -## PIL Properties +* **Коммерческое использование:** +Мы предлагаем не просто выбор между коммерческим и некоммерческим использованием. Создатели могут ограничивать права на коммерческое использование только определёнными сторонами, например, держателями NFT. -The protocol and the license work closely together. The parameters outlined in our license are enforced on-chain via Story Protocol, bridging code and law. By doing so, we unlock the benefit of transparent, autonomous, and permission-less smart contracts for the world of intellectual property. +* **Прогрессивная сложность:** +Каждый параметр предоставляет дополнительные теги для настройки, если это необходимо. Например, если лицензия ограничена определённой страной, можно выбрать «США», по умолчанию применяется глобальный охват. -Some of our unique facets include: +* **Адаптивность:** +Параметры можно использовать для настройки существующих соглашений и их интеграции с нашими смарт-контрактами. -* **Universal**: To use one of the existing open source licenses, the parties must agree on using one particular version. For Creative Commons, the agreement for commercial use is distinct from the non-commercial contract. Separate versions permitting derivatives, or relicensing, are needed to address different requirements. This results in many different licenses to represent each selection of multiple options. Why can’t there be a single flexible agreement to rule them all? -* **Permission-less**: A goal of Web3 is permission-less licensing. Creating derivatives without requesting permission (or forgiveness!) is the default in our agreement. For certain IPAs, particularly those from established brands or media properties, approvals might be required before derivatives are created. That’s OK - there’s a tag for that. -* **Commercial Use**: To effectively support commercial use, we need more than a simple binary selection between commercial and non-commercial, A media company or creator might want to limit the parties that can commercialize a work (perhaps certain NFT holders), have a clear and transparent definition of commercial use, or may have constraints on activity in certain media formats (perhaps from pre-existing license arrangements). -* **Progressive Complexity**: Under each parameter, the IPA can select tags appropriate to its project. Absent a selection, we have provided defaults. For example, if you agree that your license is limited to a particular country you might select "United States." To keep it simple, our default is global. This allows an experienced media company to apply the same business logic in current usage, while the hobbyist could apply a reasonable and industry-standard default. -* **Adaptable**: Not everyone may want to use our form. We can separately publish our parameters as a license library, which would allow others to easily map their existing agreements to our smart contracts. -* **Content Standards**: A healthy ratings system is crucial for mass market media. The original licensor can select from certain standards that content creators must stick to. +* **Контент-стандарты:** +Для массового медиа важна система рейтингов. Оригинальный лицензиар может задавать определённые ограничения для создаваемого контента. -In future versions, we might consider adding: +Грядущие версии могут включать: -* Rules for when a remix becomes a new work -* Co-creation / co-ownership terms -* Features for music licenses -* Sub-licensing capabilities -* Fractionalization permissions and rights -* New royalty pool structures +* Правила, определяющие, когда ремикс становится новым произведением +* Условия совместного творчества/владения +* Особенности для музыкальных лицензий +* Возможности суб-лицензирования +* Права на дробление лицензий +* Новые структуры распределения роялти -## Feedback +## Обратная связь -We are excited to collect feedback and collaborate with IP owners to unlock the potential of their works - please let us know what you think! We can be reached at `legal@storyprotocol.xyz`. +Мы будем рады любым отзывам и сотрудничеству с владельцами интеллектуальной собственности! Напишите нам на почту: `legal@storyprotocol.xyz`. -> 📘 PIL Legal Text +> 📘 Текст PIL > -> Check out the actual PIL legal text [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Testnet.pdf). It is very human readable for a legal text! +> Полный текст PIL можно найти [здесь] (https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Testnet.pdf). Он написан простым и понятным языком как для юридического документа! diff --git a/docs/Concepts/programmable-ip-license/pil-flavors.md b/docs/Concepts/programmable-ip-license/pil-flavors.md index 126bba8..8515c18 100644 --- a/docs/Concepts/programmable-ip-license/pil-flavors.md +++ b/docs/Concepts/programmable-ip-license/pil-flavors.md @@ -1,67 +1,69 @@ --- -title: PIL Flavors (examples) -excerpt: '' +title: Варианты PIL (примеры) +excerpt: "" deprecated: false hidden: false metadata: - title: '' - description: '' + title: "" + description: "" robots: index next: - description: '' + description: "" --- -The [💊 Programmable IP License (PIL)](doc:programmable-ip-license) is very configurable, but we support popular pre-configured License Terms (also known as "flavors") for ease of use. We expect these to be the most popular options: -## Flavor #1: Non-Commercial Social Remixing +[💊 Программируемая Лицензия IP (PIL)](doc:programmable-ip-license) хорошо настраивается, но для удобства использования мы поддерживаем популярные предварительно настроенные лицензионные условия (также известные как «варианты»). Мы ожидаем, что эти варианты будут наиболее востребованы: -> 📘 Default Terms +## Вариант №1: Некоммерческий социальный ремикс + +> 📘 Условия по умолчанию > -> This flavor is already registered as`licenseTermsId = 1` on Story. **In addition, every single IP Asset has these terms attached by default.** +> Этот вариант уже зарегистрирован как `licenseTermsId = 1` в Story. Кроме того, все объекты IP имеют эти условия по умолчанию. -Let the world build on and play with your creation. This license allows for endless free remixing while tracking all uses of your work while giving you full credit. Similar to: TikTok plus attribution. +Позвольте миру создавать и играть с вашей работой. Эта лицензия позволяет бесконечно свободно создавать ремиксы, отслеживая использование вашей работы и предоставляя вам полный кредит за оригинал. Похоже на TikTok с добавлением атрибуции. -### What others can do? +### Что могут делать другие?
- Minting Fee + Комиссия - Importance + Приоритет
- The `totalMintingFee` returned from `beforeMintLicenseTokens` + `totalMintingFee` из `beforeMintLicenseTokens` - Highest Priority + Высочайший
- The `mintingFee` set in the `LicenseConfig` + `mintingFee` из конфигурации лицензии @@ -157,11 +142,11 @@ Note that it returns the `totalMintingFee`. You may be wondering, "I can set the
- The `mintingFee` set in the License Terms + `mintingFee` из условий лицензии - Lowest Priority + Низкий
+ @@ -69,12 +71,13 @@ Let the world build on and play with your creation. This license allows for endl +
- Others can + Могут - Others cannot + Не могут
- ✅ Remix this work + ✅ Делать ремиксы на эту работу (`derivativesAllowed == true`) - ❌ Commercialize the original and derivative works + ❌ Использовать оригинал и производные работы в коммерческих целях (`commercialUse == false`)
- ✅ Distribute their remix anywhere + ✅ Распространять ремиксы где угодно - ❌ Claim credit for the remix as original work + ❌ Присваивать авторство за ремиксы как за оригинал (`derivativesAttribution == true`)
- ✅ Credit you appropriately + ✅ Указывать вас как автора оригинальной работы (`derivativesAttribution == true`)
-###  PIL Term Values +###  Значения параметров PIL -* **On-chain**: +- **На блокчейне**: ```sol Solidity PILTerms({ @@ -98,56 +101,57 @@ PILTerms({ }); ``` -* **Off-chain:** +- **Вне блокчейна:** -| Parameter | Options / Tags | -| --------------------------------- | --------------------------------------------------------------------------- | -| Territory | No restrictions | -| Channels of Distribution | No Restriction | -| Attribution | True | -| Content Standards | No Restriction | -| Sublicensable | False | -| AI Learning Models | True | -| Restriction on Cross-Platform Use | False | -| Governing Law | California | -| Alternative Dispute Resolution | Tag: Alternative-Dispute-Resolution Ledger-Authoritative-Dispute-Resolution | -| Additional License Parameters | None | +| Параметр | Опции/Метки | +| ------------------------------------------------- | ----------------------------------------------------------------------------- | +| Территория | Без ограничений | +| Каналы распостранения | Без ограничений | +| Атрибуция | Обязательно | +| Стандарты контента | Без ограничений | +| Возможность сублицензирования | Нет | +| Обучение ИИ | Разрешено | +| Ограничения по использованию на разных платформах | Нет | +| Применимое право | Калифорния | +| Альтернативное разрешение споров | Метка: Alternative-Dispute-Resolution Ledger-Authoritative-Dispute-Resolution | +| Дополнительные параметры лицензии | Отсутствуют | -## Flavor #2: Commercial Use +## Вариант №2: Коммерческое использование -Retain control over reuse of your work, while allowing anyone to appropriately use the work in exchange for the economic terms you set. This is similar to Shutterstock with creator-set rules. +Сохраняйте контроль над использованием вашей работы, позволяя другим использовать её на условиях, которые вы устанавливаете. Похоже на Shutterstock с правилами, установленными создателем. -### What others can do? +### Что могут делать другие? + @@ -158,19 +162,20 @@ Retain control over reuse of your work, while allowing anyone to appropriately u +
- Others can + Могут - Others cannot + Не могут
- ✅ Purchase the right to use your creation - (`defaultMintingFee` is set) + ✅ Покупать право использовать вашу работу + (`defaultMintingFee` задана) - ❌ Claim credit for the original work + ❌ Присваивать авторство за оригинальную работу (`commercialAttribution == true`)
- ✅ Commercialize the original and derivative works + ✅ Использовать оригинал и производные работы в коммерческих целях (`commercialUse == true`)
- ✅ Distribute their remix anywhere + ✅ Распространять ремиксы где угодно
-###  PIL Term Values +### Значения параметров PIL -* **On-chain**: +- **На блокчейне**: ```sol Solidity PILTerms({ @@ -194,79 +199,80 @@ PILTerms({ }) ``` -* **Off-chain** +- **Вне блокчейна** -| Parameter | Options / Tags | -| --------------------------------- | --------------------------------------------------------------------------- | -| Territory | No restrictions | -| Channels of Distribution | No Restriction | -| Attribution | True | -| Content Standards | No Restriction | -| Sublicensable | False | -| AI Learning Models | True | -| Restriction on Cross-Platform Use | False | -| Governing Law | California | -| Alternative Dispute Resolution | Tag: Alternative-Dispute-Resolution Ledger-Authoritative-Dispute-Resolution | -| Additional License Parameters | None | +| Параметр | Опции/Метки | +| ------------------------------------------------- | ----------------------------------------------------------------------------- | +| Территория | Без ограничений | +| Каналы распостранения | Без ограничений | +| Атрибуция | Обязательно | +| Стандарты контента | Без ограничений | +| Возможность сублицензирования | Нет | +| Обучение ИИ | Разрешено | +| Ограничения по использованию на разных платформах | Нет | +| Применимое право | Калифорния | +| Альтернативное разрешение споров | Метка: Alternative-Dispute-Resolution Ledger-Authoritative-Dispute-Resolution | +| Дополнительные параметры лицензии | Отсутствуют | -## Flavor #3: Commercial Remix +## Вариант №3: Коммерческий ремикс -Let the world build on and play with your creation... and earn money together from it! This license allows for endless free remixing while tracking all uses of your work while giving you full credit, with each derivative paying a percentage of revenue to its "parent" IP. +Позвольте миру использовать и развивать вашу работу... и зарабатывать на этом деньги вместе с вами! Эта лицензия разрешает бесконечный бесплатный ремиксинг с отслеживанием всех случаев использования вашей работы и предоставлением вам полного признания, при этом каждая производная работа платит процент от выручки своей "родительской" IP. -### What others can do? +### Что могут делать другие? + @@ -274,12 +280,13 @@ Let the world build on and play with your creation... and earn money together fr +
- Others can + Могут - Others cannot + Не могут
- ✅ Remix this work + ✅ Создавать ремиксы на эту работу (`derivativesAllowed == true`) - ❌ Claim credit for the remix as original work + ❌ Присваивать себе авторство ремикса как оригинальной работы (`derivativesAttribution == true`)
- ✅ Distribute their remix anywhere + ✅ Распространять свои ремиксы где угодно - ❌ Claim credit for the original work + ❌ Присваивать себе авторство оригинальной работы (`commercialAttribution == true`)
- ✅ Credit you appropriately + ✅ Указывать автора оригинала (`derivativesAttribution == true`) - ❌ Claim all the revenue from commercial use of the original work or derivative works + ❌ Претендовать на весь доход от коммерческого использования оригинальной или производной работы (`commercialRevShare` is set)
- ✅ Commercialize the original and derivative works + ✅ Коммерчески использовать оригинальные и производные работы (`commercialUse == true`)
-###  PIL Term Values +###  Значения условий PIL -* **On-chain**: +- **На блокчейне**: ```sol Solidity PILTerms({ @@ -303,43 +310,44 @@ PILTerms({ }); ``` -* **Off-chain** +- **Вне блокчейна** + -| Parameter | Options / Tags | -| --------------------------------- | --------------------------------------------------------------------------- | -| Territory | No restrictions | -| Channels of Distribution | No Restriction | -| Attribution | True | -| Content Standards | No Restriction | -| Sublicensable | False | -| AI Learning Models | True | -| Restriction on Cross-Platform Use | False | -| Governing Law | California | -| Alternative Dispute Resolution | Tag: Alternative-Dispute-Resolution Ledger-Authoritative-Dispute-Resolution | -| Additional License Parameters | None | +| Параметр | Опции/Метки | +| ------------------------------------------------- | ----------------------------------------------------------------------------- | +| Территория | Без ограничений | +| Каналы распостранения | Без ограничений | +| Атрибуция | Обязательно | +| Стандарты контента | Без ограничений | +| Возможность сублицензирования | Нет | +| Обучение ИИ | Разрешено | +| Ограничения по использованию на разных платформах | Нет | +| Применимое право | Калифорния | +| Альтернативное разрешение споров | Метка: Alternative-Dispute-Resolution Ledger-Authoritative-Dispute-Resolution | +| Дополнительные параметры лицензии | Отсутствуют | -# Examples +# Примеры -Here are some common examples of royalty flow. *More coming soon!* +Ниже приведены примеры потока роялти. Скоро появятся новые примеры! -## Example 1 +## Пример 1 -### Explanation +### Объяснение -Someone registers their Azuki on Story. By default, that IP Asset has Non-Commercial Social Remixing Terms, which specify that anyone can create derivatives of that work but cannot commercialize them. So, someone else creates & registers a remix of that work (IPA2) which inherits those same terms. Someone else then does the same to IPA2, creating & registering IPA3. +Кто-то регистрирует своего персонажа Azuki на платформе Story. По умолчанию этот IP-актив (IPA1) имеет условия "Некоммерческий социальный ремикс", которые разрешают любому создавать производные работы, но запрещают их коммерческое использование. Затем кто-то создает и регистрирует ремикс на этот актив (IPA2), унаследовав те же условия. Еще один человек создает ремикс на IPA2, регистрируя IPA3. -The owner of IPA1 then decides that others can commercialize the work, but they cannot create derivatives to do so, they must pay a 10 USDC minting fee, and they must share 10% of all revenue earned. So, someone wants to commercialize IPA1 by putting it on a t-shirt. They pay the 10 USDC minting fee to get a License Token, which represents the license to commercialize IPA1. They then put the image on a t-shirt and sell it. 10% of revenue earned by that t-shirt must be sent on-chain to IPA1. +Владелец IPA1 затем решает разрешить коммерческое использование своей работы, но без создания производных работ. Для этого требуется уплата комиссии за выпуск лицензии в размере 10 USDC, а также передача 10% от всего полученного дохода. Например, кто-то хочет использовать IPA1 на футболке. Он платит 10 USDC за выпуск токена лицензии, представляющего право на коммерческое использование IPA1. Затем он размещает изображение на футболке и продает ее. 10% дохода от продаж должны быть отправлены владельцу IPA1 через блокчейн. -## Example 2 +## Пример 2 -### Explanation +### Объяснение -Someone registers their Azuki on Story. By default, that IP Asset has Non-Commercial Social Remixing Terms, which specify that anyone can create derivatives of that work but cannot commercialize them. So, someone else creates & registers a remix of that work (IPA2) which inherits those same terms. Someone else then does the same to IPA2, creating & registering IPA3. +Кто-то регистрирует своего персонажа Azuki на платформе Story. По умолчанию этот IP-актив (IPA1) имеет условия "Некоммерческий социальный ремикс", которые разрешают любому создавать производные работы, но запрещают их коммерческое использование. Затем кто-то создает и регистрирует ремикс на этот актив (IPA2), унаследовав те же условия. Еще один человек создает ремикс на IPA2, регистрируя IPA3. -The owner of IPA1 then decides that others can create derivatives of their work and commercialize them, but they must pay a 10 USDC minting fee and share 10% of all revenue earned. So, someone wants to commercialize IPA1 by putting it on a t-shirt. They pay the 10 USDC minting fee to get a License Token and burn it to create their own derivative, which changes the background color to red. They then put the remixed image on a t-shirt and sell it. 10% of revenue earned by that t-shirt must be sent on-chain to IPA1. +Владелец IPA1 затем решает, что другие могут создавать производные работы и коммерчески их использовать. Однако они должны уплатить комиссию за выпуск лицензии в размере 10 USDC и отчислять 10% от полученного дохода. Например, кто-то хочет использовать IPA1 на футболке. Он платит 10 USDC за выпуск лицензии и "сжигает" этот токен, чтобы создать собственный ремикс, изменив, например, цвет фона на красный. Затем он размещает ремиксированное изображение на футболке и продает ее. 10% дохода от продаж футболки должны быть отправлены владельцу IPA1 через блокчейн. -A third person wants to commercialize the remix by putting it in a TV advertisement, but they want to change the hair color to white. So, they pay a 10 USDC minting fee (of which, 1 USDC gets sent back to IPA1) to create their own derivative. They then put the remixed image in a TV ad. 10% of revenue earned by that t-shirt must be sent on-chain to IPA4, of which 10% will be distributed back to IPA1. \ No newline at end of file +Третий человек хочет коммерчески использовать ремикс, разместив его в телевизионной рекламе, но при этом хочет изменить цвет волос персонажа на белый. Для этого он платит 10 USDC за выпуск лицензии (1 USDC из которых отправляется владельцу IPA1), чтобы создать свой ремикс. Затем он размещает ремиксированное изображение в телевизионной рекламе. 10% дохода от рекламы должны быть отправлены владельцу IPA2 через блокчейн, из которых 10% перераспределяются обратно владельцу IPA1. diff --git a/docs/Concepts/programmable-ip-license/pil-terms.md b/docs/Concepts/programmable-ip-license/pil-terms.md index f387534..ba8859a 100644 --- a/docs/Concepts/programmable-ip-license/pil-terms.md +++ b/docs/Concepts/programmable-ip-license/pil-terms.md @@ -1,32 +1,36 @@ --- -title: PIL Terms -excerpt: '' +title: Условия PIL +excerpt: "" deprecated: false hidden: false metadata: - title: '' - description: '' + title: "" + description: "" robots: index next: - description: '' + description: "" --- -> 👍 Easy Mode: We Have Preset PIL Terms + +> 👍 Упрощенный режим: У нас есть готовые условия PIL > -> [Check the PIL Flavors here](https://docs.story.foundation/docs/pil-flavors-preset-policy). +> [Готовые варианты условий PIL](https://docs.story.foundation/docs/pil-flavors-preset-policy). PIL is the first License Agreement for medial license developed by Story Protocol and inspired by [Token Bound License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf). If you haven't already, read the overview: [Programmable IP License (PIL💊)](doc:programmable-ip-license) -> 📘 PIL Legal Text +PIL (Программируемая Лицензия IP) — это первая лицензия для медийных лицензий, разработанная Story Protocol и вдохновленная [Token Bound License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf). Если вы еще не знакомы, прочитайте обзор:[Программируемая Лицензия IP (PIL💊)](doc:programmable-ip-license). + +> 📘 Текст PIL > -> Check out the actual PIL legal text [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Testnet.pdf). It is very human readable for a legal text! +> Ознакомьтесь с полным текстом PIL [здесь](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Testnet.pdf). Он написан простым и понятным языком как для юридического документа! -# On-chain terms +# Условия на блокчейне Most PIL terms are on-chain. They are implemented in the `IPILicenseTemplate` contract as a `PILTerms` struct [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/licensing/IPILicenseTemplate.sol). +Большинство условий PIL реализованы на блокчейне. Они включены в контракт `IPILicenseTemplate` как структура `PILTerms`. Ознакомьтесь с исходным кодом [здесь](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/licensing/IPILicenseTemplate.sol). ```sol IPILicenseTemplate.sol -/// @notice This struct defines the terms for a Programmable IP License (PIL). -/// These terms can be attached to IP Assets. +/// @notice Эта структура определяет условия для PIL. +/// Эти условия могут быть применены к IP-активам. struct PILTerms { bool transferable; address royaltyPolicy; @@ -48,23 +52,24 @@ struct PILTerms { } ``` -## Descriptions +## Описание параметров + @@ -78,7 +83,7 @@ struct PILTerms { @@ -88,11 +93,11 @@ struct PILTerms { @@ -106,7 +111,7 @@ struct PILTerms { @@ -120,7 +125,7 @@ struct PILTerms { @@ -134,7 +139,7 @@ struct PILTerms { @@ -148,7 +153,7 @@ struct PILTerms { @@ -158,11 +163,11 @@ struct PILTerms { @@ -176,7 +181,7 @@ struct PILTerms { @@ -190,9 +195,9 @@ struct PILTerms { @@ -206,7 +211,7 @@ struct PILTerms { @@ -220,7 +225,7 @@ struct PILTerms { @@ -234,7 +239,7 @@ struct PILTerms { @@ -248,7 +253,7 @@ struct PILTerms { @@ -262,7 +267,7 @@ struct PILTerms { @@ -276,7 +281,7 @@ struct PILTerms { @@ -290,7 +295,7 @@ struct PILTerms { @@ -304,148 +309,132 @@ struct PILTerms { +
- Parameter + Параметр - Values + Значения - Description + Описание
- If false, the License Token cannot be transferred once it is minted to a recipient address. + Если False, токен лицензии нельзя будет передать другому адресу.
- Address + Адрес - The address of the royalty policy contract. The royalty policy must have been approved by Story Protocol in advance. + Адрес контракта политики роялти, который должен быть предварительно одобрен Story Protocol.
- The fee to be paid when minting a license. + Комиссия за создание лицензии.
- The expiration period of the license. + Срок действия лицензии (в блоках или секундах).
- You can make money from using the original IP Asset, subject to limitations below. + Можно ли зарабатывать деньги, используя оригинал.
- If true, people must give credit to the original work in their commercial application (eg. merch) + Требуется ли указание авторства при коммерческом использовании.
- Address + Адрес - Commercializers that are allowed to commercially exploit the original work. If zero address, then no restrictions are enforced. + Контракт, определяющий, кто может коммерчески использовать актив. Если адрес пустой, ограничений нет
- The data to be passed to the commercializer checker contract. + Данные для проверки коммерциализации.
- Amount of revenue (from any source, original & derivative) that must be shared with the licensor (a value of 10,000,000 == 10% of revenue share). + Процент дохода, который должен быть передан лицензиару (например, 10,000,000 = 10%). - This will collect all revenue from tokens that are whitelisted in the [RoyaltyModule.sol contract](https://github.com/storyprotocol/protocol-core-v1/blob/e339f0671c9172a6699537285e32aa45d4c1b57b/contracts/modules/royalty/RoyaltyModule.sol#L50). + Весь доход от токенов которые внесены в белый список контракта [RoyaltyModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/e339f0671c9172a6699537285e32aa45d4c1b57b/contracts/modules/royalty/RoyaltyModule.sol#L50).
- If `commercialUse` is set to true, this value determines the maximum revenue you can earn from the original work. + Максимальный доход, который можно заработать на оригинале.
- Indicates whether the licensee can create derivatives of his work or not. + Разрешено ли создавать производные работы.
- If true, derivatives that are made must give credit to the original work. + Требуется ли указывать авторство для производных работ.
- If true, the licensor must approve derivatives of the work. + Требуется ли одобрение от владельца для создания производных работ.
- If true, derivatives of this derivative can be created indefinitely as long as they have the exact same terms. + Производные работы могут быть использованы для создания новых производных только при соблюдении тех же условий.
- If `commercialUse` is set to true, this value determines the maximum revenue you can earn from derivative works. + Максимальный доход от производных работ.
- The ERC20 token to be used to pay the minting fee. The token must be registered in story protocol. + Токен ERC20, используемый для оплаты лицензии. Токен должен быть зарегестрирован в Story.
- The URI of the license terms, which can be used to fetch [off-chain license terms](https://docs.story.foundation/v1/docs/pil-for-devs-and-creators#off-chain-parameters-to-be-included-in-uri-field). + URI с дополнительными условиями [офф-чейн лицензии](https://docs.story.foundation/v1/docs/pil-for-devs-and-creators#off-chain-parameters-to-be-included-in-uri-field).
-# Off-chain terms to be included in `uri` field +# Условия вне блокчейна (включаются в uri) -Some PIL terms must be stored off-chain and passed in the `uri` field above. This is because these terms are often more lengthy and/or descriptive, so it would not make sense to store them on-chain. +Некоторые параметры PIL хранятся вне блокчейна, поскольку они могут быть более длинными или описательными. + + Указывает географические ограничения (по умолчанию глобально). - + + +
- Parameter + Параметр - Description + Описание
- Territory + Территория - Limit usage of the IP to certain regions and/or countries. - - By default, the IP can be used globally. -
- Channels of Distribution + Каналы дистрибуции - Restrict usage of the IP to certain media formats and use in certain channels of distribution. - By default, the IP can be used across all possible channels of distribution. +Ограничивает использование IP в определенных форматах и каналах (по умолчанию доступно для всех каналов). Примеры: "телевидение", "физические товары", "видеоигры" и т.д. - Examples: "television", "physical consumer products", "video games", etc. -
- Attribution + Атрибуция - If the original author should be credited for usage of the IP. - - By default, you do not need to provide credit to the original author. + Указывает, нужно ли упоминать автора (по умолчанию не требуется).
- Content Standards + Стандарты контента - Set content standards around use of the IP. - - By default, no standards apply. - - Examples: "No-Hate", "Suitable-for-All-Ages", "No-Drugs-or-Weapons", "No-Pornography". + Указывает стандарты для использования контента (по умолчанию ограничений нет). Примеры: "Без ненависти", "Подходит для всех возрастов", "Без наркотиков".
- Sublicensable + Сублицензирование - Derivative works can grant the same rights they received under this license to a 3rd party, without approval from the original licensor. - - By default, derivatives may not do so. + Производные работы могут передавать те же права третьим лицам без подтверждения автора оригинала (по умолчанию запрещено).
- AI Learning Models + Искусственный интеллект - Whether or not the IP can be used to develop AI learning models. - - By default, the IP can be used for such development. + Разрешено ли использовать IP для разработки, обучения моделей ИИ (по умолчанию разрешено).
- Restriction On Cross-Platform Use + Кроссплатформенность - Limit licensing and creation of derivative works solely on the app on which the IP is made available. - - By default, the IP can be used anywhere. + Можно ли использовать IP за пределами платформы, где она была опубликована (по умолчанию разрешено).
- Governing Law + Применимое законодательство - The laws of a certain jurisdiction by which this license abides. - - By default, this is California, USA. + Указывает законы, регулирующие лицензию (по умолчанию Калифорния, США).
- Alternative Dispute Resolution + Альтернативное разрешение споров - Please see section 3.1 (s) [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Beta_Final_2024_02_Plain_English.pdf). + Секция 3.1 [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/PIL_Beta_Final_2024_02_Plain_English.pdf).
- Additional License Parameters + Дополнительные параметры - There may be other terms the licensor would like to add and they can do so in this tag. + Лицензиар может добавлять дополнительные условия в этот раздел.
From 1264d621b452da9cf2cb67a9048ddb0f16b27070 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Wed, 1 Jan 2025 23:37:15 +0300 Subject: [PATCH 05/10] registry + half of royalty module --- .../registry/group-ip-asset-registry.md | 18 ++-- docs/Concepts/registry/index.md | 26 +++--- docs/Concepts/registry/ip-asset-registry.md | 12 +-- docs/Concepts/registry/license-registry.md | 32 +++---- docs/Concepts/registry/module-registry.md | 10 +-- .../external-royalty-policies.md | 70 ++++++++-------- docs/Concepts/royalty-module/index.md | 84 +++++++++---------- 7 files changed, 128 insertions(+), 124 deletions(-) diff --git a/docs/Concepts/registry/group-ip-asset-registry.md b/docs/Concepts/registry/group-ip-asset-registry.md index 0b5536d..e844ee1 100644 --- a/docs/Concepts/registry/group-ip-asset-registry.md +++ b/docs/Concepts/registry/group-ip-asset-registry.md @@ -1,5 +1,5 @@ --- -title: Group IP Asset Registry +title: Реестр групповых IP-активов excerpt: '' deprecated: false hidden: false @@ -10,34 +10,34 @@ metadata: next: description: '' --- -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/GroupIPAssetRegistry.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/GroupIPAssetRegistry.sol). -The Group IP Asset Registry is responsible for managing the registration and tracking of Group IP Assets, including the group members and reward pools. +Реестр групповых IP-активов отвечает за управление регистрацией и отслеживанием групповых IP-активов, включая их участников и пулы вознаграждений. -The Group IP Asset Registry will maintain grouping relationship on-chain between the Group's IP Account and individual IP Accounts through a mapping: +Реестр групповых IP-активов хранит данные о связях между групповым IP-аккаунтом и индивидуальными IP-аккаунтами на блокчейне с использованием следующего отображения: ```sol GroupIPAssetRegistry.sol mapping(address groupIpId => EnumerableSet.AddressSet memberIpIds) groups; ``` -### Notable Functions +### Основные функции ```sol GroupIPAssetRegistry.sol function registerGroup(address groupNft, uint256 groupNftId, address rewardPool) external onlyGroupingModule whenNotPaused returns (address groupId) ``` -This function registers a new Group IPA on Story. +Эта функция регистрирует новый групповой IP-актив в Story. ```sol GroupIPAssetRegistry.sol function addGroupMember(address groupId, address[] calldata ipIds) external onlyGroupingModule whenNotPaused ``` -Adds already registered IPAs to an existing Group IPA. +Добавляет уже зарегистрированные IP-активы в существующий групповой IP-актив. ```sol GroupIPAssetRegistry.sol function removeGroupMember(address groupId, address[] calldata ipIds) external onlyGroupingModule whenNotPaused ``` -Removes registered IPAs from a Group IPA. +Удаляет зарегистрированные IP-активы из группового IP-актива. diff --git a/docs/Concepts/registry/index.md b/docs/Concepts/registry/index.md index 18e38ec..f8bf4af 100644 --- a/docs/Concepts/registry/index.md +++ b/docs/Concepts/registry/index.md @@ -1,5 +1,5 @@ --- -title: 🗂️ Registry +title: 🗂️ Реестр excerpt: '' deprecated: false hidden: false @@ -10,26 +10,26 @@ metadata: next: description: '' --- -The various registries on Story function as a primary directory/storage for the global states of the protocol. Obviously, they also contain functions to update that storage. +Различные реестры в Story функционируют как основная директория/хранилище для глобальных состояний протокола. Кроме того, они содержат функции для обновления этого хранилища. -Unlike [IP Accounts](doc:ip-account), which manage the state of specific IPs, a **registry** oversees the broader states of the protocol. +В отличие от [IP-аккаунтов](doc:ip-account), которые управляют состоянием конкретных IP, **реестр** отвечает за более широкие состояния протокола. -# Types of Registries +# Типы реестров -Below are all of the registries on Story. +Ниже перечислены все реестры в Story. -## [IP Asset Registry](doc:ip-asset-registry) +## [Реестр IP-активов](doc:ip-asset-registry) -Responsible for registering IPs into the protocol. +Отвечает за регистрацию IP в протоколе. -## [Group IP Asset Registry](doc:group-ip-asset-registry) +## [Реестр групповых IP-активов](doc:group-ip-asset-registry) -Responsible for registering and maintaining Group IP Assets. +Отвечает за регистрацию и поддержку групповых IP-активов. -## [License Registry](doc:license-registry) +## [Реестр лицензий](doc:license-registry) -Stores all license-related states within the protocol, like attaching License Terms to IP Assets, registering derivatives, creating new License Templates, etc. +Хранит все данные, связанные с лицензиями в протоколе, включая прикрепление условий лицензии к IP-активам, регистрацию производных работ, создание новых Шаблонов Лицензий и так далее. -## [Module Registry](doc:module-registry) +## [Реестр модулей](doc:module-registry) -Maintains and updates the global list of modules and hooks registered permissionlessly on Story +Поддерживает и обновляет глобальный список модулей и хуков, зарегистрированных без разрешений в Story. diff --git a/docs/Concepts/registry/ip-asset-registry.md b/docs/Concepts/registry/ip-asset-registry.md index 867f10b..7a55cb6 100644 --- a/docs/Concepts/registry/ip-asset-registry.md +++ b/docs/Concepts/registry/ip-asset-registry.md @@ -1,5 +1,5 @@ --- -title: IP Asset Registry +title: Реестр IP-активов excerpt: '' deprecated: false hidden: false @@ -10,16 +10,16 @@ metadata: next: description: '' --- -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/IPAssetRegistry.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/IPAssetRegistry.sol). -The IP Asset Registry is responsible for registering IPs into the protocol. It deploys a dedicated [IP Account](doc:ip-account) contract for each new IP Asset registered on the protocol (*NOTE: This registry inherits from IP Account Registry*) +Реестр IP-активов отвечает за регистрацию IP в протоколе. Он разворачивает выделенный контракт [IP-аккаунта](doc:ip-account) для каждого нового IP-актива, зарегистрированного в протоколе (*ПРИМЕЧАНИЕ: Этот реестр наследуется от Реестра IP-аккаунтов*). -### Notable Functions +### Основные функции ```sol IPAssetRegistry.sol function register(uint256 chainid, address tokenContract, uint256 tokenId) external whenNotPaused returns (address id) ``` -This function registers an ERC-721 NFT as a new IP Asset on Story. +Эта функция регистрирует ERC-721 NFT как новый IP-актив в Story. diff --git a/docs/Concepts/registry/license-registry.md b/docs/Concepts/registry/license-registry.md index 4e0cfa1..2f944f9 100644 --- a/docs/Concepts/registry/license-registry.md +++ b/docs/Concepts/registry/license-registry.md @@ -1,5 +1,5 @@ --- -title: License Registry +title: Реестр Лицензий excerpt: '' deprecated: false hidden: false @@ -10,45 +10,47 @@ metadata: next: description: '' --- -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/LicenseRegistry.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/LicenseRegistry.sol). The License Registry stores all license-related states within the protocol, including managing global state like registering new License Templates like the [Programmable IP License (PIL💊)](doc:programmable-ip-license), attaching licenses to individual [IP Assets](doc:ipasset), registering derivatives, and the like: +Реестр Лицензий хранит все состояния, связанные с лицензиями в протоколе, включая управление глобальными состояниями, такими как регистрация новых шаблонов лицензий, например, [Программируемая Лицензия IP (PIL💊)](doc:programmable-ip-license), прикрепление лицензий к отдельным [IP-активам](doc:ipasset), регистрацию производных активов и тому подобное: + ```sol LicenseRegistry.sol struct LicenseRegistryStorage { - /// The default license template address + /// Адрес шаблона лицензии по умолчанию address defaultLicenseTemplate; - /// The default license terms ID + /// ID условий лицензии по умолчанию uint256 defaultLicenseTermsId; - /// Registered license templates + /// Зарегистрированные шаблоны лицензий mapping(address licenseTemplate => bool isRegistered) registeredLicenseTemplates; - /// Mapping of parent IPs to derivative IPs + /// Сопоставление родительских IP с производными IP mapping(address childIpId => EnumerableSet.AddressSet parentIpIds) parentIps; - /// Mapping of derivative IPs to parent IPs + /// Сопоставление производных IP с родительскими IP mapping(address parentIpId => EnumerableSet.AddressSet childIpIds) childIps; - /// attachedLicenseTerms Mapping of attached license terms to IP IDs + /// Сопоставление прикрепленных условий лицензий с ID IP mapping(address ipId => EnumerableSet.UintSet licenseTermsIds) attachedLicenseTerms; - /// Mapping of license templates to IP IDs + /// Сопоставление шаблонов лицензий с ID IP mapping(address ipId => address licenseTemplate) licenseTemplates; - /// Mapping of minting license configs to a licenseTerms of an IP + /// Сопоставление конфигураций лицензий с условиями лицензии IP mapping(bytes32 ipLicenseHash => Licensing.LicensingConfig licensingConfig) licensingConfigs; - /// Mapping of minting license configs to an IP, the config will apply to all licenses under the IP + /// Сопоставление конфигураций лицензий с IP, конфигурация будет применяться ко всем лицензиям данного IP mapping(address ipId => Licensing.LicensingConfig licensingConfig) licensingConfigsForIp; } ``` -### Notable Functions +### Основные функции ```sol LicenseRegistry.sol function attachLicenseTermsToIp(address ipId, address licenseTemplate, uint256 licenseTermsId) external onlyLicensingModule ``` -This function allows you to attach License Terms to an IP Asset. +Эта функция позволяет прикрепить Условия Лицензии к IP-активу. ```sol LicenseRegistry.sol function registerDerivativeIp(address childIpId, address[] calldata parentIpIds, address licenseTemplate, uint256[] calldata licenseTermsIds, bool isUsingLicenseToken) external onlyLicensingModule ``` -This function allows you to register an IP Asset as a derivative of another IP Asset, unlocking things like claimable royalty flows from the [Royalty Module](doc:royalty-module). +Эта функция позволяет зарегистрировать IP-актив как производный от другого IP-актива, что открывает возможности, вроде получения роялти через [Модуль Роялти](doc:royalty-module). diff --git a/docs/Concepts/registry/module-registry.md b/docs/Concepts/registry/module-registry.md index 6e059ce..3383124 100644 --- a/docs/Concepts/registry/module-registry.md +++ b/docs/Concepts/registry/module-registry.md @@ -1,5 +1,5 @@ --- -title: Module Registry +title: Реестр Модулей excerpt: '' deprecated: false hidden: false @@ -10,10 +10,10 @@ metadata: next: description: '' --- -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/ModuleRegistry.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/ModuleRegistry.sol). -The Module Registry maintains and updates the global list of modules and hooks registered permissionlessly on Story. It can enable/disable modules on a per-IP Account basis for granular control over each IP Account's interaction with modules and hooks. +Реестр модулей поддерживает и обновляет глобальный список модулей и хуков, зарегистрированных без разрешений в Story. Он позволяет включать/отключать модули для каждого IP-аккаунта индивидуально, обеспечивая детальный контроль над взаимодействием каждой учетной записи с модулями и хуками. -**This module is likely not very important for you** unless you wish to dive into creating/reading modules. +**Скорее всего, этот модуль не будет для вас особо важным**, если только вы не хотите углубиться в создание или изучение модулей. diff --git a/docs/Concepts/royalty-module/external-royalty-policies.md b/docs/Concepts/royalty-module/external-royalty-policies.md index 5fa0c00..4158603 100644 --- a/docs/Concepts/royalty-module/external-royalty-policies.md +++ b/docs/Concepts/royalty-module/external-royalty-policies.md @@ -1,5 +1,5 @@ --- -title: External Royalty Policies +title: Внешняя Политика Роялти excerpt: '' deprecated: false hidden: false @@ -10,68 +10,70 @@ metadata: next: description: '' --- -There can be many flavors and variations of royalty distribution rules as we observe in the real world. The same can be expected onchain. Whenever a use case requires unique and specific royalty rules, then those set of rules can be registered as an **External Royalty Policy**. +В реальном мире существует множество вариантов и разновидностей правил распределения роялти. То же самое можно ожидать и в блокчейне. В случаях, когда требуется уникальный и специфический набор правил роялти, они могут быть зарегистрированы как **Внешняя Политика Роялти**. -## 1. What is an External Royalty Policy? +## 1. Что такое Внешняя Политика Роялти? -It is a smart contract that inherits a specific interface called `IExternalRoyaltyPolicy`, which defines the view function below: +Это смарт-контракт, который наследует определенный интерфейс под названием `IExternalRoyaltyPolicy`, включающий следующий view-функционал: ```sol IExternalRoyaltyPolicy - /// @notice Returns the amount of royalty tokens required to link a child to a given IP asset - /// @param ipId The ipId of the IP asset - /// @param licensePercent The percentage of the license - /// @return The amount of royalty tokens required to link a child to a given IP asset + /// @notice Возвращает количество токенов роялти, необходимых для связи дочернего IP с данным IP-активом + /// @param ipId ID IP-актива + /// @param licensePercent Процент лицензии + /// @return Количество токенов роялти, необходимых для связи дочернего IP с данным IP-активом function getPolicyRtsRequiredToLink(address ipId, uint32 licensePercent) external view returns (uint32); ``` -After developing your smart contract make sure it inherits the interface above and you can register your new External Royalty Policy by calling `registerExternalRoyaltyPolicy` function in RoyaltyModule.sol. +После разработки смарт-контракта убедитесь, что он наследует указанный интерфейс. Затем вы можете зарегистрировать вашу новую Внешнюю Политику Роялти, вызвав функцию `registerExternalRoyaltyPolicy` в файле RoyaltyModule.sol. -## 2. How does it work? +## 2. Как это работает? -Let's follow an example of a new External Royalty Policy called "Policy X". +Рассмотрим пример новой внешней политики роялти под названием "Политика X". -### External Royalty Policies are selected by users +### Пользователи выбирают Внешние Политики Роялти -An IPA owner decides the royalty policy he/she wants to allow the IP to be remixed with. There are multiple options of royalty rules that can be chosen such as LAP, LRP and other External Royalty Policies. Let's say the user decides to mint a license token with "Policy X". After that, IP2 remixes IP1 and IP3 remixes IP2 and we have the situation as the image below: +Владелец IP-аккаунта выбирает политику роялти, которую он хочет разрешить для ремиксации IP. Можно выбрать различные правила роялти, такие как LAP, LRP и другие Внешние Политики Роялти. Допустим, пользователь решает выпустить лицензионный токен с "Политикой X". После этого IP2 делает ремикс IP1, а IP3 делает ремикс IP2, и мы получаем следующую ситуацию: ![](https://files.readme.io/412377155f8b31081aa77a2bf8dfe86ac40795ebc9b2f963471f8e4d6cacf559-image.png) -Every time there is a remix - the link between the parent and derivative has 2 data points associated: +Каждый раз при создании ремикса связь между родительским и производным активом включает два элемента данных: -1. The royalty policy address - 1. "Policy X" address in the example -2. The percentage of royalty tokens the parent demands from derivatives. This percentage can have different meanings depending on the royalty policy being used - ie. it can be a relative percentage, an absolute percentage, an adjusted percentage according to specific rules, etc. - 1. 10% between IP1 and IP2 - 2. 50% between IP2 and IP3 +1. Адрес политики роялти + 1. В данном примере это адрес "Политики X". +2. Процент токенов роялти, который родитель требует от производных активов. Этот процент может варьироваться в зависимости от используемой политики роялти: это может быть относительный процент, абсолютный процент или процент, скорректированный по специфическим правилам. + 1. 10% между IP1 и IP2 + 2. 50% между IP2 и IP3 -### External Royalty Policies receive royalty tokens from their users' IPs +### Внешние Политики Роялти получают токены роялти от пользователей их IP -Following the example, when each remix is made and during the `onLinkToParents` function call in RoyaltyModule.sol the function +В продолжение примера, каждый раз, когда создается ремикс, во время вызова функции `onLinkToParents` в RoyaltyModule.sol вызывается следующая функция на адресе "Политики X": `getPolicyRtsRequiredToLink(address ipId, uint32 licensePercent) external view returns (uint32)` -is called on the "Policy X" address. It should return the % of derivative's royalty tokens that the royalty policy demands for the link to happen. That share of royalty tokens are sent to the "Policy X" contract. In the example case: +Она возвращает процент токенов роялти производного актива, который требует политика роялти для осуществления связи. Эта часть токенов роялти отправляется в контракт "Политики X". В данном примере: -* "Policy X" receives 3% of RT2 token supply that it can then redistributed to its userbase. IP1 owner wanted 10%, however - let's assume for the sake of the example - that due to the specific use case of "Policy X" and its custom logic, the IP2 owner is granted a special status in the platform in which it it has a 70% discount on the % share it has to give parent IPs due to having a very large distribution network to promote IPs. Therefore, instead of having to give 10% as the license percentage indicated it only gives 3%. -* "Policy X" receives 50% of RT3 token supply that it can then redistributed to its userbase. +* "Политика X" получает 3% от токенов RT2, которые затем могут быть перераспределены ее пользователям. Владелец IP1 хотел 10%, однако — предположим для примера — что из-за специфики "Политики X" и ее логики IP2 получает особый статус на платформе, что позволяет ему снизить свою долю до 3% (70% скидка). +* "Политика X" получает 50% от токенов RT3, которые затем перераспределяются среди ее пользователей. ![](https://files.readme.io/33efb951a9be1339e849eb025d183a0f8d4f949f634ee5dfe1f13dac52c79bb0-image.png) -### External Royalty Policies redistribute value back to their users according to custom rules +### Внешние Политики Роялти перераспределяют ценность среди своих пользователей по собственным правилам -There are two ways in which an External Royalty Policy can redistribute value back to its users: +Существует два способа перераспределения ценности через Внешнюю Политику Роялти: -1. Send Royalty Tokens directly to its users -2. Keep the Royalty Tokens in the External Royalty Policy contract and have users claim Revenue Tokens through the the said contract +1. Напрямую отправлять токены роялти пользователям. +2. Хранить токены роялти в контракте Внешней Политики Роялти, позволяя пользователям требовать токены дохода через этот контракт. + +Рассмотрим оба случая в контексте "Политики X". Предположим, из 50% токенов RT3, полученных "Политикой X", 40% остаются в контракте, а 10% отправляются в хранилище роялти предка (IP1). + +![](https://files.readme.io/4a8c08eac060fdaad89116ee26a60939938298a563d526d8835e5064e3f02e28-image.png)Теперь представим, что IP3 получает выплату в размере 1M USDC. Пример потока средств: -Let's explore both in the context of "Policy X". Let's say that from the 50% of RT3 token supply "Policy X" received - 40% are kept in the "Policy X" contract and 10% are sent to an ancestor royalty vault (IP1). -![](https://files.readme.io/4a8c08eac060fdaad89116ee26a60939938298a563d526d8835e5064e3f02e28-image.png)Now let's imagine there is a 1M payment made to IP3 - an example of how the flow would be: ![](https://files.readme.io/f39ebfc34c5b276df0ac1c32f3e014969d2c152daa41f099be4a75a5dd219734-image.png) -From the 1M USDC inflow to IP3 Royalty Vault: +Из 1M USDC, поступивших в хранилище роялти IP3: -* 500k USDC are claimed by the IP Account 3 which had 50% of RT3 token supply -* 100k USDC are claimed by the IP1 Royalty Vault which has 10% of RT3 token supply via `claimByTokenBatchAsSelf` function -* 400k USDC are claimed by "Policy X" which has 40 of RT3 token supply. This amount is further split by "Policy X" custom contract according to its specific rules - which define y% and z% - to its users. \ No newline at end of file +* 500k USDC получают владельцы IP3, у которых было 50% от токенов RT3. +* 100k USDC получает хранилище роялти IP1 (10% от RT3) через функцию `claimByTokenBatchAsSelf`. +* 400k USDC получает "Политика X", у которой было 40% RT3. Эти средства распределяются среди пользователей "Политики X" в соответствии с ее специфическими правилами, определяющими доли y% и z%. \ No newline at end of file diff --git a/docs/Concepts/royalty-module/index.md b/docs/Concepts/royalty-module/index.md index 207d8e3..3b897b1 100644 --- a/docs/Concepts/royalty-module/index.md +++ b/docs/Concepts/royalty-module/index.md @@ -1,6 +1,6 @@ --- -title: 💸 Royalty Module -excerpt: Learn how revenue flows between parent and child IP on Story. +title: 💸 Модуль Роялти +excerpt: Узнайте, как распределяется доход между родительскими и дочерними IP-активами на платформе deprecated: false hidden: false metadata: @@ -10,80 +10,80 @@ metadata: next: description: '' --- -The Royalty Module defines how revenue flows between parent and child IP Assets. There are two common scenarios when revenue flow would happen: +Модуль Роялти определяет, как распределяется доход между родительскими и дочерними IP-активами. Существуют два основных сценария, при которых происходит распределение дохода: -1. Minting a License - sometimes there is a minting fee to mint a [License Token](doc:license-token) from an IP Asset. When this is paid by someone (who wants to register a derivative or simply hold a license), the revenue should flow up the chain. -2. Tipping Directly - if someone sends revenue to an IP Asset directly, it should flow up the chain. +1. Создание лицензии — иногда за выпуск [Лицензионного Токена](doc:license-token) для IP-актива взимается плата. Когда она оплачивается (кем-то, кто хочет зарегистрировать производный актив или просто владеть лицензией), доход распределяется вверх по цепочке. +2. Прямое вознаграждение — если кто-то отправляет доход непосредственно на IP-актив, он также распределяется вверх по цепочке. -The below example (using [Liquid Absolute Percentage](doc:policy-liquid-absolute-percentage)) shows what happens when an IP Asset 4 (IPA4) tips IPA3 1M USDC. +В следующем примере (с использованием [Ликвидного абсолютного процента (LAP)](doc:policy-liquid-absolute-percentage)) показано, что происходит, когда IP-актив 4 (IPA4) отправляет 1 миллион USDC в пользу IPA3. -1. Revenue first flows to the Royalty Module contract -2. Royalty Module sends USDC to both IPA3 and the LAP contract based on the **royalty stack** (15%) -3. LAP will distribute funds to further ancestors since they have negotiated some license agreement where they are due revenue from IPA3's earnings. +1. Доход сначала поступает в контракт Модуля Роялти. +2. Модуль Роялти распределяет USDC между IPA3 и контрактом LAP на основе **стека роялти** (15%). +3. LAP распределяет средства среди других предков, так как они заключили лицензионное соглашение, в соответствии с которым они имеют право на часть дохода IPA3. -**Don't worry if you don't understand everything in the picture, this is just to show you an overview of what the Royalty Module is all about.** +**Не переживайте, если вы не понимаете все детали на изображении, оно лишь дает общий обзор работы Модуля Роялти.** ![](https://files.readme.io/25e44cabafe06886fef078422c3d48c472f25a12b6ea60207ffa0b63ef2cd65b-image.png) -## Royalty Policies +## Политики Роялти -Royalty policies are a component of the license agreement between two IP Assets. It defines how revenue flow actually happens. +Политики Роялти являются частью лицензионного соглашения между двумя IP-активами. Они определяют, как именно происходит распределение дохода. -The Royalty Module supports both whitelisted/native policies created by our team directly, and external ones created by you. +Модуль Роялти поддерживает как одобренные/встроенные политики, созданные нашей командой, так и внешние политики, которые можно создать самостоятельно. -> 📘 Note on Royalty Policies +> 📘 Примечание по Политике Роялти > -> An IP Asset without any parents can mint licenses with different royalty policies while a derivative IP Asset inherits the royalty policy of its parents. +> IP-актив, у которого нет родителей, может создавать лицензии с разными Политиками Роялти, в то время как производный IP-актив наследует Политику Роялти своих родителей. > -> Additionally, there will always be one royalty policy governing every link an IP Asset has with each of its derivatives. +> Кроме того, каждая связь IP-актива с производным активом всегда регулируется одной Политикой Роялти. -### Whitelisted/Native Royalty Policies +### Одобренные/Встроенные Политики Роялти -These policies require governance whitelisting and guarantee royalty token distribution to ancestors. +Эти политики требуют одобрения сообществом и гарантируют распределение токенов роялти среди предков. -1. [Liquid Absolute Percentage (LAP)](doc:liquid-absolute-percentage) -2. [Liquid Relative Percentage (LRP)](doc:liquid-relative-percentage) +1. [Ликвидный Абсолютный Процент (LAP)](doc:liquid-absolute-percentage) +2. [Ликвидный Относительный Процент(LRP)](doc:liquid-relative-percentage) -### External Royalty Policies +### Внешние политики роялти -These policies can be registered in a permission-less way and stipulate their own royalty and revenue distribution rules. +Эти политики могут быть зарегистрированы без разрешений и включать собственные правила распределения доходов и роялти. -* [External Royalty Policies](doc:external-royalty-policies) +* [Внешняя Политика Роялти](doc:external-royalty-policies)
-#### Royalty Token % vs Royalty Stack % +#### Роялти Токен % vs Роялти Стек % -When creating a derivative, the creator will want to answer the question: "How much percentage of my IP earnings will I keep and how much will go to ancestor IPs? +При создании производного актива создателю необходимо ответить на вопрос: «Какой процент дохода от моей IP я сохраню для себя, а сколько достанется родительским IP?» -To answer this question two concepts are important: +Для этого важны два понятия: -1. Royalty Token - Each IP Asset has 100,000,000 Royalty Tokens associated, where each token represents 0.000001% of the capital that enters each IP Royalty Vault. The holders of these Royalty Tokens can claim the Revenue Tokens that are in the associated IP Royalty Vault. -2. Royalty Stack - is the percentage of IP revenue that has to be paid to ancestors via Whitelisted/Native royalty policies. External royalty policies do not use the royalty stack percentgae - only Whitelisted/Native royaltys policies do. +1. Токены Роялти — Каждый IP-актив имеет 100,000,000 Токенов Роялти, где каждый токен представляет 0.000001% капитала, поступающего в Хранилище Роялти IP. Владельцы этих токенов могут требовать доход, находящийся в связанном Хранилище Роялти IP. +2. Стек Роялти — это процент дохода IP, который необходимо выплатить предкам через встроенные политики роялти. Внешние Политики Роялти не используют процент Стека Роялти, только встроенные. -Let's imagine the scenario below: +Представим следующий сценарий: -* IP1 is a root IP Asset. -* IP2 is a derivative of IP1. -* User A has 100% of Royalty Tokens of IP1 -* User B has 20% of Royalty Tokens of IP2 -* User C has 80% of Royalty Tokens of IP2 -* IP2 Royalty Stack is 10% - meaning that all its ancestor IPs via Native/Whitelisted policies require IP2 to pay 10% of its revenue in order to create the derivative. In this case, there is only 1 ancestor which is IP1. IP1 demands 10% of IP2's future revenue in order to create a derivative. +* IP1 — корневой IP-актив. +* IP2 — производный актив IP1. +* Пользователь A владеет 100% Токенов Роялти IP1. +* Пользователь B владеет 20% Токенов Роялти IP2. +* Пользователь C владеет 80% Токенов Роялти IP2. +* Стек роялти IP2 составляет 10% — это значит, что все его предки через встроенные политики роялти требуют, чтобы IP2 выплачивал 10% своего дохода. В данном случае предок только один — это IP1. IP1 требует 10% будущего дохода IP2. -In the image below there is an example of a one million USDC payment made to IP2. In the image we can see how much each Royalty Token holder of the entire derivative chain receives when the payment is made. +На изображении ниже показан пример выплаты в размере 1 миллиона USDC на адрес IP2. На нем видно, как распределяется доход среди владельцев Токенов Роялти всей цепочки производных активов. ![](https://files.readme.io/a96e7d196a85f69dceb2b125ce70008115e15d0aa76b4e14b0dff2007525051b-image.png) -* RT Holder A - From the one million USDC payment gets 100k USDC. Royalty Stack percentage is paid first and RT Holder A has 100% of Royalty Tokens of IP1 so gets to keep the whole 100k USDC. -* RT Holder B - From the one million USDC payment gets 180k USDC. IP2 holders as a whole receive 900k USDC from the original one million USDC payment. Those 900k USDC are then split among the different Royalty Token holders of IP2 which are B and C. B has 20% of Royalty Tokens of IP2 so it receives 900k USDC \* 20% = 180k. -* RT Holder C - From the one million USDC payment gets 720k USDC. IP2 holders as a whole receive 900k USDC from the original one million USDC payment. Those 900k USDC are then split among the different Royalty Token holders of IP2 which are B and C. C has 80% of Royalty Tokens of IP2 so it receives 900k USDC \* 80% = 720k. +* Владелец RT A — из одного миллиона USDC получает 100k USDC. Сначала выплачивается процент Стека Роялти, и владелец RT A, имеющий 100% Токенов Роялти IP1, получает всю сумму 100k USDC. +* Владелец RT B — из одного миллиона USDC получает 180k USDC. Владельцы IP2 в целом получают 900k USDC. Эти 900k USDC распределяются между владельцами Токенов Роялти IP2: B и C. B имеет 20% Токенов Роялти IP2, поэтому получает 900k USDC \* 20% = 180k. +* Владелец RT C — из одного миллиона USDC получает 720k USDC. Владельцы IP2 в целом получают 900k USDC, которые распределяются между B и C. C имеет 80% Токенов Роялти IP2, поэтому получает 900k USDC * 80% = 720k.
-## Derivative Chain Configurations +## Конфигурации цепочки производных активов ![](https://files.readme.io/79bd27f-image.png) -The derivative chain can assume multiple configurations. +Цепочка производных активов может принимать различные конфигурации. -Each IP Asset is restricted to a total royalty % of 100%. It will revert when minting a license that would make the IPA reserve more than 100% of its royalty tokens for ancestors, since this would make no sense. \ No newline at end of file +Каждый IP-актив ограничен максимальным процентом роялти в 100%. При попытке создать лицензию, которая зарезервирует более 100% токенов роялти для предков, транзакция будет отклонена, так как это не имеет смысла. \ No newline at end of file From 9fc371583b592c1b1de7a056b5d4c04c5e1533e0 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Thu, 2 Jan 2025 13:13:50 +0300 Subject: [PATCH 06/10] royalty module --- .../royalty-module/ip-royalty-vault.md | 69 +++++++++++-------- .../liquid-absolute-percentage.md | 51 +++++++------- .../liquid-relative-percentage.md | 54 +++++++-------- 3 files changed, 91 insertions(+), 83 deletions(-) diff --git a/docs/Concepts/royalty-module/ip-royalty-vault.md b/docs/Concepts/royalty-module/ip-royalty-vault.md index 4efb9ff..a25d250 100644 --- a/docs/Concepts/royalty-module/ip-royalty-vault.md +++ b/docs/Concepts/royalty-module/ip-royalty-vault.md @@ -1,69 +1,78 @@ --- -title: IP Royalty Vault -excerpt: '' +title: Хранилище Роялти IP +excerpt: "" deprecated: false hidden: false metadata: - title: '' - description: '' + title: "" + description: "" robots: index next: - description: '' + description: "" --- -> ⏩ Skip the Read - 1 Minute Summary + +> ⏩ Читать не обязательно - 1-минутное саммари > -> An IP Royalty Vault is a pool for all monetary inflows related to an IP Asset. +> Хранилище Роялти IP – это пул, в котором хранятся все денежные поступления, связанные с IP-активом > -> Every IP Asset has 100,000,000 Royalty Tokens associated with it, where each token represents the right to 0.000001% of that IPA's revenue (*"Revenue Tokens"*) stored in the pool. +> Каждый IP-актив имеет 100,000,000 Токенов Роялти, где каждый токен представляет собой право на 0.000001% дохода этого актива («Токены Дохода»), хранящегося в пуле. > -> Revenue Tokens are ERC-20 tokens used for payment (ex. USDC). These tokens must be whitelisted by the protocol to be used. +> Токены Дохода – это токены стандарта ERC-20, используемые для оплаты (например, USDC). Для использования токены должны быть включены в белый список протокола. -Each IP Asset has an IP Royalty Vault, which acts as a pool for all monetary inflows related to an IP Asset's commercial exploration or from minting licenses. Anyone who holds Royalty Tokens (defined below) has the right to claim their share of this pool. +Каждый IP-актив имеет свое Хранилище Роялти IP, которое служит пулом для всех денежных поступлений, связанных с коммерческой эксплуатацией IP или выдачей лицензий. Любой владелец Токенов Роялти имеет право требовать свою долю из этого пула. -## Token Terminology +## Терминология токенов -1. Royalty Tokens - the IP Royalty Vault contract is also the ERC-20 contract for the Royalty Tokens of each IP Asset. This means the address of the IP Royalty Vault for an IP Asset is also the ERC-20 token address of the Royalty Tokens. Each IP Asset has 100,000,000 Royalty Tokens associated, where each token represents 0.000001% of those gains. The holders of these Royalty Tokens can claim the Revenue Tokens (defined below) that are in the associated IP Royalty Vault. -2. Revenue Tokens - these are the tokens used for payment (ie. ETH, USDC, etc). Royalty Tokens can be used to claim Revenue Tokens. - 1. An ERC-20 token must be whitelisted by governance in the [RoyaltyModule.sol contract](https://github.com/storyprotocol/protocol-core-v1/blob/e339f0671c9172a6699537285e32aa45d4c1b57b/contracts/modules/royalty/RoyaltyModule.sol#L50) to be used as a Revenue Token in the Royalty Module. +1. Токены Роялти – контракт Хранилища Роялти IP также является контрактом ERC-20 для Токенов Роялти каждого IP-актива. Это означает, что адрес Хранилища Роялти IP для IP-актива также является адресом Токенов Роялти. Каждый IP-актив имеет 100,000,000 Токенов Роялти, и каждый токен представляет 0.000001% дохода. Владельцы этих токенов могут требовать Токены Дохода (см. ниже), находящиеся в соответствующем Хранилище Роялти IP. +2. Токены Дохода – это токены, используемые для оплаты (например, ETH, USDC и т.д.). Токены Роялти могут быть использованы для получения Токенов Дохода. + Токен ERC-20 должен быть включен в белый список управления в контракте [RoyaltyModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/e339f0671c9172a6699537285e32aa45d4c1b57b/contracts/modules/royalty/RoyaltyModule.sol#L50), чтобы его можно было использовать как Токен Дохода. -### Whitelisted Revenue Tokens +### Токены Дохода из белого списка -An ERC-20 token must be whitelisted by our protocol in the [RoyaltyModule.sol contract](https://github.com/storyprotocol/protocol-core-v1/blob/e339f0671c9172a6699537285e32aa45d4c1b57b/contracts/modules/royalty/RoyaltyModule.sol#L50) to be used as a Revenue Token. Here are the whitelisted tokens (you can mint tokens directly from the link): +ERC-20 токен должен быть включен в белый список нашего протокола в контракте [RoyaltyModule.sol](https://github.com/storyprotocol/protocol-core-v1/blob/e339f0671c9172a6699537285e32aa45d4c1b57b/contracts/modules/royalty/RoyaltyModule.sol#L50), чтобы быть использованным в качестве Токена Дохода. Вот список токенов из белого списка (вы можете сгенерировать токены по ссылке): -| Token | Contract Address | Mint | +| Токен | Адрес Контракта | Создать | | :---- | :------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | -| SUSD | `0xC0F6E387aC0B324Ec18EAcf22EE7271207dCE3d5` | Mint SUSD ↗️ | +| SUSD | `0xC0F6E387aC0B324Ec18EAcf22EE7271207dCE3d5` | Минт SUSD ↗️ | | WIP | `0x1516000000000000000000000000000000000000` | | -## How to obtain Royalty Tokens? +## Как получить Токены Роялти -When an IP Asset receives revenue, it is deposited into its IP Royalty Vault. In order to claim revenue from this vault, you must have the associated Royalty Tokens. Once any address owns Royalty Tokens of a given IP Asset, it is entitled to that % (% of the total supply of Royalty Tokens owned) of any future Revenue Token (that is whitelisted) received & in the IP Royalty Vault. +Когда IP-актив получает доход, он помещается в его Хранилище Роялти IP. Чтобы получить доход из этого хранилища, необходимо обладать соответствующими Токенами Роялти. Любой адрес, владеющий Токенами Роялти для данного IP-актива, имеет право на соответствующий процент дохода (процент от общего количества токенов роялти, находящихся в обращении). -There are two ways that trigger the IP Royalty Vault deployment and make the initial Royalty Token distribution - whichever comes first: +Хранилище Роялти IP активируется, а Токены Роялти распределяются при выполнении одного из двух условий (в зависимости от того, что произойдет раньше): -* IP mints a license token for the first time - the associated IP Account receives 100% of the Royalty Tokens -* IP registers as a derivative - the associated IP Account receives y% of the Royalty Tokens and (100-y)% is sent to the Royalty Policy contracts that are part of the IP's ancestry. The y% is the amount the IP has to reserve/give to all its ancestors in order to create the derivative IP. +- Выпуск лицензии: Если IP-актив впервые выпускает Токен Лицензии, связанный IP-аккаунт получает 100% токенов роялти. +- Регистрация производного актива: Если IP-актив регистрируется как производный, связанный IP-аккаунт получает y% токенов роялти, а (100-y)% отправляется в контракты Политики Роялти, связанные с предшествующими активами в цепочке происхождения. y% – это доля, которую IP обязан зарезервировать для своих предшественников. -Because Royalty Tokens are ERC-20, they can be transferred like any other token. Thus, the IP Account could send them to someone else, or even put them up for sale on the secondary market. +Роялти Токены как токены ERC-20 могут быть отправлены кому-то или даже размещены на продажу на вторичном рынке. -## How Revenue Flows +## Как происходит распределение доходов This section will help explain how revenue flows from the time of payment to being claimed by the royalty token holder. For the purposes of explanation, we will use an example from the [Liquid Absolute Percentage (LAP)](doc:liquid-absolute-percentage), but it is the same for any royalty policy. +Эта секция объясняет, как доход распределяется с момента оплаты до его получения владельцем Токенов Роялти. Рассмотрим пример, связанный с [Ликвидным Абсолютным Процентом (LAP)](doc:liquid-absolute-percentage), однако процесс идентичен для других Политик Роялти: -Imagine we have a scenario where IPA4 tips IPA3 1M USDC by calling `payRoyaltyOnBehalf`. +Пример оплаты: IPA4 переводит IPA3 1 миллион USDC, вызывая функцию `payRoyaltyOnBehalf`. 1. Revenue Tokens flow to the Royalty Module contract. This contract then splits up the tokens based on the **royalty stack** on the receiving IPA. In this case, IPA3 has a royalty stack of 15%, so 850k tokens flow to IP Royalty Vault 3, and 150k tokens flow to the LAP contract. +Токены Дохода поступают в контракт Модуля Роялти, который распределяет их в соответствии со **стеком роялти** для получающего актива. Например, если стек роялти IPA3 составляет 15%, 850k USDC поступает в хранилище IPA3, а 150k – в контракт LAP. ![](https://files.readme.io/be5dfdf9064320904ca27bc1f12a2475456064a19049b7d8fb2500d094746e1d-image.png) -2. The LAP contract separates the payment to the ancestors by calling `transferToVault`. In this case, IPA2 deserves 100k (10% of IPA3's earnings) and IPA1 deserves 50k (5% of IPA3's earnings). + +2. Контракт LAP распределяет оплату предшественникам, вызывая `transferToVault`. Например, IPA2 получает 100k (10% дохода IPA3), а IPA1 – 50k (5% дохода IPA3). ![](https://files.readme.io/1ad3a4827aa302dd94bcf45ebca6749b68821fcfaadb6a85c9b70b9c8d3f4af5-image.png) -3. Now that the Revenue Tokens are in the IP Royalty Vaults, the associated Royalty Token holders can claim from the vaults. Remember, the Revenue Tokens get claimed to whoever holds the Royalty Tokens. In the most common case, they are in the IP Account since that's where they originate. To claim, you would call either `claimRevenueOnBehalfByTokenBatch` or `claimRevenueOnBehalf`. + +3. Теперь Токены Дохода находятся в Хранилище Роялти IP. Владельцы соответствующих Токенов Роялти могут запросить их. Обычно они хранятся в IP-аккаунте, откуда и происходят. Для запроса необходимо вызвать `claimRevenueOnBehalfByTokenBatch` или `claimRevenueOnBehalf` ![](https://files.readme.io/c3523d5de4a3129f07eeceff5ff577178c3b3161b35fa2b75ed6e8ef98191872-image.png) -### External Royalty Policies +### Внешние Политики Роялти Revenue Tokens can also move from a vault to another vault via the functions `claimByTokenBatchAsSelf` located in the `IpRoyaltyVault.sol` contract. For this to be possible the vault that is claiming revenue tokens needs to own Royalty Tokens of the vault being claimed from. This can be particularly useful when used together with external royalty policies. -Vaults can only claim from other vaults if those other vaults belong to IPs in the same derivative chain. If a vault owns royalty tokens from an IP but it is not an ancestor of that IP, it is not possible to claim rewards with those royalty tokens. \ No newline at end of file +Vaults can only claim from other vaults if those other vaults belong to IPs in the same derivative chain. If a vault owns royalty tokens from an IP but it is not an ancestor of that IP, it is not possible to claim rewards with those royalty tokens. + +Токены Дохода могут перемещаться из одного хранилища в другое с помощью функции `claimByTokenBatchAsSelf`, находящейся в контракте `IpRoyaltyVault.sol`. Однако для этого хранилище, запрашивающее токены, должно владеть Токенами Роялти хранилища, из которого оно запрашивает доход. + +Это возможно только для хранилищ, принадлежащих активам в одной и той же цепочке производных. Если хранилище владеет Токенами Роялти актива, который не является его предком, получение дохода с этих токенов невозможно. \ No newline at end of file diff --git a/docs/Concepts/royalty-module/liquid-absolute-percentage.md b/docs/Concepts/royalty-module/liquid-absolute-percentage.md index 5f2cf56..aef6d2a 100644 --- a/docs/Concepts/royalty-module/liquid-absolute-percentage.md +++ b/docs/Concepts/royalty-module/liquid-absolute-percentage.md @@ -1,5 +1,5 @@ --- -title: Liquid Absolute Percentage (LAP) +title: Ликвидный Абсолютный Процент (LAP) excerpt: '' deprecated: false hidden: false @@ -10,49 +10,48 @@ metadata: next: description: '' --- -> ⏩ Skip the Read - 1 Minute Summary +> ⏩ Читать не обязательно - 1-минутное саммари > -> Let's come up with an example: An IP Asset ('C') is a child of 'B', and 'B' is a child of 'A', such that it goes A▶️B▶️C. 'A' specifies that any descendant must share 5% of their revenue with it. On the other hand, 'B' specifies that any descendants must share 10% of their revenue with it. +> Представим пример: IP-актив "C" является производным от "B", а "B" – производным от "A", то есть A▶️B▶️C. "A" указывает, что любой потомок должен делиться 5% своего дохода с ним. В то же время "B" указывает, что любой потомок должен делиться 10% дохода с ним. > -> Okay, great. Let's see what happens in two (independent) common scenarios: +> Рассмотрим два независимых сценария: > -> 1. **Minting a License** - 'C' mints a license from 'B' that costs 100 USDC. When 'C' pays 'B' 100 USDC to mint a license, 'A' claims 5 USDC from B. In the end, 'B' only gets 95 USDC. -> 2. **Tipping Directly** - 'C' is a comic book that is super well written. Someone tips 100 USDC to 'C' because they love it. 'A' claims 5 USDC from 'C'. 'B' claims 10 USDC from 'C'. In the end, 'C' only gets 85 USDC. +> 1. **Выпуск лицензии** – "C" выпускает лицензию от "B", которая стоит 100 USDC. Когда "C" платит "B" 100 USDC за выпуск лицензии, "A" получает 5 USDC от "B". В результате "B" получает только 95 USDC. +> 2. **Прямой донат** – "C" – это супер качественный комикс. Кто-то отправляет 100 USDC "C" в знак признания. "A" получает 5 USDC от "C". "B" получает 10 USDC от "C". В итоге "C" остаётся 85 USDC. -The Liquid Absolute Percentage (LAP) defines that each parent IP Asset can choose a minimum royalty percentage that all of its downstream IP Assets in a derivative chain will share from their monetary gains as defined in the license agreement. +LAP определяет, что каждый родительский IP-актив может установить минимальный процент роялти, которым все его потомки в производной цепочке обязаны делиться от своей прибыли согласно лицензионному соглашению. -## Prerequisites +## Предварительные условия -Before continuing, make sure you have read the [IP Royalty Vault](doc:ip-royalty-vault) terminology. +Перед продолжением убедитесь, что вы прочитали раздел с терминологией [Хранилища Роялти IP](doc:ip-royalty-vault). -## Royalty Payment and Claiming Flow +## Поток выплат и запрос роялти -In the image below, IPA 1 and IPA 2 - due to being ancestors of IPA 3 - have a % economic right over revenue made by IPA 3. Key notes to understand the derivative chain below: +На изображении ниже IPA 1 и IPA 2 – будучи предками IPA 3 – имеют экономическое право на долю дохода, который получает IPA 3. Ключевые термины для понимания производной цепочки: -* License Royalty Percentage - this percentage is selected by the user and it means the percentage that the user wants - according to LAP rules - in return for allowing other users to remix its IPA. -* Royalty Stack - is the revenue an IPA has to pay all its ancestors. For LAP royalty stack = sum of parents royalty stack + sum of licenses percentages used to connect to each parent - * Royalty Stack IPA 2 = Royalty Stack IPA 1 + License Royalty % between IPAs 1 and 2 = 0% + 5% = 5% - * Royalty Stack IPA 3 = Royalty Stack IPA 2 + License Royalty % between IPAs 2 and 3 = 5% + 10% = 15% -* Royalty Tokens flow to the IPA initially when a vault is deployed. The Royalty Tokens can be transferred to any other address and after that transfer any future royalty inflow will be claimable by that new address which now holds the RTs. +* Процент лицензионных роялти – это процент, который пользователь выбирает для себя в соответствии с правилами LAP в обмен на разрешение другим пользователям использовать его IPA. + * Стек роялти IPA 2 = стек роялти IPA 1 + процент лицензионных роялти между IPA 1 и IPA 2 = 0% + 5% = 5% + * Стек роялти IPA 3 = стек роялти IPA 2 + процент лицензионных роялти между IPA 2 и IPA 3 = 5% + 10% = 15% +* Токены Роялти распределяются в IPA сразу при развёртывании хранилища. Эти токены можно передавать на другие адреса, и все будущие выплаты роялти будут доступны для получения этим новым владельцем. ![](https://files.readme.io/dcfb36162a224000d960fe9d6ca451bf7679500a31e727fb7205d22cb3581391-image.png) -Now, let's imagine a scenario where a new IP Asset 4 intends to join the derivative chain as a derivative of IP Asset 3. An example flow sequence below: +Теперь рассмотрим сценарий, в котором новый IP-актив 4 хочет присоединиться к производной цепочке как производный от IP-актива 3. Пример последовательности действий: -1. IP Asset 4 pays 1M USDC in royalties to its parent IPA 3 by calling `payRoyaltyOnBehalf`. Note that the royalty process is the same whether the payment is the license minting fee or any other royalty payment - with the difference being that the license minting fee is made via `payLicenseMintingFee` and is mandatory upon derivative creation. Once a payment is made, a share equivalent to the IPA 3 royalty stack % is sent to the royalty policy contract and the remaining amount is sent to the IPA 3 vault. +1. Актив 4 выплачивает 1 млн USDC в роялти своему родителю IPA 3 через вызов функции `payRoyaltyOnBehalf`. Обратите внимание, что процесс роялти одинаков независимо от того, является ли это платой за выпуск лицензии или любой другой выплатой. Различие лишь в том, что лицензионная плата выплачивается через функцию `payLicenseMintingFee` и является обязательной при создании производного актива. После оплаты доля, равная проценту стека роялти IPA 3, отправляется в контракт политики роялти, а оставшаяся часть – в хранилище IPA 3. ![](https://files.readme.io/5b32b2bbdefe8e9d4c0a36016360b1b0bddaed899c889586df476ae736032478-image.png) -2. Each ancestor can call `transferToVault` on the royalty policy contract to receive the amount each ancestor has the right to claim from a given descendant. Funds are moved to the ancestor's IP Royalty Vault. - 1. 100k USDC are transferred to the IP Royalty Vault 2 since it the right to 10% of all IPA 2 descendants revenue - 2. 50k USDC are transferred to the IP Royalty Vault 1 since it the right to 5% of all IPA 2 descendants revenue +2. Каждый предок может вызвать функцию `transferToVault` в контракте политики роялти, чтобы получить свою долю, на которую он имеет право. Средства переводятся в хранилище роялти предков. + 1. 100k USDC переводится в хранилище IPA 2, так как оно имеет право на 10% от доходов всех потомков IPA 2. + 2. 50k USDC переводится в хранилище IPA 1, так как оно имеет право на 5% от доходов всех потомков IPA 2. ![](https://files.readme.io/76059536b28ba6daee35328f15baa4995850a5c54f00a1bcf863620e04a0eba3-image.png) -3. In the final step of the claiming flow, any Royalty Token holder address can call `claimRevenueOnBehalfByTokenBatch`/`claimRevenueOnBehalf` (for non-vault claimers) or `claimRevenueByTokenBatchAsSelf` (when the claimer is an IP Royalty Vault) to claim revenue tokens. In the current example: - 1. 50k USDC are claimed to the IPA 1 which holds 100% RT1 - 2. 100k USDC are claimed to the IPA 2 which holds 100% RT2 - 3. 850k USDC are claimed by IPA 3 which holds 100% RT3\ - Note: Any royalty token holder address can claim - whether it is a smart contract, IPA, or EOA. +3. На финальном этапе любой владелец токенов роялти может вызвать функции `claimRevenueOnBehalfByTokenBatch`/`claimRevenueOnBehalf` (для адресов, не являющихся хранилищами) или `claimRevenueByTokenBatchAsSelf` (если запрос выполняется хранилищем роялти) для получения дохода. В текущем примере: + 1. 50k USDC запрашивается IPA 1, который владеет 100% RT1. + 2. 100k USDC запрашивается IPA 2, который владеет 100% RT2. + 3. 850k USDC запрашивается IPA 3, который владеет 100% RT3\ + Примечание: Любой адрес, владеющий Токенами Роялти, может запрашивать выплаты, будь то смарт-контракт, IPA или стандартный адрес EOA. ![](https://files.readme.io/cdc8c8569c1cb6106542c7f663ee06059a28105f5b32671dfa77331071f0d128-image.png) \ No newline at end of file diff --git a/docs/Concepts/royalty-module/liquid-relative-percentage.md b/docs/Concepts/royalty-module/liquid-relative-percentage.md index 60bbffc..11547a0 100644 --- a/docs/Concepts/royalty-module/liquid-relative-percentage.md +++ b/docs/Concepts/royalty-module/liquid-relative-percentage.md @@ -1,5 +1,5 @@ --- -title: Liquid Relative Percentage (LRP) +title: Ликвидный Относительный Процент (LRP) excerpt: '' deprecated: false hidden: false @@ -10,53 +10,53 @@ metadata: next: description: '' --- -> ⏩ Skip the Read - 1 Minute Summary +> ⏩ Читать не обязательно - 1-минутное саммари > -> Let's come up with an example: An IP Asset ('C') is a child of 'B', and 'B' is a child of 'A', such that it goes A▶️B▶️C. 'A' specifies that any **direct** descendant must share 5% of their revenue with it. On the other hand, 'B' specifies that any **direct** descendants must share 10% of their revenue with it. +> Представим пример: IP-актив "C" является производным от "B", а "B" является производным от "A", то есть A▶️B▶️C. "A" указывает, что каждый **непосредственный потомок** должен делиться 5% своего дохода с ним. В то же время "B" указывает, что каждый **непосредственный потомок** должен делиться 10% своего дохода с ним. > -> Okay, great. Let's see what happens in two (independent) common scenarios: -> -> 1. **Minting a License** - 'C' mints a license from 'B' that costs 100 USDC. When 'C' pays 'B' 100 USDC to mint a license, 'A' claims 5 USDC from B. In the end, 'B' only gets 95 USDC. -> 2. **Tipping Directly** - 'C' is a comic book that is super well written. Someone tips 100 USDC to 'C' because they love it. 'B' claims 10 USDC from 'C'. 'A' claims 0.5 USDC from 'B' (5% of 10). In the end, 'C' only gets 90 USDC. +> Рассмотрим два независимых сценария: +> 1. **Выпуск лицензии** – "C" выпускает лицензию от "B", которая стоит 100 USDC. Когда "C" платит "B" 100 USDC за выпуск лицензии, "A" получает 5 USDC от "B". В итоге "B" получает только 95 USDC. +> 2. **Прямой донат** – "C" – это супер качественный комикс. Кто-то отправляет 100 USDC "C" в знак признания. "B" получает 10 USDC от "C". "A" получает 0.5 USDC от "B" (5% от 10). В итоге "C" остаётся 90 USDC. + +LRP определяет, что каждый родительский IP-актив может установить минимальный процент роялти, который только непосредственные производные активы интеллектуальной собственности в цепочке будут делить от своей прибыли согласно лицензионному соглашению. -The Liquid Relative Percentage (LRP) royalty policy defines that each parent IP Asset can choose a minimum royalty percentage that only the direct derivative IP Assets in a derivative chain will share from their monetary gains as defined in the license agreement. +## Предварительные условия -## Prerequisites +Перед продолжением убедитесь, что вы прочитали раздел с терминологией [Хранилища Роялти IP](doc:ip-royalty-vault). -Before continuing, make sure you have read the [IP Royalty Vault](doc:ip-royalty-vault) terminology. +## Поток выплат и запрос роялти -## Royalty Payment and Claiming Flow +На изображении ниже IPA 1 и IPA 2 – будучи предками IPA 3 – имеют экономическое право на долю дохода, который получает IPA 3. Ключевые термины для понимания производной цепочки: -In the image below, IPA 1 and IPA 2 - due to being ancestors of IPA 3 - have a % economic right over revenue made by IPA 3. Key notes to understand the derivative chain below: +* Процент лицензионных роялти – это процент, который пользователь выбирает для себя в соответствии с правилами LRP в обмен на разрешение другим пользователям использовать его IPA. +* Стек роялти LRP – это совокупная сумма роялти, которую IPA должен выплатить всем своим родителям. + * Стек роялти IPA 2 = процент лицензионных роялти между IPA 1 и IPA 2 = 5% + * Стек роялти IPA 3 = процент лицензионных роялти между IPA 2 и IPA 3 = 10% +* Токены Роялти распределяются в IPA сразу при развёртывании хранилища. Эти токены можно передавать на другие адреса, и все будущие выплаты роялти будут доступны для получения этим новым владельцем. -* License Royalty Percentage - this percentage is selected by the user and it means the percentage that the user wants - according to LRP rules - in return for allowing other users to remix its IPA. -* Royalty Stack LRP - is the revenue an IPA has to pay all its parent. For LRP royalty stack = sum of licenses percentages used to connect to each parent - * Royalty Stack IPA 2 = License Royalty % between IPAs 1 and 2 = 5% - * Royalty Stack IPA 3 = License Royalty % between IPAs 2 and 3 = 10% -* Royalty tokens flow to the IPA initially when a vault is deployed. The Royalty Tokens can be transferred to any other address and after that transfer any future royalty inflow will be claimable by that new address which now holds the RTs. ![](https://files.readme.io/de296f0efbb58233b5f340b127dc66a48c80eff88a75b809107ea8b95beca5a6-image.png) -Now, let's imagine a scenario where a new IP Asset 4 intends to join the derivative chain as a derivative of IP Asset 3. An example flow sequence below: +Теперь рассмотрим сценарий, в котором новый IP-актив 4 хочет присоединиться к производной цепочке как производный от IP-актива 3. Пример последовательности действий: -1. IP Asset 4 pays 1M USDC in royalties to its parent IPA 3 by calling `payRoyaltyOnBehalf`. Note that the royalty process is the same whether the payment is the license minting fee or any other royalty payment - with the difference being that the license minting fee is made via `payLicenseMintingFee` and is mandatory upon derivative creation. Once a payment is made, a share equivalent to the IPA 3 royalty stack % is sent to the royalty policy contract and the remaining amount is sent to the IPA 3 vault. +1. Актив 4 выплачивает 1 млн USDC в роялти своему родителю IPA 3 через вызов функции `payRoyaltyOnBehalf`. Обратите внимание, что процесс выплаты роялти одинаков, независимо от того, является ли это платой за выпуск лицензии или любой другой выплатой. Различие лишь в том, что лицензионная плата выплачивается через функцию `payLicenseMintingFee` и является обязательной при создании производного актива. После оплаты доля, равная проценту стека роялти IPA 3, отправляется в контракт политики роялти, а оставшаяся часть – в хранилище IPA 3. ![](https://files.readme.io/29ac6f6c55c2bb507ef8344fbc4351aa5574154e4d8577ec949d96d44cfffb68-image.png)
-2. Each ancestor can call `transferToVault` on the royalty policy contract to receive the amount each ancestor has the right to claim from a given descendant. Funds are moved to the ancestor's IP Royalty Vault. +2. Каждый предок может вызвать функцию `transferToVault` в контракте политики роялти, чтобы получить свою долю, на которую он имеет право. Средства переводятся в хранилище роялти предков. - 1. 95k USDC are transferred to the IP Royalty Vault 2 since it has the right to 10% of all IPA 2 descendants revenue and has to pay 5% of its revenue to its direct parent IPA 1. So 100k is received from IPA 3 and 5k is paid to IPA 1, resulting in IPA 2 keeping 100k - 5k = 95k. - 2. 5k USDC are transferred to the IP Royalty Vault 1 since it has the right to 0.5% of all IPA 2 descendants revenue. IPA 1 has the right to 5% of revenue earned by IPA 2, which in turn has 10% of revenue earned by IPA 3. Given LRP royalty policy considers relative percentages, then IPA 1 has the right to 10%\*5% = 0.5% of revenue earned by IPA 3. + 1. 95k USDC переводится в хранилище IPA 2, так как оно имеет право на 10% от доходов всех потомков IPA 2 и должно выплатить 5% от своего дохода своему непосредственному родителю IPA 1. Так, 100k USDC получены от IPA 3, 5k USDC передаются IPA 1, в результате IPA 2 остаётся с 100k - 5k = 95k. + 2. 5k USDC переводится в хранилище IPA 1, так как оно имеет право на 0,5% от доходов всех потомков IPA 2. IPA 1 имеет право на 5% от дохода, заработанного IPA 2, который в свою очередь имеет 10% от дохода, заработанного IPA 3. Поскольку политика LRP учитывает относительные проценты, IPA 1 имеет право на 10% * 5% = 0,5% от дохода, полученного IPA 3. ![](https://files.readme.io/4956d4151c271dd42773b83ca75e23794c6318b8850cf046156f86b04c783f71-image.png)
-3. In the final step of the claiming flow, any Royalty Token holder address can call `claimRevenueOnBehalfByTokenBatch`/`claimRevenueOnBehalf` (for non-vault claimers) or `claimRevenueByTokenBatchAsSelf` (when the claimer is an IP Royalty Vault) to claim revenue tokens. In the current example: - 1. 5k USDC are claimed to the IPA 1 which holds 100% RT1 - 2. 95k USDC are claimed to the IPA 2 which holds 100% RT2 - 3. 900k USDC are claimed by IPA 3 which holds 100% RT3\ - Note: Any royalty token holder address can claim - whether it is a smart contract, IPA, or EOA. +3. На финальном этапе любой владелец токенов роялти может вызвать функции `claimRevenueOnBehalfByTokenBatch`/`claimRevenueOnBehalf` (для адресов, не являющихся хранилищами) или `claimRevenueByTokenBatchAsSelf` (если запрос выполняется хранилищем роялти) для получения дохода. В текущем примере: + 1. 5k USDC запрашиваются IPA 1, который владеет 100% RT1. + 2.95k USDC запрашиваются IPA 2, который владеет 100% RT2. + 3. 900k USDC запрашиваются IPA 3, который владеет 100% RT3.\ + Примечание: Любой адрес, владеющий Токенами Роялти, может запрашивать выплаты, будь то смарт-контракт, IPA или стандартный адрес EOA. ![](https://files.readme.io/b39ed27190ace760f4b8cb788fdf5ad28e93e3d3f3a5c5b23b122c9a812564bd-image.png) \ No newline at end of file From 61c0de45361a01b89a0c0c6f9a49a14c848aec8a Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Thu, 2 Jan 2025 13:23:43 +0300 Subject: [PATCH 07/10] fixed eng --- docs/Concepts/licensing-module/license-config-hook.md | 2 +- docs/Concepts/programmable-ip-license/index.md | 2 -- docs/Concepts/programmable-ip-license/pil-terms.md | 3 --- docs/Concepts/registry/license-registry.md | 2 -- docs/Concepts/royalty-module/ip-royalty-vault.md | 9 ++------- 5 files changed, 3 insertions(+), 15 deletions(-) diff --git a/docs/Concepts/licensing-module/license-config-hook.md b/docs/Concepts/licensing-module/license-config-hook.md index d4c9932..88226e1 100644 --- a/docs/Concepts/licensing-module/license-config-hook.md +++ b/docs/Concepts/licensing-module/license-config-hook.md @@ -18,7 +18,7 @@ next: > > Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/lib/Licensing.sol). -Optionally, you can attach a `LicensingConfig` to an IP Asset (for a specific `licenseTermsId` attached to that asset) which contains fields like a `mintingFee` and a `licensingHook`, as shown below. + Вы можете опционально прикрепить `LicensingConfig` к IP-активу (для определённых `licenseTermsId`, связанных с этим активом), который содержит такие параметры, как `mintingFee` и `licensingHook`, как показано ниже. ```sol Licensing.sol diff --git a/docs/Concepts/programmable-ip-license/index.md b/docs/Concepts/programmable-ip-license/index.md index 0d31bab..b68dca8 100644 --- a/docs/Concepts/programmable-ip-license/index.md +++ b/docs/Concepts/programmable-ip-license/index.md @@ -28,8 +28,6 @@ next: ## История создания -We searched for a form of a "universal license" that could support these emerging activities at scale. Hat tip to [Creative Commons](https://creativecommons.org/mission/), [Arweave](https://mirror.xyz/0x64eA438bd2784F2C52a9095Ec0F6158f847182d9/AjNBmiD4A4Sw-ouV9YtCO6RCq0uXXcGwVJMB5cdfbhE), A16Z / [Can’t Be Evil,](https://a16zcrypto.com/posts/article/introducing-nft-licenses/) The [Token-Bound NFT License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf) and music rights organizations, among others. But we simply couldn't find one framework or agreement robust enough - so with our expert legal counsel (with special thanks to Ghaith Mahmood and Heather Liu) we created one ourselves! **Introducing the Story Protocol Programmable IP License (PIL:pill:), the first example of a [License Template](doc:license-template) on the protocol.** - [Модуль Лицензирования](doc:licensing-module) Story Protocol (Licensing Module) был создан для поддержки новых форм творчества, таких как разрешённые ремиксы и совместное создание. Протокол поддерживает любые форматы медиа и проекты — от пользовательских видео и изображений до создания контента уровня Голливуда. Владельцы интеллектуальной собственности могут разрешать третьим сторонам использовать или развивать свои работы, предоставляя права по лицензии, будь то в коммерческих целях или на благо общества. В медиаиндустрии такие лицензии, как правило, представляют собой индивидуализированные контракты, которые зависят от формата медиа и нужд лицензиаров. Для их создания часто требуется юридическая экспертиза и значительные ресурсы. diff --git a/docs/Concepts/programmable-ip-license/pil-terms.md b/docs/Concepts/programmable-ip-license/pil-terms.md index ba8859a..8909846 100644 --- a/docs/Concepts/programmable-ip-license/pil-terms.md +++ b/docs/Concepts/programmable-ip-license/pil-terms.md @@ -15,8 +15,6 @@ next: > > [Готовые варианты условий PIL](https://docs.story.foundation/docs/pil-flavors-preset-policy). -PIL is the first License Agreement for medial license developed by Story Protocol and inspired by [Token Bound License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf). If you haven't already, read the overview: [Programmable IP License (PIL💊)](doc:programmable-ip-license) - PIL (Программируемая Лицензия IP) — это первая лицензия для медийных лицензий, разработанная Story Protocol и вдохновленная [Token Bound License](https://james.grimmelmann.net/files/articles/token-bound-nft-license.pdf). Если вы еще не знакомы, прочитайте обзор:[Программируемая Лицензия IP (PIL💊)](doc:programmable-ip-license). > 📘 Текст PIL @@ -25,7 +23,6 @@ PIL (Программируемая Лицензия IP) — это первая # Условия на блокчейне -Most PIL terms are on-chain. They are implemented in the `IPILicenseTemplate` contract as a `PILTerms` struct [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/licensing/IPILicenseTemplate.sol). Большинство условий PIL реализованы на блокчейне. Они включены в контракт `IPILicenseTemplate` как структура `PILTerms`. Ознакомьтесь с исходным кодом [здесь](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/licensing/IPILicenseTemplate.sol). ```sol IPILicenseTemplate.sol diff --git a/docs/Concepts/registry/license-registry.md b/docs/Concepts/registry/license-registry.md index 2f944f9..d98946e 100644 --- a/docs/Concepts/registry/license-registry.md +++ b/docs/Concepts/registry/license-registry.md @@ -14,8 +14,6 @@ next: > > Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/registries/LicenseRegistry.sol). -The License Registry stores all license-related states within the protocol, including managing global state like registering new License Templates like the [Programmable IP License (PIL💊)](doc:programmable-ip-license), attaching licenses to individual [IP Assets](doc:ipasset), registering derivatives, and the like: - Реестр Лицензий хранит все состояния, связанные с лицензиями в протоколе, включая управление глобальными состояниями, такими как регистрация новых шаблонов лицензий, например, [Программируемая Лицензия IP (PIL💊)](doc:programmable-ip-license), прикрепление лицензий к отдельным [IP-активам](doc:ipasset), регистрацию производных активов и тому подобное: ```sol LicenseRegistry.sol diff --git a/docs/Concepts/royalty-module/ip-royalty-vault.md b/docs/Concepts/royalty-module/ip-royalty-vault.md index a25d250..1ff0391 100644 --- a/docs/Concepts/royalty-module/ip-royalty-vault.md +++ b/docs/Concepts/royalty-module/ip-royalty-vault.md @@ -49,13 +49,12 @@ ERC-20 токен должен быть включен в белый списо ## Как происходит распределение доходов -This section will help explain how revenue flows from the time of payment to being claimed by the royalty token holder. For the purposes of explanation, we will use an example from the [Liquid Absolute Percentage (LAP)](doc:liquid-absolute-percentage), but it is the same for any royalty policy. + Эта секция объясняет, как доход распределяется с момента оплаты до его получения владельцем Токенов Роялти. Рассмотрим пример, связанный с [Ликвидным Абсолютным Процентом (LAP)](doc:liquid-absolute-percentage), однако процесс идентичен для других Политик Роялти: Пример оплаты: IPA4 переводит IPA3 1 миллион USDC, вызывая функцию `payRoyaltyOnBehalf`. -1. Revenue Tokens flow to the Royalty Module contract. This contract then splits up the tokens based on the **royalty stack** on the receiving IPA. In this case, IPA3 has a royalty stack of 15%, so 850k tokens flow to IP Royalty Vault 3, and 150k tokens flow to the LAP contract. -Токены Дохода поступают в контракт Модуля Роялти, который распределяет их в соответствии со **стеком роялти** для получающего актива. Например, если стек роялти IPA3 составляет 15%, 850k USDC поступает в хранилище IPA3, а 150k – в контракт LAP. +1. Токены Дохода поступают в контракт Модуля Роялти, который распределяет их в соответствии со **стеком роялти** для получающего актива. Например, если стек роялти IPA3 составляет 15%, 850k USDC поступает в хранилище IPA3, а 150k – в контракт LAP. ![](https://files.readme.io/be5dfdf9064320904ca27bc1f12a2475456064a19049b7d8fb2500d094746e1d-image.png) @@ -69,10 +68,6 @@ This section will help explain how revenue flows from the time of payment to bei ### Внешние Политики Роялти -Revenue Tokens can also move from a vault to another vault via the functions `claimByTokenBatchAsSelf` located in the `IpRoyaltyVault.sol` contract. For this to be possible the vault that is claiming revenue tokens needs to own Royalty Tokens of the vault being claimed from. This can be particularly useful when used together with external royalty policies. - -Vaults can only claim from other vaults if those other vaults belong to IPs in the same derivative chain. If a vault owns royalty tokens from an IP but it is not an ancestor of that IP, it is not possible to claim rewards with those royalty tokens. - Токены Дохода могут перемещаться из одного хранилища в другое с помощью функции `claimByTokenBatchAsSelf`, находящейся в контракте `IpRoyaltyVault.sol`. Однако для этого хранилище, запрашивающее токены, должно владеть Токенами Роялти хранилища, из которого оно запрашивает доход. Это возможно только для хранилищ, принадлежащих активам в одной и той же цепочке производных. Если хранилище владеет Токенами Роялти актива, который не является его предком, получение дохода с этих токенов невозможно. \ No newline at end of file From 845bcb65fb50dbbd97ebd9c02bdd1088f033bef5 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Thu, 2 Jan 2025 16:00:16 +0300 Subject: [PATCH 08/10] spg + story_modules --- docs/Concepts/spg/batch-spg-function-calls.md | 109 +++++++++--------- docs/Concepts/spg/index.md | 76 ++++++------ docs/Concepts/story-modules/base-module.md | 22 ++-- docs/Concepts/story-modules/hooks.md | 31 ++--- 4 files changed, 120 insertions(+), 118 deletions(-) diff --git a/docs/Concepts/spg/batch-spg-function-calls.md b/docs/Concepts/spg/batch-spg-function-calls.md index 2a5564e..97b4aa1 100644 --- a/docs/Concepts/spg/batch-spg-function-calls.md +++ b/docs/Concepts/spg/batch-spg-function-calls.md @@ -1,5 +1,5 @@ --- -title: Batch Function Calls +title: Пакетные вызовы функций excerpt: '' deprecated: false hidden: false @@ -10,38 +10,38 @@ metadata: next: description: '' --- -## Background +## Предыстория -Prior to this point, registering multiple IPs or performing other operations such as minting, attaching licensing terms, and registering derivatives requires separate transactions for each operation. This can be inefficient and costly. To streamline the process, you can batch multiple transactions into a single one. Two solutions are now available for this: +До внедрения нового подхода регистрация нескольких объектов IP или выполнение других операций, таких как выпуск токенов, добавление лицензионных условий и регистрация производных, требовали отдельной транзакции для каждой операции. Это могло быть неэффективным и дорогостоящим. Для оптимизации процесса теперь доступно два способа объединения нескольких транзакций в одну: -1. **Batch SPG function calls:** Use [SPG’s built-in `multicall` function](https://docs.story.foundation/docs/batch-spg-function-calls#1-batch-spg-function-calls-via-built-in-multicall-function). -2. **Batch function calls beyond SPG:** Use the [Multicall3 Contract](https://docs.story.foundation/docs/batch-spg-function-calls#2-batch-function-calls-via-multicall3-contract). +1. **Пакетные вызовы функций SPG:** Используйте встроенную функцию [`multicall`](https://docs.story.foundation/docs/batch-spg-function-calls#1-batch-spg-function-calls-via-built-in-multicall-function). +2. **Пакетные вызовы функций за пределами SPG:** Используйте контракт [Multicall3](https://docs.story.foundation/docs/batch-spg-function-calls#2-batch-function-calls-via-multicall3-contract). *** -## 1. Batch SPG Function Calls via Built-in `multicall` Function +## 1. Пакетные вызовы функций SPG с использованием встроенной функции `multicall` -SPG includes a `multicall` function that allows you to combine multiple read or write operations into a single transaction. +SPG включает функцию `multicall`, которая позволяет объединить несколько операций чтения или записи в одну транзакцию. -### Function Definition +### Определение функции -The `multicall` function accepts an array of encoded call data and returns an array of encoded results corresponding to each function call: +Функция `multicall` принимает массив закодированных данных вызова и возвращает массив закодированных результатов, соответствующих каждому вызову функции: ```solidity -/// @dev Executes a batch of function calls on this contract. +/// @dev Выполняет пакетный вызов функций в этом контракте. function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results); ``` -### Example Usage +### Пример Использования -Suppose you want to mint multiple NFTs, register them as IPs, and link them as derivatives to some parent IPs. +Допустим, вы хотите выпустить несколько NFT, зарегистрировать их как IP и связать их с производными объектами IP. -To accomplish this, you can use SPG’s `multicall` function to batch the calls to the `mintAndRegisterIpAndMakeDerivative` function. +Для этого можно использовать функцию `multicall` SPG для пакетного вызова функции `mintAndRegisterIpAndMakeDerivative`. -Here’s how you might do it: +Пример использования: ```solidity -// an SPG workflow contract: https://github.com/storyprotocol/protocol-periphery-v1/blob/main/contracts/workflows/DerivativeWorkflows.sol +// контракт рабочего процесса SPG: https://github.com/storyprotocol/protocol-periphery-v1/blob/main/contracts/workflows/DerivativeWorkflows.sol contract DerivativeWorkflows { ... function mintAndRegisterIpAndMakeDerivative( @@ -56,10 +56,10 @@ contract DerivativeWorkflows { } ``` -To batch call `mintAndRegisterIpAndMakeDerivative` using the `multicall` function: +Пример пакетного вызова `mintAndRegisterIpAndMakeDerivative` с помощью функции `multicall`: ```javascript -// batch mint, register, and make derivatives for multiple IPs +// пакетное создание, регистрация и связывание производных для нескольких IP await DerivativeWorkflows.multicall([ DerivativeWorkflows.contract.methods.mintAndRegisterIpAndMakeDerivative( nftContract1, @@ -82,23 +82,23 @@ await DerivativeWorkflows.multicall([ ipMetadata3, ).encodeABI(), ... - // Add more calls as needed + // Добавьте больше вызовов по мере необходимости ]); ``` *** -## 2. Batch Function Calls via Multicall3 Contract +## 2. Пакетные вызовы функций через контракт Multicall3 -> 🚧 Warning +> 🚧 Важно > -> Note: The Multicall3 contract is not fully compatible with SPG functions that involve SPGNFT minting due to access control and context changes during Multicall execution. For such operations, use [SPG’s built-in multicall function.](https://docs.story.foundation/docs/batch-spg-function-calls#1-batch-spg-function-calls-via-built-in-multicall-function) +> Контракт Multicall3 не полностью совместим с функциями SPG, связанными с выпуском SPGNFT, из-за особенностей контроля доступа и изменения контекста во время выполнения Multicall. Для таких операций используйте встроенную функцию [multicall SPG](https://docs.story.foundation/docs/batch-spg-function-calls#1-batch-spg-function-calls-via-built-in-multicall-function). -The Multicall3 contract allows you to execute multiple calls within a single transaction and aggregate the results. The [`viem` library](https://viem.sh/docs/contract/multicall#multicall) provides native support for Multicall3. +Контракт Multicall3 позволяет выполнить несколько вызовов функций в рамках одной транзакции и агрегировать результаты. Библиотека [`viem`](https://viem.sh/docs/contract/multicall#multicall) поддерживает Multicall3 на нативном уровне. -### Story Odyssey Testnet Multicall3 Deployment Info +### Информация о развертывании Multicall3 в тестовой сети Story Odyssey -(Same address across all EVM chains) +(Один и тот же адрес на всех сетях EVM) ```json { @@ -109,70 +109,71 @@ The Multicall3 contract allows you to execute multiple calls within a single tra } ``` -### Main Functions +### Основные функции -To batch multiple function calls, you can use the following functions: +Для пакетного вызова функций используйте следующие функции: -1. **`aggregate3`**: Batches calls using the `Call3` struct. -2. **`aggregate3Value`**: Similar to `aggregate3`, but also allows attaching a value to each call. +1.**` aggregate3`**: Выполняет пакетный вызов с использованием структуры Call3. +2. **`aggregate3Value`**: Аналогична `aggregate3`, но позволяет также прикреплять значение к каждому вызову. ```solidity -/// @notice Aggregate calls, ensuring each returns success if required. -/// @param calls An array of Call3 structs. -/// @return returnData An array of Result structs. +/// @notice Агрегирует вызовы, обеспечивая успех каждого, если это требуется. +/// @param calls Массив структур Call3. +/// @return returnData Массив структур Result. function aggregate3(Call3[] calldata calls) external payable returns (Result[] memory returnData); -/// @notice Aggregate calls with an attached msg value. -/// @param calls An array of Call3Value structs. -/// @return returnData An array of Result structs. +/// @notice Агрегирует вызовы с прикрепленным значением msg. +/// @param calls Массив структур Call3Value. +/// @return returnData Массив структур Result. function aggregate3Value(Call3Value[] calldata calls) external payable returns (Result[] memory returnData); ``` -### Struct Definitions +### Определения структур -* **Call3**: Used in `aggregate3`. -* **Call3Value**: Used in `aggregate3Value`. + +* **Call3**: Используется в `aggregate3`. +* **Call3Value**: Используется в `aggregate3Value`. ```solidity struct Call3 { - address target; // Target contract to call. - bool allowFailure; // If false, the multicall will revert if this call fails. - bytes callData; // Data to call on the target contract. + address target; // Адрес вызываемого контракта. + bool allowFailure; // Если false, вызов Multicall завершится неудачей при ошибке. + bytes callData; // Данные для вызова контракта. } struct Call3Value { address target; bool allowFailure; - uint256 value; // Value (in wei) to send with the call. - bytes callData; // Data to call on the target contract. + uint256 value; // Значение (в wei), отправляемое с вызовом. + bytes callData; // Данные для вызова контракта. } ``` -### Return Type +### Тип возвращаемого значения -* **Result**: Struct returned by both `aggregate3` and `aggregate3Value`. +* **Result**: Структура возвращаемая `aggregate3` и `aggregate3Value`. ```solidity struct Result { - bool success; // Whether the function call succeeded. - bytes returnData; // Data returned from the function call. + bool success; // Успешность вызова. + bytes returnData; // Данные, возвращаемые функцией. } ``` -> 📘 Examples +> 📘 Примеры > -> For detailed examples in Solidity, TypeScript, and Python, see the [Multicall3 repository](https://github.com/mds1/multicall/tree/main/examples). +> Для подробных примеров на Solidity, TypeScript и Python, см. [репозиторий Multicall3](https://github.com/mds1/multicall/tree/main/examples). -### Limitations +### Ограничения -For a list of limitations when using Multicall3, refer to the [Multicall3 README](https://github.com/mds1/multicall/blob/main/README.md#batch-contract-writes). +Список ограничений при использовании Multicall3 доступен в [Multicall3 README](https://github.com/mds1/multicall/blob/main/README.md#batch-contract-writes). -### Additional Resources +### Дополнительные ресурсы -* [Multicall3 Documentation](https://github.com/mds1/multicall/blob/main/README.md) -* [Multicall Documentation from Viem](https://viem.sh/docs/contract/multicall#multicall) +* [Документация Multicall3](https://github.com/mds1/multicall/blob/main/README.md) +* [Документация Multicall от Viem](https://viem.sh/docs/contract/multicall#multicall) -### Full Multicall3 Interface +### Полный интерфейс Multicall3 ```solidity interface IMulticall3 { diff --git a/docs/Concepts/spg/index.md b/docs/Concepts/spg/index.md index 234e592..74bb80a 100644 --- a/docs/Concepts/spg/index.md +++ b/docs/Concepts/spg/index.md @@ -1,5 +1,5 @@ --- -title: 📦 SPG +title: 📦 Протоколный шлюз Story (SPG) excerpt: '' deprecated: false hidden: false @@ -10,13 +10,13 @@ metadata: next: description: '' --- -The Story Protocol Gateway (SPG) is a group of periphery/utility smart contracts, deployed on our protocol that **allows you to combine independent operations** - like registering an [🧩 IP Asset](doc:ip-asset) and attaching License Terms to that IP Asset - **into one transaction to make your life easier**. +SPG (Story Protocol Gateway) — это набор периферийных/утилитарных смарт-контрактов, развернутых в рамках нашего протокола. Они позволяют **объединять независимые операции** (например, регистрацию [🧩 IP-актива](doc:ip-asset) и прикрепление лицензионных условий к этому IP-активу) **в одну транзакцию для упрощения процесса**. -> 🗒️ Contracts +> 🗒️ Контракты > -> View the smart contracts [here](https://github.com/storyprotocol/protocol-periphery-v1/tree/main/contracts). +> Ознакомьтесь со смарт-контрактами [тут](https://github.com/storyprotocol/protocol-periphery-v1/tree/main/contracts). -For example, this `mintAndRegisterIpAndAttachPILTerms` is one of the functions in the SPG (more specifically in the "License Attachment Workflows") that allows you to mint an NFT, register it as an IP Asset, and attach License Terms to it all in one call: +Функция `mintAndRegisterIpAndAttachPILTerms`, являющаяся частью SPG (в частности, "Workflow для прикрепления лицензий"), позволяет в одной транзакции создать NFT, зарегистрировать его как IP-актив и прикрепить к нему лицензионные условия. ```sol LicenseAttachmentWorkflows.sol function mintAndRegisterIpAndAttachPILTerms( @@ -27,53 +27,53 @@ function mintAndRegisterIpAndAttachPILTerms( ) external onlyCallerWithMinterRole(nftContract) returns (address ipId, uint256 tokenId, uint256 licenseTermsId) ``` -## Supported Workflows +## Поддерживаемые Workflow -As mentioned above, there are many different functions we have created for you that combine multiple functions into one. Because we have created many of them, we have categorized them into different groups. These groups are called "workflows". +В SPG реализовано множество функций, которые объединяют несколько операций в одну. Для удобства они разделены на категории, называемые "Workflow". -> 📘 Below Workflow Docs +> 📘 Документация Workflow > -> The below docs on the supported workflows is a copy + paste of [this document](https://github.com/storyprotocol/protocol-periphery-v1/blob/main/docs/WORKFLOWS.md). While we will try to keep the below list up to date, you can always go there for the latest version. +> Приведенный ниже список Workflow — это копия [этого документа](https://github.com/storyprotocol/protocol-periphery-v1/blob/main/docs/WORKFLOWS.md). Мы будем стараться поддерживать его актуальность, однако для последней версии обращайтесь к оригинальному документу. -### [Registration Workflows](../contracts/interfaces/workflows/IRegistrationWorkflows.sol) +### [Workflow для регистрации](../contracts/interfaces/workflows/IRegistrationWorkflows.sol) -* `createCollection`: Creates a SPGNFT Collection -* `registerIp`: Registers an IP -* `mintAndRegisterIp`: Mints a NFT → Registers it as an IP +* `createCollection`: Создание коллекции SPGNFT. +* `registerIp`: Регистрация IP-актива. +* `mintAndRegisterIp`: Создание NFT → Регистрация его как IP-актива. -### [License Attachment Workflows](../contracts/interfaces/workflows/ILicenseAttachmentWorkflows.sol) +### [Workflow для прикрепления лицензии](../contracts/interfaces/workflows/ILicenseAttachmentWorkflows.sol) -* `registerPILTermsAndAttach`: Registers PIL terms → Attaches them to an IP -* `registerIpAndAttachPILTerms`: Registers an IP → Registers PIL terms → Attaches them to the IP -* `mintAndRegisterIpAndAttachPILTerms`: Mints a NFT → Registers it as an IP → Registers PIL terms → Attaches them to the IP +* `registerPILTermsAndAttach`: Регистрация PIL-условий → Прикрепление их к IP. +* `registerIpAndAttachPILTerms`: Регистрация IP → Регистрация PIL-условий → Прикрепление их к IP. +* `mintAndRegisterIpAndAttachPILTerms`: Создание NFT → Регистрация его как IP → Регистрация PIL-условий → Прикрепление их к IP. -### [Derivative Workflows](../contracts/interfaces/workflows/IDerivativeWorkflows.sol) +### [Workflow для производных активов](../contracts/interfaces/workflows/IDerivativeWorkflows.sol) -* `registerIpAndMakeDerivative`: Registers an IP → Registers it as a derivative of another IP -* `mintAndRegisterIpAndMakeDerivative`: Mints a NFT → Registers it as an IP → Registers the IP as a derivative of another IP -* `registerIpAndMakeDerivativeWithLicenseTokens`: Registers an IP → Registers the IP as a derivative of another IP using the license tokens -* `mintAndRegisterIpAndMakeDerivativeWithLicenseTokens`: Mints a NFT → Registers it as an IP → Registers the IP as a derivative of another IP using the license tokens +* `registerIpAndMakeDerivative`: Регистрация IP → Определение его как производного от другого IP. +* `mintAndRegisterIpAndMakeDerivative`: Создание NFT → Регистрация его как IP → Определение его как производного от другого IP. +* `registerIpAndMakeDerivativeWithLicenseTokens`: Регистрация IP → Определение его как производного с использованием лицензионных токенов. +* `mintAndRegisterIpAndMakeDerivativeWithLicenseTokens`: Создание NFT → Регистрация его как IP → Определение его как производного с использованием лицензионных токенов. -### [Grouping Workflows](../contracts/interfaces/workflows/IGroupingWorkflows.sol) +### [Workflow для группировки](../contracts/interfaces/workflows/IGroupingWorkflows.sol) -* `mintAndRegisterIpAndAttachLicenseAndAddToGroup`: Mints a NFT → Registers it as an IP → Attaches the given license terms to the IP → Adds the IP to a group IP -* `registerIpAndAttachLicenseAndAddToGroup`: Registers an IP → Attaches the given license terms to the IP → Adds the IP to a group IP -* `registerGroupAndAttachLicense`: Registers a group IP → Attaches the given license terms to the group IP +* `mintAndRegisterIpAndAttachLicenseAndAddToGroup`: Создание NFT → Регистрация его как IP → Прикрепление лицензионных условий → Добавление в группу IP. +* `registerIpAndAttachLicenseAndAddToGroup`: Регистрация IP → Прикрепление лицензионных условий → Добавление в группу IP. +* `registerGroupAndAttachLicense`: Регистрация группы IP → Прикрепление лицензионных условий к группе. * `registerGroupAndAttachLicenseAndAddIps`: Registers a group IP → Attaches the given license terms to the group IP → Adds existing IPs to the group IP -### [Royalty Workflows](../contracts/interfaces/workflows/IRoyaltyWorkflows.sol) +### [Workflow для роялти](../contracts/interfaces/workflows/IRoyaltyWorkflows.sol) -* `transferToVaultAndSnapshotAndClaimByTokenBatch`: Transfers revenue tokens to ancestor IP’s royalty vault → Takes a snapshot of the royalty vault → Claims all available revenue tokens from the snapshot to the claimer’s wallet - * *Use Case*: For IP royalty token holders who want to claim both their direct revenue and royalties from descendant IPs. -* `transferToVaultAndSnapshotAndClaimBySnapshotBatch`: Transfers revenue tokens to ancestor IP’s royalty vault → Takes a snapshot of the royalty vault → Claims all available revenue tokens from the new snapshot to the claimer’s wallet → Claims all available revenue tokens from each provided unclaimed snapshot to the claimer’s wallet - * *Use Case*: For IP royalty token holders who want to claim both direct revenue and descendant royalties from the latest snapshot and previously taken snapshots. -* `snapshotAndClaimByTokenBatch`: Takes a snapshot of the royalty vault → Claims all available revenue tokens from the new snapshot to the claimer’s wallet - * *Use Case*: For IP royalty token holders who want to claim the current revenue in their IP’s royalty vault (which may or may not include descendant royalties). -* `snapshotAndClaimBySnapshotBatch`: Takes a snapshot of the royalty vault → Claims all available revenue tokens from the new snapshot to the claimer’s wallet → Claims all available revenue tokens from each provided unclaimed snapshot to the claimer’s wallet - * *Use Case*: For IP royalty token holders who want to claim the current revenue in their IP’s royalty vault from the latest snapshot and previously taken snapshots. +* `transferToVaultAndSnapshotAndClaimByTokenBatch`: Перевод доходных токенов в хранилище роялти IP → Создание снимка хранилища → Вывод доходов и роялти потомков IP. + * *Применение*: Для владельцев роялти-токенов, которые хотят вывести доходы и роялти от потомков. +* `transferToVaultAndSnapshotAndClaimBySnapshotBatch`: Перевод токенов → Создание нового снимка → Вывод текущих доходов и доходов из предыдущих снимков. + * *Применение*: Для владельцев роялти, которые хотят получить доходы за текущий и прошлые периоды. +* `snapshotAndClaimByTokenBatch`: Создание снимка (снепшота) → Вывод текущих доходов. + * *Применение*: Для владельцев роялти, которые хотят получить текущий доход. +* `snapshotAndClaimBySnapshotBatch`: Создание снимка → Вывод доходов за текущий и предыдущие периоды. + * *Применение*: Для владельцев роялти, желающих получить доходы за все периоды. -## Batching Calls +## Объединение вызовов -Although the SPG contains certain functions like `mintAndRegisterIpAndAttachPILTerms`, `registerIpAndAttachPILTerms`, and a bunch more, it would be tedious for us to continually update the contract to account for every single combination of possible interactions with an IP Asset. +Несмотря на наличие функций, таких как `mintAndRegisterIpAndAttachPILTerms`и `registerIpAndAttachPILTerms`, их комбинации могут быть ограничены. Чтобы обеспечить максимальную гибкость, SPG предоставляет механизм "Multicall", позволяющий группировать вызовы в одну транзакцию. -Instead, we have allowed for a "Multicall" mechanism where you can batch transactions how you like. For more info, see [Batch Function Calls](doc:batch-spg-function-calls). +Подробнее про "Multicall" [Пакетные вызовы функций](doc:batch-spg-function-calls). diff --git a/docs/Concepts/story-modules/base-module.md b/docs/Concepts/story-modules/base-module.md index f82bb7e..a40382d 100644 --- a/docs/Concepts/story-modules/base-module.md +++ b/docs/Concepts/story-modules/base-module.md @@ -1,5 +1,5 @@ --- -title: Base Module +title: Базовый Модуль excerpt: '' deprecated: false hidden: false @@ -10,21 +10,21 @@ metadata: next: description: '' --- -The Base Module provides a standard set of must-have functionalities for all modules registered on Story Protocol. Anyone wishing to create and register a module on Story Protocol must inherit and override the Base Module. +Базовый Модуль предоставляет стандартный набор обязательных функций для всех модулей, зарегистрированных в Story Protocol. Любой, кто хочет создать и зарегистрировать модуль в Story Protocol, должен унаследовать и переопределить Базовый Модуль. -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/BaseModule.sol). +> Ознакомьтесь со смарт-контрактом [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/BaseModule.sol). -# Key Features +# Отличительные черты -## Simplicity and Flexibility +## Простота и гибкость -The BaseModule is intentionally kept simple and generalized. It only implements the ERC165 interface, which is crucial for interface detection. This design choice allows for maximum flexibility when developing more specific modules within the Story Protocol. +BaseModule намеренно создан простым и обобщенным. Он реализует только интерфейс ERC165, который необходим для определения интерфейсов. Такой подход обеспечивает максимальную гибкость при разработке более специализированных модулей в рамках Story Protocol. -## ERC165 Interface Implementation +## Реализация интерфейса ERC165 -By implementing the ERC165 interface, BaseModule allows other contracts to query whether it supports a specific interface. This feature is essential for ensuring compatibility and interoperability within the Story Protocol ecosystem and beyond. +Реализуя интерфейс ERC165, BaseModule позволяет другим контрактам проверять, поддерживает ли он определенный интерфейс. Эта функция важна для обеспечения совместимости и взаимодействия внутри экосистемы Story Protocol и за ее пределами. ```sol BaseModule.sol abstract contract BaseModule is ERC165, IModule { @@ -32,9 +32,9 @@ abstract contract BaseModule is ERC165, IModule { } ``` -## `supportsInterface` Function +## Функция `supportsInterface` -A key function in the BaseModule is `supportsInterface`, which overrides the ERC165's `supportsInterface` method. This function is crucial for interface detection, allowing the contract to declare support for both its own `IModule` interface and any other interfaces it might inherit. +Ключевая функция в BaseModule — это `supportsInterface`, которая переопределяет метод `supportsInterface` из ERC165. Эта функция играет важную роль в определении интерфейсов, позволяя контракту заявлять о поддержке как собственного интерфейса `IModule`, так и любых других интерфейсов, которые он может наследовать. ```sol BaseModule.sol function supportsInterface(bytes4 interfaceId) public view virtual override(ERC165, IERC165) returns (bool) { diff --git a/docs/Concepts/story-modules/hooks.md b/docs/Concepts/story-modules/hooks.md index 1a6c21f..ab9c09f 100644 --- a/docs/Concepts/story-modules/hooks.md +++ b/docs/Concepts/story-modules/hooks.md @@ -1,30 +1,31 @@ --- -title: Hooks -excerpt: Introduction of hooks in Story Protocol +title: Хуки +excerpt: Введение в Хуки в Story Protocol deprecated: false hidden: false metadata: - title: '' - description: '' + title: "" + description: "" robots: index next: - description: '' + description: "" --- -# Overview -Hooks in Story Protocol are defined as a specialized interface that inherits from the Module framework. They are designed for developers to create custom implementations that integrate seamlessly with existing Modules. +# Обзор + +Хуки в Story Protocol определяются как специализированный интерфейс, который наследуется от фреймворка Module. Они предназначены для того, чтобы разработчики могли создавать индивидуальные реализации, которые легко интегрируются с уже существующими модулями. -# Concept and Functionality +# Концепция и функциональность -While Modules are the backbone of the Story Protocol, executing actions and managing interactions, Hooks are distinct in their specific focus. They are tailored to verify conditions, an essential feature embodied in their `verify()` functionality. This design choice positions Hooks as a unique subset of Modules, specialized for particular tasks within the ecosystem. +В то время как Модули являются основой Story Protocol, выполняя действия и управляя взаимодействиями, хуки отличаются своей узкой специализацией. Они предназначены для проверки условий, что особенно важно благодаря их функции `verify()`. Этот подход делает хуки уникальным подмножеством модулей, специально разработанных для выполнения определённых задач в экосистеме. -# Design Philosophy +# Философия проектирования -From a structural standpoint, Hooks are not treated as separate entities from Modules. This decision avoids unnecessary complexity in the architecture. Viewing Hooks as specialized Modules allows for a simplified, efficient design that emphasizes clarity in roles and interactions. +С точки зрения структуры, хуки не рассматриваются как отдельные сущности от модулей. Это позволяет избежать излишней сложности архитектуры. Рассматривая хуки как специализированные модули, удаётся создать простую и эффективную систему, в которой роли и взаимодействия максимально ясны. -# Sample Token Gated Hook Module +# Пример: Хук для проверки доступа на основе токенов ```coffeescript pragma solidity 0.8.23; @@ -36,7 +37,7 @@ import { IHookModule } from "../../../contracts/interfaces/modules/base/IHookMod import { BaseModule } from "../../../contracts/modules/BaseModule.sol"; /// @title Token Gated Hook. -/// @notice Hook for ensursing caller is the owner of an NFT token. +/// @notice Хук для проверки, является ли вызывающий адрес владельцем NFT. contract TokenGatedHook is BaseModule, IHookModule { using ERC165Checker for address; @@ -65,7 +66,7 @@ contract TokenGatedHook is BaseModule, IHookModule { ``` -Using The `TokenGatedHook` as `commercializerChecker` with `LicensingModule` for use case that only allow mint license to licensee who own a specific NFT token. +Модуль `TokenGatedHook` может применяться в качестве `commercializerChecker` в LicensingModule (Модуль Лицензирования). В данном случае он позволяет выдавать лицензию только тем, кто владеет определённым токеном NFT. ``` licensingModule.registerPolicyFrameworkManager(address(pilManager)); @@ -90,7 +91,7 @@ Using The `TokenGatedHook` as `commercializerChecker` with `LicensingModule` for MockTokenGatedHook tokenGatedHook = new MockTokenGatedHook(); policyData.commercializerChecker = address(tokenGatedHook); - // address(this) doesn't hold token of NFT collection gatedNftBar, so the verification will fail + // address(this) не владеет токеном из коллекции gatedNftBar, поэтому проверка не будет пройдена. policyData.commercializerCheckerData = abi.encode(address(gatedNftBar)); policyData.territories[0] = "territory1"; policyData.distributionChannels[0] = "distributionChannel1"; From 88d6cd25bcb51342633cc196931a82d07f3e1c53 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Thu, 2 Jan 2025 16:58:55 +0300 Subject: [PATCH 09/10] story-modules done --- .../how-to-create-and-register-modules.md | 34 ++++++++++--------- docs/Concepts/story-modules/index.md | 24 +++++++------ docs/Concepts/story-modules/view-module.md | 18 +++++----- 3 files changed, 40 insertions(+), 36 deletions(-) diff --git a/docs/Concepts/story-modules/how-to-create-and-register-modules.md b/docs/Concepts/story-modules/how-to-create-and-register-modules.md index fe53b3d..26976e2 100644 --- a/docs/Concepts/story-modules/how-to-create-and-register-modules.md +++ b/docs/Concepts/story-modules/how-to-create-and-register-modules.md @@ -1,5 +1,5 @@ --- -title: How to Create and Register Modules +title: Создание и Регистрация Модулей excerpt: '' deprecated: false hidden: false @@ -10,13 +10,15 @@ metadata: next: description: '' --- -This guide will walk you through the process of creating a Module and registering it with the Story Protocol, enabling you to contribute to its ecosystem. +Это руководство проведет вас через процесс создания модуля и его регистрации в Story Protocol, чтобы вы могли внести свой вклад в экосистему. -# How to Create a Module -Creating a module is straightforward. You need to develop a contract and implement the `IModule` interface. While inheriting from `BaseModule` is recommended for convenience, it's not mandatory. +# Как создать Модуль -Below is an example of how to create a HookModule: + +Создание модуля довольно простое. Вам нужно разработать смарт-контракт и реализовать интерфейс `IModule`. Рекомендуется наследоваться от `BaseModule` для удобства, но это не обязательно. + +Ниже приведен пример создания HookModule (модуля хука): ```sol TokenGatedHook.sol // SPDX-License-Identifier: MIT @@ -29,7 +31,7 @@ import { IHookModule } from "contracts/interfaces/modules/base/IHookModule.sol"; import { BaseModule } from "contracts/modules/BaseModule.sol"; /// @title Mock Token Gated Hook. -/// @notice Hook for ensursing caller is the owner of an NFT token. +/// @notice Хук, проверяющий, является ли вызывающий адрес владельцем NFT. contract TokenGatedHook is BaseModule, IHookModule { using ERC165Checker for address; @@ -58,16 +60,16 @@ contract TokenGatedHook is BaseModule, IHookModule { ``` -# How to Register Your Module +# Как зарегистрировать ваш Модуль -After creating your module, the next step is to register it with the Story Protocol to make it available within its ecosystem. We have established a public GitHub repository at [here](https://github.com/storyprotocol/registered-modules) to facilitate the submission process. You are invited to register your module here. The Story Protocol team will conduct a thorough review of your submission. This process ensures that only safe and compliant modules are integrated into the ecosystem. +После создания модуля следующим шагом будет его регистрация в Story Protocol, чтобы он стал доступен в экосистеме. Мы создали публичный репозиторий на GitHub для удобства подачи заявок [тут](https://github.com/storyprotocol/registered-modules). Вы можете зарегистрировать свой модуль здесь. Перед интеграцией в экосистему команда Story Protocol проведет тщательную проверку вашей заявки, чтобы убедиться, что ваш модуль безопасен и соответствует стандартам. -## Steps to Register Your Module +## Шаги для регистрации Модуля -To get your module verified and listed in this repository, please follow these steps: +Чтобы ваш модуль был проверен и добавлен в репозиторий, выполните следующие шаги: -1. **Fork this[Repository](https://github.com/storyprotocol/registered-modules):** Begin by forking this repository to your own GitHub account. -2. **Update the Module List:** Add your module's details to the appropriate JSON file according to module types in the repository. Ensure that you adhere to the following JSON structure: +1. **Сделайте форк [Репозитория](https://github.com/storyprotocol/registered-modules):** Сначала сделайте форк этого репозитория в своем аккаунте GitHub. +2. **Обновите список модулей:** Добавьте информацию о вашем модуле в соответствующий JSON-файл в репозитории, соблюдая следующую структуру: ```json @@ -78,7 +80,7 @@ To get your module verified and listed in this repository, please follow these s } ``` -* Replace `YourModuleName`, `YourModuleAddress`, and `YourModuleBlockExplorerLink` with your module's name, its address, and the link to its block explorer page, respectively. +* Замените `YourModuleName`, `YourModuleAddress`, и `YourModuleBlockExplorerLink` на название вашего модуля, его адрес и ссылку на его страницу в блокчейн-эксплорере. * Example: ```json json @@ -89,7 +91,7 @@ To get your module verified and listed in this repository, please follow these s } ``` -3. **Create a Pull Request (PR)**: Once you have added your module, create a pull request against this repository. Utilize the provided PR template to ensure all necessary information is included. -4. **Await Verification:** After your PR is submitted, it will be reviewed. Upon approval and merging of your PR, your module will be officially registered and recognized as safe for use within the StoryProtocol community. +3. **Создайте Pull Request (PR)**: После того как вы добавите свой модуль, создайте pull request (PR) в этот репозиторий. Используйте предоставленный шаблон PR, чтобы включить всю необходимую информацию. +4. **Ожидайте проверки:** После того как ваш PR будет подан, его проверят. После утверждения и слияния PR, ваш модуль будет официально зарегистрирован и признан безопасным для использования в сообществе Story Protocol. -We look forward to seeing your contributions and expanding the StoryProtocol module ecosystem! +Мы с нетерпением ждем ваших вкладов и расширения экосистемы модулей Story Protocol! 😊 diff --git a/docs/Concepts/story-modules/index.md b/docs/Concepts/story-modules/index.md index c8cbdf4..8cb21e2 100644 --- a/docs/Concepts/story-modules/index.md +++ b/docs/Concepts/story-modules/index.md @@ -1,5 +1,5 @@ --- -title: 🧱 Modules +title: 🧱 Модули excerpt: '' deprecated: false hidden: false @@ -12,22 +12,24 @@ next: --- Modules are standalone contracts that adhere to the [`IModule` interface](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/base/IModule.sol). These modules play a crucial role in taking action on IP to change the data/state around or of IP. -# Existing Modules +Модули — это независимые контракты, которые соответствуют [интерфейсу `IModule`](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/interfaces/modules/base/IModule.sol). Эти модули играют ключевую роль в выполнении действий с интеллектуальной собственностью (IP), изменяя данные/состояние, связанные с ней или её частью. -There are a few important modules, created by the Story team, to be aware of: +# Существующие Модули -## [📜 Licensing Module](doc:licensing-module) +Существует несколько важных модулей, созданных командой Story, с которыми стоит ознакомиться: -Responsible for defining and attaching licenses to IP Assets. +## [📜 Модуль Лицензирования](doc:licensing-module) -## [💸 Royalty Module](doc:royalty-module) +Отвечает за определение и привязку лицензий к IP-активам. -Responsible for handling royalty flow between parent & child IP Assets. +## [💸 Модуль Роялти](doc:royalty-module) -## [❌ Dispute Module](doc:dispute-module) +Отвечает за управление потоком роялти между родительскими и дочерними IP-активами. -Responsible for handling the dispute of wrongfully registered or misbehaved IP Assets. +## [❌ Модуль Споров](doc:dispute-module) -## [👥 Grouping Module](doc:grouping-module) +Отвечает за обработку споров по неправомерно зарегистрированным или неправомерно использованным IP-активам. -Responsible for handling groups of IPAs. +## [👥 Модуль Группировки](doc:grouping-module) + +Отвечает за управление группами IP-активов. diff --git a/docs/Concepts/story-modules/view-module.md b/docs/Concepts/story-modules/view-module.md index 0eb88ac..67660d4 100644 --- a/docs/Concepts/story-modules/view-module.md +++ b/docs/Concepts/story-modules/view-module.md @@ -1,5 +1,5 @@ --- -title: View Module +title: Модуль Просмотра excerpt: '' deprecated: false hidden: true @@ -10,20 +10,20 @@ metadata: next: description: '' --- -# Overview +# Обзор -The View Module, inheriting from the Module in Story Protocol, is designed for interpreting and displaying IP data. Its primary role is to function as a read-only module, focusing on the presentation of IP-related data in various accessible formats. +Модуль Просмотра, наследующий от Модуля в Story Protocol, предназначен для интерпретации и отображения данных об интеллектуальной собственности (IP). Его основная роль — функционировать как модуль только для чтения, сосредотачиваясь на представлении данных, связанных с IP, в различных доступных форматах. -# Design +# Структура -The View Module is uniquely tailored to aggregate data from multiple namespaces within an IPAccount. This design enables it to present a comprehensive view of an IP, encompassing different data types and sources. It is structured to prioritize interpretability and user-friendly display of information. +Модуль просмотра уникально настроен для агрегирования данных из нескольких пространств имен в IP-аккаунте. Такой подход позволяет предоставить комплексный обзор IP, охватывающий различные типы данных и источники. Структура модуля ориентирована на приоритет интерпретируемости и удобства отображения информации. -# Use Cases Example +# Примеры использования -* **Core Metadata Immutability:**Utilizes CoreMetadataModule to ensure the immutability of core IP metadata. -* **User-Defined Metadata:** Employs UserMetadataModule for new metadata additions and UserMetadataViewModule for reading and showcasing data from Core and User Metadata. -* **Metadata Upgrade/Migration:** Focuses on seamless data evolution with MetadataModuleV2 and MetadataViewModuleV2, combining information from original and upgraded metadata sources without the need for migration. +* **Неизменность основных метаданных::** Использует CoreMetadataModule для обеспечения неизменности основных метаданных IP. +* **Пользовательские метаданные:** Использует UserMetadataModule для добавления новых метаданных и UserMetadataViewModule для чтения и отображения данных из основных и пользовательских метаданных. +* **Обновление/миграция метаданных:** Ориентирован на плавное обновление данных с помощью MetadataModuleV2 и MetadataViewModuleV2, комбинируя информацию из оригинальных и обновленных источников метаданных без необходимости миграции. \ No newline at end of file From 07765d6930ab4e384523a2efdef51d26bb38c718 Mon Sep 17 00:00:00 2001 From: stepaks675 Date: Fri, 3 Jan 2025 00:08:29 +0300 Subject: [PATCH 10/10] finished concepts --- docs/Concepts/access-controller.md | 79 +++++++++++++++--------------- docs/Concepts/concepts-faq.md | 49 +++++++++--------- docs/Concepts/grouping-module.md | 67 +++++++++++++------------ docs/Concepts/ip-account.md | 16 +++--- 4 files changed, 109 insertions(+), 102 deletions(-) diff --git a/docs/Concepts/access-controller.md b/docs/Concepts/access-controller.md index 0b098bc..d06897c 100644 --- a/docs/Concepts/access-controller.md +++ b/docs/Concepts/access-controller.md @@ -1,5 +1,5 @@ --- -title: 🔒 Access Controller +title: 🔒 Контроллер Доступа excerpt: '' deprecated: false hidden: false @@ -12,11 +12,11 @@ next: --- -Access Controller manages all permission-related states and permission checks in Story Protocol. In particular, it maintains the *Permission Table* and *Permission Engine* to process and store permissions. IPAccount permissions are set by the IPAccount owner. +Контроллер доступа управляет всеми состояниями и проверками разрешений в Story Protocol. В частности, он поддерживает *таблицу разрешений* и *движок разрешений* для обработки и хранения прав. Разрешения IPAccount устанавливаются владельцем IPAccount. -## Permission Table +## Таблица разрешений -### Permission Record +### Журнал Разрешений | IPAccount | Signer (caller) | To (only module) | Function Sig | Permission | | ---------- | --------------- | ---------------- | ------------ | ---------- | @@ -24,15 +24,13 @@ Access Controller manages all permission-related states and permission checks in | 0x123..111 | 0x789..222 | 0x790..333 | 0xBBBBBBBB | Deny | | 0x123..111 | 0x789..222 | 0x790..333 | 0xCCCCCC | Abstain | -Each record defines a permission in the form of the **Signer** (caller) calling the **Func** of the **To** (module) on behalf of the **IPAccount**. +Каждая запись определяет разрешение (**Permission**) в виде вызвавшего адреса (**Signer**), который вызывает функцию (**Func**) модуля (**To**) от имени IPAccount. -The permission field can be set as "Allow," "Deny," or "Abstain." Abstain indicates that the permission decision is determined by the upper-level permission. +Поле разрешения может быть установлено как: "Allow," "Deny," или "Abstain." Abstain - воздержаться (решение о разрешении принимается на уровне выше). -### Wildcard +### Поддержка универсальных шаблонов (Wildcard) -Wildcard is also supported when defining permissions; it defines a permission that applies to multiple modules and/or functions. - -With wildcards, users can easily define a whitelist or blacklist of permissions. +Шаблоны разрешений (wildcards) позволяют определить права, применимые сразу к нескольким модулям и/или функциям. Это упрощает создание списков разрешений (whitelist) или запрещений (blacklist). @@ -106,20 +104,22 @@ With wildcards, users can easily define a whitelist or blacklist of permissions.
-The above example shows that the signer (0x789...) is unable to invoke any functions of the module (0x790...) on behalf of the IPAccount (0x123...). +В примере (0x789..222) не может вызывать функции модуля (0x790..333) от имени IPAccount (0x123..111). + +Другими словами, IPAccount запретил адресу вызов функций в модуле 0x790...333 -In other words, the IPAccount has blacklisted the signer from calling any functions on the module 0x790...333 -* Supported wildcards: +* Поддерживаемые универсальные шаблоны: -| Parameter | Wildcard | +| Параметр | Шаблон | | -------------------------- | ---------- | | Func | bytes4(0) | | Addresses (IPAccount / To) | address(0) | -### Permission Prioritization +### Приоритет разрешений + +Более конкретные разрешения имеют приоритет над общими. -Specific permissions override general permissions. @@ -215,28 +215,29 @@ Specific permissions override general permissions.
-The above shows that the signer (0x789...) is not allowed to call any functions of the module (0x790...) on behalf of IPAccount (0x123...), except for the function 0xCCCCDDDD +Пример показывает что (0x789..222) не может вызывать функции модуля (0x790..333), кроме функции 0xCCCCDDDD. + +Однако, (0x789..222) может вызывать любые функции других модулей от имени IPAccount (0x123..111). -Furthermore, the signer (0x789...) is permitted to call all other modules on behalf of IPAccount (0x123...).
-## Call Flows with Access Control +## Потоки вызовов с контролем доступа -There exist three types of call flows expected by the Access Controller. +Существует три типа потоков вызовов, которые проверяются Контроллером доступа: -1. An IPAccount calls a module directly. -2. A module calls another module directly. -3. A module calls a registry directly. +1. IPAccount вызывает модуль напрямую. +2. Модуль вызывает другой модуль. +3. Модуль вызывает реестр. -### IPAccount calling a Module directly +### IPAccount вызывает модуль напрямую -* IPAccount performs a permission check with the Access Controller. -* The module only needs to check if the `msg.sender` is a valid IPAccount. +* IPAccount проверяет разрешения через Контроллер Доступа. +* Модуль проверяет только, является ли `msg.sender` валидным IPAccount. When calling a module from an IPAccount, the IPAccount performs an access control check with AccessController to determine if the current caller has permission to make the call. In the module, it only needs to check whether the transaction `msg.sender` is a valid IPAccount. -`AccessControlled` provide a modifier `onlyIpAccount()` helps to perform the access control check. +`AccessControlled` предоставляет метод `onlyIpAccount()` который помогает проверить доступ. ```solidity Solidity contract MockModule is IModule, AccessControlled { @@ -248,13 +249,13 @@ contract MockModule is IModule, AccessControlled { -## Module calling another Module +## Модуль вызывает другой модуль -* The callee module needs to perform the authorization check itself. +* Модуль, который вызывает другой модуль, должен выполнить проверку доступа самостоятельно. -When a module is called directly from another module, it is responsible for performing the access control check using AccessController. This check determines whether the current caller has permission to make the call to the module. +Когда модуль вызывает другой модуль, он отвечает за проверку контроля доступа через Контроллер Доступа. Эта проверка определяет, имеет ли текущий вызывающий право вызывать функции другого модуля. -`AccessControlled` provide a modifier `verifyPermission(address ipAccount)` helps to perform the access control check. +`AccessControlled` предоставляет метод `verifyPermission(address ipAccount)` который помогает проверить доступ. ```coffeescript Solidity contract MockModule is IModule, AccessControlled { @@ -262,19 +263,19 @@ contract MockModule is IModule, AccessControlled { if (!IAccessController(accessController).checkPermission(ipAccount, msg.sender, address(this), this.callFromAnotherModule.selector)) { revert Unauthorized(); } - // do something + // сделать что то } } ``` -## Module calling Registry +## Модуль вызывает реестр (Registry) -* The registry performs the authorization check by calling AccessController. -* The registry authorizes modules through set global permission +* Реестр выполняет проверку авторизации через Контроллер Доступа. +* Разрешения задаются глобально через администратора. -When a registry is called by a module, it can perform the access control check using AccessController. This check determines whether the callee module has permission to call the registry. +Когда модуль вызывает реестр, реестр выполняет проверку контроля доступа через Контроллер Доступа. Эта проверка подтверждает, что модуль имеет право вызывать функции реестра. ```solidity Solidity // called by StoryProtocl Admin @@ -288,13 +289,13 @@ contract MockRegistry { if (!IAccessController(accessController).checkPermission(address(0), msg.sender, address(this), this.registerAction.selector)) { revert Unauthorized(); } - // do something + // сделать что то } } ``` -> 📘 The IPAccount's permissions will be revoked upon transfer of ownership. +> 📘 Разрешения IPAccount аннулируются при передаче права собственности. > -> The permissions associated with the IPAccount are exclusively linked to its current owner. When the ownership of the IPAccount is transferred to a new individual, the existing permissions granted to the previous owner are automatically revoked. This ensures that only the current, legitimate owner has access to these permissions. If, in the future, the IPAccount ownership is transferred back to the original owner, the permissions that were initially revoked will be reinstated, restoring the original owner's access and control. +> Права, связанные с IPAccount, принадлежат только текущему владельцу. При передаче IPAccount новому владельцу все ранее предоставленные разрешения автоматически аннулируются. Если право собственности возвращается прежнему владельцу, его первоначальные разрешения восстанавливаются. diff --git a/docs/Concepts/concepts-faq.md b/docs/Concepts/concepts-faq.md index c430ddf..5695a08 100644 --- a/docs/Concepts/concepts-faq.md +++ b/docs/Concepts/concepts-faq.md @@ -1,16 +1,17 @@ --- -title: ❓ Concepts FAQ -excerpt: Common technical questions related to our protocol documentation. +title: ❓ FAQ Концепций +excerpt: Распостранённые вопросы по нашей документации deprecated: false hidden: false metadata: - title: '' - description: '' + title: "" + description: "" robots: index next: - description: '' + description: "" --- -## *"What is the difference between License Tokens, Royalty Tokens, and Revenue Tokens?"* + +## _"В чём различие между Токенами Лицензии, Токенами Роялти и Токенами Дохода?"_ @@ -20,76 +21,78 @@ next: + +
- License Tokens + Токены Лицензии - Royalty Tokens + Токены Роялти - Revenue Tokens + Токены Дохода
- **Module** + **Модуль** - [📜 Licensing Module](doc:licensing-module) + [📜 Модуль Лицензирования](doc:licensing-module) - [💸 Royalty Module](doc:royalty-module) + [💸 Модуль Роялти](doc:royalty-module) - [💸 Royalty Module](doc:royalty-module) + [💸 Модуль Роялти](doc:royalty-module)
- **Explanation** + **Объяснение** - An ERC-721 NFT that gets minted from an IP Asset with specific license terms. It is essentially the license you hold that gives you access to use the associated IP Asset based on the terms in the License Token. + NFT стандарта ERC-721, который выпускается на основе IP-актива с определенными условиями лицензии. Это, по сути, ваша лицензия, которая предоставляет доступ к использованию связанного IP-актива на условиях, указанных в Токене Лицензии. - A License Token is burned when it is used to register an IP Asset as a derivative of another. + Токен Лицензии сжигается, когда он используется для регистрации IP-актива в качестве производного от другого актива. - Each IP Asset has 100,000,000 Royalty Tokens associated, where each token represents the right of whoever owns them to claim 0.000001% of the gains ("*Revenue Tokens*") deposited into the IPA's Royalty Vault. + Каждый IP-актив связан с 100 000 000 Токенов Роялти, где каждый токен предоставляет владельцу право претендовать на 0,000001% прибыли , которая поступает в Хранилище Роялти IP. - These are the tokens that are actually used for payment (ex. ETH, USDC, etc). + Это токены, которые используются для фактических выплат (например, ETH, USDC и т.д.). - "*Royalty Tokens*" are used to claim these Revenue Tokens when an IP Asset earns them. + *"Токены Роялти"* используются для получения этих Токенов Дохода, если IP-актив зарабатывает их.
- **Associated Docs** + **Связанные Документы** - [License Token](doc:license-token) + [Токен Лицензии](doc:license-token) - [IP Royalty Vault](doc:ip-royalty-vault) + [Хранилище Роялти IP](doc:ip-royalty-vault) - [IP Royalty Vault](doc:ip-royalty-vault) + [Хранилище Роялти IP](doc:ip-royalty-vault)
diff --git a/docs/Concepts/grouping-module.md b/docs/Concepts/grouping-module.md index 24bd93f..5f674db 100644 --- a/docs/Concepts/grouping-module.md +++ b/docs/Concepts/grouping-module.md @@ -1,5 +1,5 @@ --- -title: 👥 Grouping Module +title: 👥 Модуль Группировки excerpt: '' deprecated: false hidden: false @@ -10,60 +10,63 @@ metadata: next: description: '' --- -The Grouping Module enables the creation and management of group IP Assets, supporting a royalty pool for the group. +Модуль Группировки позволяет создавать и управлять групповыми IP-активами, поддерживая пул роялти для группы. ## `GroupingModule.sol` -> 🗒️ Contract +> 🗒️ Контракт > -> View the smart contract [here](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/grouping/GroupingModule.sol). +> Ознакомьтесь с кодом смарт-контракта [тут](https://github.com/storyprotocol/protocol-core-v1/blob/main/contracts/modules/grouping/GroupingModule.sol). -`GroupingModule.sol` is the main entry point for the grouping workflows. It is **stateless** and responsible for: +`GroupingModule.sol` это основная точка входа для всех операций с группами. Контракт не имеет состояния (stateless) и отвечает за: -* Registering a new group -* Adding an IPA to a group -* Removing an IPA from a group -* Checking whether a group contains a specific IPA -* Get total number of IPAs of a group +* Регистрацию новой группы +* Добавление IP-актива в группу +* Удаление IP-актива из группы +* Проверку наличия определённого IP-актива в группе +* Получение общего числа IP-активов в группе -## Creating a Group IPA +## Создание группового IP-актива -Similar to the IP Asset registration process, in which you must have a minted NFT to register and then an IP Account is created, the same applies to Group IP Assets. You must have a minted ERC-721 NFT (that represents the ownership of the group) to register as a group, and then when you register, an IP Account for the group is deployed. +Так же, как и для регистрации IP-актива (сначала должен быть выпущен NFT, а затем только создаётся IP-аккаунт), процесс для групповых IP-активов аналогичен. Необходимо сначала выпустить NFT стандарта ERC-721 (который представляет право собственности на группу), а затем зарегистрировать его как группу, после чего для группы создаётся IP-аккаунт. -Anyone can create a new group. +Создать новую группу может любой пользователь. -### Group IP Asset Registry +### Реестр групповых IP-активов -Similar to how when an IP Asset is created an IP Account is deployed & registered through the [IP Asset Registry](doc:ip-asset-registry), the Group's IP Account is deployed and registered through the [Group IP Asset Registry](doc:group-ip-asset-registry). This is responsible for managing the registration and tracking of Group IP Assets, including the group members and reward pools. +Подобно тому, как при создании IP-актива развёртывается и регистрируется IP-аккаунт через [Реестр IP-активов](doc:ip-asset-registry), IP-аккаунт группы развёртывается и регистрируется через [Реестр Групповых IP-активов](doc:group-ip-asset-registry). Этот реестр отвечает за управление регистрацией и отслеживанием групповых IP-активов, включая участников группы и пул вознаграждений. -## The Group's IP Account +## IP-аккаунт группы -The Group IP Account should function equivalently to a normal IP Account, allowing attachment of license terms, creation of derivatives, execution with modules, and other interactions. It also has the same common interface of IP Account. Hence, the Group IP Account can be applied to anywhere where IP Account can be applied. +IP-аккаунт группы должен функционировать аналогично обычному IP-аккаунту, предоставляя возможность прикрепления лицензионных условий, создания производных активов, работы с модулями и других взаимодействий. -Besides the common interfaces of IP Account, the Group IP Account has functions to manage the adding/removing of individual IPAs in the group. +Он имеет тот же общий интерфейс, что и обычный IP-аккаунт. Таким образом, IP-аккаунт группы может применяться в тех же сценариях, где используется обычный IP-аккаунт. -## Adding & Removing from a Group +Кроме того, IP-аккаунт группы имеет функции для управления добавлением/удалением отдельных IP-активов в/из группы. -Only the owner of a group can add/remove IP Assets. You **do not** have to own an IP Asset to add it to your group. +## Добавление и удаление из группы -### Conditions to Add to a Group +Только владелец группы может добавлять или удалять IP-активы. При этом вам **не обязательно** владеть IP-активом, чтобы добавить его в свою группу. -There are a few conditions an IP Asset must meet to be added into a group: +### Условия добавления в группу -1. The minting fee of that IP Asset must be set to 0 -2. It must have the same license terms of the group it is trying to join **or** no license terms at all. It can also have other license terms attached, as long as one of them is the same. +Есть несколько условий, которым должен соответствовать IP-актив, чтобы быть добавленным в группу: -### Groups Becoming Locked +1. Комиссия за выпуск этого IP-актива должна быть равна 0. +2. ктив должен иметь такие же лицензионные условия, как у группы, в которую он пытается войти, **или** вообще не иметь лицензионных условий. Он также может иметь дополнительные лицензионные условия, при условии, что одно из них совпадает с группой. -There are a few cases in which a group becomes "locked", meaning you can't add/remove any more members: +### Случаи, когда группы становятся заблокированными -* once the group receives any type of payment -* if a derivative is linked to the group (in other words, the group becomes a parent IP) +Есть несколько ситуаций, при которых группа становится "заблокированной", то есть добавление/удаление участников становится невозможным: -If any of these happen, you must create a new group if you wish to add/remove members. +* Когда группа получает какой-либо платеж. +* Если к группе привязан производный актив (т.е. группа становится "родительским" IP). -> 📘 Example +Если это произошло, для добавления/удаления участников необходимо создать новую группу. + +> 📘 Пример > -> Lets say you have an AI bot that uses training data to continuously learn and produce better content. The training data is a Group IPA that is the root, and the AI bot is a derivative IPA of the training data. And any time the AI bot gets paid, the revenue flows back to the training data as revenue. +> Представьте, что у вас есть ИИ-бот, который использует данные для обучения, чтобы улучшать своё содержание. Эти данные обучения – это групповой IP-актив, являющийся корневым, а сам ИИ-бот – это производный IP-актив от данных обучения. +Каждый раз, когда ИИ-бот получает доход, средства возвращаются в данные обучения в виде роялти. > -> Now you want to add more training data to the group. Since the group is now locked (you linked a derivative to it), you should register a new Group IPA as a root, and then a new AI bot as a derivative. \ No newline at end of file +> Теперь вы хотите добавить больше данных обучения в группу. Однако группа уже заблокирована (поскольку к ней привязан производный актив). В таком случае вам нужно зарегистрировать новый групповой IP-актив в качестве корневого, а затем создать новый ИИ-бот как производный актив от нового корня. \ No newline at end of file diff --git a/docs/Concepts/ip-account.md b/docs/Concepts/ip-account.md index 3269d28..5c1a201 100644 --- a/docs/Concepts/ip-account.md +++ b/docs/Concepts/ip-account.md @@ -14,19 +14,19 @@ next: > > Краткая 2-минутная выжимка про IP-аккаунты тут [тут](https://twitter.com/jacobmtucker/status/1787603252198134234). -When an [🧩 IP Asset](doc:ip-asset) is registered, it is given an associated **IP Account**. An IP Account is a modified ERC-6551 (Token Bound Account) implementation. It is a separate contract bound to the IP Asset for controlling permissions around interactions with Story's modules or storing the IP's associated data. Upon registration, an IP Asset is assigned a unique ID. This ID is the address of the IP Account that is bound to the IP Asset. +Когда 🧩 [IP-актив](doc:ip-asset) регистрируется, ему назначается связанный **IP-аккаунт**. IP-аккаунт представляет собой модифицированную реализацию ERC-6551 (Token Bound Account). Это отдельный контракт, привязанный к IP-активу, который управляет разрешениями для взаимодействия с модулями Story или хранения данных, связанных с IP. При регистрации IP-активу присваивается уникальный идентификатор. Этот идентификатор является адресом IP-аккаунта, привязанного к активу. ![](https://files.readme.io/aab60607fd795080b061d93bfdfaf9a800930db861be332d205a48d637e234f1-image.png) -An IP Account mainly does two things: +IP-аккаунт выполняет две основные функции: -1. Stores comprehensive IP-related data, including metadata and ownership details of associated assets such as the License Tokens or Royalty Tokens that are created from the IP. -2. Facilitates the utilization of this data by various modules. These modules interact with and contribute to the IP Account, creating and storing data. For example, licensing, revenue/royalty sharing, remixing, disputing an IP, and other modules are made possible due to the IP Account's programmability. +1. Хранение данных, связанных с IP. Включает метаданные и информацию о владении связанными активами, такими как Лицензионные Токены или Роялти Токены, созданные на основе IP. +2. Обеспечение использования этих данных различными модулями. Эти модули взаимодействуют с IP-аккаунтом и вносят в него данные. Например, лицензирование, распределение доходов/роялти, ремиксы, разрешение споров и другие действия становятся возможными благодаря программируемости IP-аккаунта. -> 📘 Transferring the Underlying NFT +> 📘 Передача базового NFT > -> If the underlying NFT is transferred, the new owner is also automatically the owner of the associated IP Asset & IP Account. +> Если базовый NFT передается другому владельцу, то новый владелец автоматически становится владельцем связанного IP-актива и IP-аккаунта. -## `execute` and `executeWithSig` +## `execute` и `executeWithSig` -A key feature of IP Account is the generic `execute()` function, which allows calling arbitrary modules within Story via encoded bytes data (thus extensible for future modules). Additionally, there is a `executeWithSig()` function that enables users to sign transactions and have others execute on their behalf for seamless UX. +Ключевая функция IP-аккаунта — это универсальная функция `execute()`, которая позволяет вызывать любые модули внутри Story с использованием закодированных данных в формате bytes (что делает ее расширяемой для будущих модулей). Дополнительно существует функция `executeWithSig()`, которая позволяет пользователям подписывать транзакции и поручать их выполнение другим, обеспечивая удобство пользовательского опыта (UX).