> For the complete documentation index, see [llms.txt](https://docs.omniyield.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omniyield.finance/bg/omniyield/arkhitektura.md).

# Архитектура

Архитектурата на OmniYield е проектирана да бъде модулна, независима от веригата и силно мащабируема.

Нашата основна цел е да създадем независим от веригата слой за доходност, който максимизира възвръщаемостта, коригирана спрямо риска, за потребителите в DeFi. За да постигне това, системата използва обстоен анализ на данни, усъвършенствани извънверижни алгоритми, строги протоколи за безопасност, правила за диверсификация и архитектура, която абстрахира сложността на междуверижното взаимодействие.&#x20;

### Основни архитектурни компоненти

<details>

<summary><strong>Хранилища</strong></summary>

Портата на потребителя към OmniYield.

Тези интелигентни договори, съвместими с ERC-4626, сигурно управляват депозитите, получават отчети от стратегиите и обработват тегленията.

Те служат като основен интерфейс, координиращ средствата на потребителя с базовите Стратегии.

</details>

<details>

<summary><strong>Изпълнителен слой (Solver)</strong></summary>

Интелигентният слой на OmniYield.

Тези автоматизирани системи непрекъснато анализират DeFi протоколи във всички вериги, идентифицират оптимални възможности за доходност, оценяват рисковете и определят разпределението на активите за Хранилищата.

Тази обработка се изчислява извън веригата за по-голяма ефективност — само резултатите се внедряват във веригата, като се предотвратява имитирането на стратегиите на OmniYield.

</details>

<details>

<summary><strong>Стратегии</strong></summary>

Към всяко Хранилище е свързан поне един договор за Стратегия.

Този компонент превежда решенията на solver-а в действия. Той се справя с техническите сложности на движението на активи, включително размяна на токени, предоставяне на ликвидност, кредитиране, стейкинг и др.

</details>

<details>

<summary><strong>Дестинации</strong></summary>

Конкретните DeFi протоколи, пулове за ликвидност или ферми за доходност, в които в крайна сметка се разпределят активите на хранилището.

</details>

<details>

<summary><strong>Инфраструктура за междуверижни съобщения</strong></summary>

Основната технология, която позволява междуверижни възможности, улеснявайки комуникацията и прехвърлянето на активи между различни блокчейни.

</details>

### Жизненият цикъл на активите

<div data-with-frame="true"><figure><img src="/files/e6665af9560c90ad9fbccfff00be1660a043e6c2" alt=""><figcaption></figcaption></figure></div>

Разбирането на потока на активите помага да се изясни работата на системата:

{% stepper %}
{% step %}
**Депозит**

Потребител депозира един тип актив (напр. USDC) в съответното хранилище OmniYield във всяка поддържана верига. Депозираните активи се прехвърлят в договора на хранилището в хъба Arbitrum и първоначално остават неактивни там.
{% endstep %}

{% step %}
**Междуверижно ребалансиране**

* Извънверижният компонент (автономен Solver) следи балансите на хранилищата и пазарните условия. Щом бъде достигнат определен праг на неактивни активи или по време на периодични цикли на оптимизация, той определя оптималното разпределение за текущите Стратегии във всички интегрирани вериги и предлага план за ребалансиране. Ако предложението отговаря на изискванията за безопасност и производителност, то инициира ребалансиране (напр. прехвърляне на X количество USDC към Стратегия A във верига Y) чрез договора на хранилището в хъба Arbitrum.&#x20;
* Използвайки LayerZero и Axelar, съобщение, съдържащо инструкции за ребалансиране, се изпраща от хъба към съответния договор на хранилището в целевите вериги.
* Системата изпълнява необходимите стъпки (като мостово прехвърляне, размяна, депозиране и др.) за ребалансиране.
* Актуализираното разпределение се записва и потвърждения/статус актуализации се изпращат обратно към хъба Arbitrum чрез слоевете за съобщения. Този процес може да включва прехвърляне на неактивни средства от хъба към Стратегия или преместване на средства между различни Стратегии в търсене на по-добра доходност.
  {% endstep %}

{% step %}
**Автоматично капитализиране и консолидирано отчитане**

* Договорите на Стратегиите периодично заявяват натрупаните награди от дестинационните протоколи, конвертирани в базовия актив на хранилището (напр. USDC), и ги реинвестират автоматично. Този процес се оркестрира от разрешени Keepers.&#x20;
* Данните за ефективността, включително наградите, генерирани от тези Стратегии във всички поддържани вериги, непрекъснато се отчитат обратно към хъба Arbitrum. Наградите се добавят към общата стойност на хранилището, като автоматично капитализират доходността за депозиторите.
  {% endstep %}

{% step %}
**Теглене**

* Тегленията не са ограничени до веригата на депозита; потребителите могат да инициират заявка за теглене по всяко време от всяка поддържана верига (**не е задължително да е същата верига, използвана за депозита**).
* Такса за ефективност от 9% се изчислява въз основа на печалбата, генерирана от депозита на потребителя във всички базови Стратегии и вериги.
* Заявката се насочва към хъба Arbitrum. Ако Хранилището разполага с достатъчно неактивни средства (активи, които не са активно разпределени в Стратегии), тегленето се обработва незабавно.
* Ако Хранилището няма достатъчно неактивни средства, хъбът сигнализира на Стратегиите да изтеглят необходимата сума. Приоритет се дава на теглене от Стратегии, при които въздействието върху общата доходност (APR) е минимално. Този процес може да отнеме малко повече време в зависимост от базовите протоколи.
  {% endstep %}

{% step %}
**Заявяване**

* След като в Хранилището има достатъчно ликвидност, потребителят може да заяви своето теглене. При заявяване съответните активи се прехвърлят в портфейла на потребителя чрез междуверижната инфраструктура.
  {% endstep %}
  {% endstepper %}

### Междуверижна архитектура

Инфраструктурата на OmniYield е изградена върху стабилна хъб-и-спици архитектура:&#x20;

* **Хъб:** Използваме Arbitrum като наш централен оперативен хъб („основната верига“). Тук основно се намират основната логика, сложните изчисления и цялостното управление на състоянието на протокола OmniYield.
* **Спици:** Всички други поддържани блокчейни функционират като „спица-вериги“ или „странични вериги“. Това са мрежите, от които могат да произхождат потребителските депозити и върху които се разгръщат много от базовите Стратегии за доходност. Те основно действат като крайни точки за изпълнение, получаващи инструкции от Хъба.

<div data-with-frame="true"><figure><img src="/files/b95ce9ab97c0ba01c0517adf981dce8f148b80c1" alt=""><figcaption></figcaption></figure></div>

#### **Поток на комуникация:**

{% stepper %}
{% step %}
**Агрегиране**

Когато бъде взето решение за ребалансиране или възникнат действия на потребителите (като депозити/тегления, изискващи междуверижно прехвърляне), се генерират междуверижни съобщения и те сигурно се предават от спица-веригите към хъба Arbitrum.
{% endstep %}

{% step %}
**Изчисление**

Хъбът обработва тези входящи съобщения, извършва необходимите изчисления (като оптимизиране на разпределението на активите между всички спици, изчисляване на общата ефективност на хранилището, консолидиране на таксите) и взема стратегически решения въз основа на своята глобална представа за системата.
{% endstep %}

{% step %}
**Разпределение**

След като решенията бъдат взети, необходимите инструкции и данни за транзакциите се разпределят обратно от Arbitrum към съответните интелигентни договори на спица-веригите за изпълнение (напр. депозиране на средства в конкретна Стратегия в друга мрежа).
{% endstep %}
{% endstepper %}

{% hint style="success" %}
Този модулен дизайн позволява:

* **Централизирана логика, децентрализирано изпълнение**\
  Този модел осигурява консистентност на данните, тъй като хъбът Arbitrum действа като единствен източник на истина. Действителното разпределение на капитала се извършва във всички спица-вериги, използвайки уникалните възможности, които всяка верига предоставя.
* **Модулност и разширяемост**\
  Новите вериги, активи, стратегии и дестинации могат да бъдат интегрирани по модела plug-and-play с минимални промени в съществуващата кодова база.\
  Това осигурява малка повърхност за атака, като същевременно улеснява разработването на допълнителни продукти. За да подобри допълнително своята устойчивост и функционалност, протоколът OmniYield се интегрира с различни DeFi примитиви и инфраструктури, осигурявайки най-доброто потребителско изживяване и безпроблемно взаимодействие с други финансови инструменти.
  {% endhint %}

### Междуверижна комуникация

Работата на нашия модел хъб-и-спици върху множество блокчейни е възможна благодарение на водещи доставчици на междуверижни съобщения: LayerZero и Axelar (и потенциално други, съобразени с конкретни токени/вериги/функции в бъдеще).&#x20;

LayerZero осигурява лека и ефективна комуникация, гарантирайки минимална латентност и бездоверителна оперативна съвместимост между поддържаните мрежи. Axelar допълва това с маршрутизиране на високо ниво и сигурна доставка на обобщени междуверижни съобщения.

* **Комуникационният гръбнак:** Тези протоколи действат като сигурната и надеждна комуникационна инфраструктура, свързваща нашия Хъб (Arbitrum) с всички Спица-вериги. Те осигуряват основните пътища за предаване на данни и инструкции през границите на блокчейна. Цялото препращане на съобщения, валидиране и сетълмент се извършва чрез сигурните съобщителни канали на тези доставчици.
* **Улесняване на ключови операции:** LayerZero и Axelar предават критичните съобщения, необходими за основните функции. Това включва:
  * Уведомяване на Хъба за нови депозити, направени в спица-веригите.
  * Препращане на заявки за теглене от потребители в спица-веригите към Хъба за обработка.
  * Изпращане на команди от Хъба към договорите на стратегиите в спица-веригите за изпълнение на депозити, тегления или ребалансирания.
  * Отчитане обратно към Хъба на генерираната доходност, показатели за ефективност и данни за таксите от стратегиите в спица-веригите.

### Консолидирано отчитане на таксите

В типичните многоверижни настройки всяка верига често действа като силоз с изолирана логика и отчитане на ефективността. OmniYield предприема коренно различен подход. Вярваме, че нашата екосистема трябва да функционира като единен протокол, а не като фрагментирана колекция от внедрявания, специфични за всяка верига.

Докато OmniYield генерира такси от стратегии за доходност, работещи в множество вериги. Протоколът прилага консолидирано отчитане на таксите — процес, при който данните за генериране на такси от всички поддържани вериги се агрегират, нормализират и изчисляват в Arbitrum (хъба).&#x20;

{% hint style="success" %}
Това позволява:

* **Гъвкаво потребителско изживяване:** Потребителите не трябва да се тревожат за несъгласувани стимули. Те могат да депозират от всяка верига, която предпочитат, знаейки, че таксите, възможностите за доходност и наградите остават последователни в цялата екосистема OmniYield.
* **Споделена токеномика:** Всички такси на протокола, независимо от изходната верига, допринасят към един и същ глобален модел на приходи.
* **Прозрачни показатели:** Унифицираното отчитане елиминира несъответствията и подобрява одитируемостта.
  {% endhint %}

<div align="right"><figure><img src="/files/00adf69ddc534e16d3f3a1e6fc823fe601dc5c07" alt="" width="17"><figcaption></figcaption></figure></div>
