> 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/no/omniyield/arkitektur.md). # Arkitektur OmniYields arkitektur er utformet for å være modulær, uavhengig av kjede og svært skalerbar. Vårt primære mål er å skape et avkastningslag uavhengig av kjede som maksimerer risikojustert avkastning for brukere på tvers av DeFi. For å oppnå dette bruker systemet omfattende dataanalyse, avanserte off-chain-algoritmer, strenge sikkerhetsprotokoller, diversifiseringsregler og en arkitektur som abstraherer bort kompleksiteten i krysskjedesamhandling. ### Viktige arkitektoniske komponenter
Hvelv Brukerens inngangsport til OmniYield. Disse smarte kontraktene som er i samsvar med ERC-4626, håndterer innskudd sikkert, mottar rapporter fra strategier og behandler uttak. De fungerer som hovedgrensesnittet som koordinerer brukerens midler med de underliggende strategiene.
Utførelseslag (Solver) Intelligenslaget til OmniYield. Disse automatiserte systemene analyserer kontinuerlig DeFi-protokoller på tvers av kjeder, identifiserer optimale avkastningsmuligheter, vurderer risiko og styrer allokeringen av eiendeler for hvelvene. Denne behandlingen beregnes off-chain for effektivitetens skyld - bare resultatene implementeres on-chain, noe som hindrer at OmniYields strategier blir etterlignet.
Strategier Knyttet til hvert hvelv er minst én strategi-kontrakt. Denne komponenten oversetter solver-beslutninger til handlinger. Den håndterer de tekniske kompleksitetene ved flytting av eiendeler, inkludert token-bytter, likviditetslevering, utlån, staking osv.
Destinasjoner De spesifikke DeFi-protokollene, likviditetspoolene eller yield-farmene der hvelvens eiendeler til slutt plasseres.
Infrastruktur for krysskjedemeldinger Den grunnleggende teknologien som muliggjør krysskjedefunksjonalitet, og som fasiliterer kommunikasjon og overføring av eiendeler mellom ulike blokkjeder.
### Eiendelens livssyklus
Å forstå flyten av eiendeler bidrar til å tydeliggjøre systemets drift: {% stepper %} {% step %} **Innskudd** En bruker setter inn en enkelt type eiendel (f.eks. USDC) i det tilsvarende OmniYield-hvelvet på en hvilken som helst støttet kjede. De innskutte eiendelene flyttes til hvelvkontrakten på Arbitrum-huben og ligger i utgangspunktet passive der. {% endstep %} {% step %} **Krysskjedebalansering** * Den off-chain-komponenten (autonom Solver) overvåker hvelvbalanser og markedsforhold. Når en viss terskel for passive eiendeler er nådd, eller under periodiske optimaliseringssykluser, bestemmer den den optimale allokeringen for de nåværende strategiene på tvers av integrerte kjeder og foreslår en rebalanseringsplan. Hvis forslaget oppfyller sikkerhets- og ytelseskravene, initierer det en rebalansering (f.eks. å flytte X mengde USDC til Strategi A på Kjede Y) gjennom hvelvkontrakten på Arbitrum-huben. * Ved bruk av LayerZero og Axelar sendes en melding som inneholder rebalanseringsinstruksjoner fra huben til den relevante hvelvkontrakten på mål-kjedene. * Systemet utfører de nødvendige trinnene (for eksempel bridging, bytte, innskudd osv.) for å rebalansere. * Den oppdaterte allokeringen registreres, og bekreftelses-/statusoppdateringer sendes tilbake til Arbitrum-huben via meldingslaget. Denne prosessen kan innebære å flytte passive midler fra huben inn i en strategi eller å flytte midler mellom ulike strategier for å jage bedre avkastning. {% endstep %} {% step %} **Autoutbytte og konsolidert rapportering** * Strategi-kontrakter gjør jevnlig krav på opptjente belønninger fra destinasjonsprotokollene, konvertert til hvelvets basis-eiendel (f.eks. USDC) og reinvesterer dem automatisk. Denne prosessen orkestreres av autoriserte Keepers. * Ytelsesdata, inkludert belønninger generert av disse strategiene på alle støttede kjeder, rapporteres kontinuerlig tilbake til Arbitrum-huben. Belønningene legges til hvelvets totale verdi, slik at avkastningen for innskytere sammensettes automatisk. {% endstep %} {% step %} **Uttak** * Uttak er ikke begrenset til innskuddskjeden; brukere kan starte en uttaksforespørsel når som helst fra en hvilken som helst støttet kjede (**det trenger ikke å være den samme kjeden som ble brukt til innskuddet**). * Et ytelsesgebyr på 9 % beregnes basert på fortjenesten som genereres av en brukers innskudd på tvers av alle underliggende strategier og kjeder. * Forespørselen rutes til Arbitrum-huben. Hvis hvelvet har tilstrekkelige passive midler (eiendeler som ikke er aktivt plassert i strategier), behandles uttaket umiddelbart. * Hvis hvelvet ikke har tilstrekkelige passive midler, signaliserer huben til strategiene at de skal ta ut det nødvendige beløpet. Den prioriterer uttak fra strategier der påvirkningen på den samlede avkastningen (APR) er minst. Denne prosessen kan ta litt lengre tid avhengig av de underliggende protokollene. {% endstep %} {% step %} **Krev ut** * Når tilstrekkelig likviditet er tilgjengelig i hvelvet, kan brukeren kreve uttaket sitt. Ved krav overføres de tilsvarende eiendelene til brukerens lommebok via krysskjededinfrastrukturen. {% endstep %} {% endstepper %} ### Krysskjedearkitektur OmniYields infrastruktur er bygget på en robust hub-and-spoke-arkitektur: * **Hub:** Vi bruker Arbitrum som vår sentrale operative hub («hovedkjeden»). Det er her kjernelogikken, de komplekse beregningene og den overordnede tilstandshåndteringen til OmniYield-protokollen primært befinner seg. * **Spokes:** Alle andre støttede blokkjeder fungerer som «spoke chains» eller «sidekjeder». Dette er nettverkene der brukerinnskudd kan komme fra, og der mange av de underliggende avkastningsstrategiene er utplassert. De fungerer primært som utførelsespunkter som mottar instruksjoner fra Huben.
#### **Kommunikasjonsflyt:** {% stepper %} {% step %} **Aggregering** Når en rebalanseringsbeslutning tas eller brukerhandlinger (som innskudd/uttak som krever krysskjedebevegelse) skjer, genereres krysskjedemeldinger og sendes sikkert fra spoke-kjedene til Arbitrum-huben. {% endstep %} {% step %} **Beregning** Huben behandler disse innkommende meldingene, utfører nødvendige beregninger (som å optimalisere eiendelsallokeringen på tvers av alle spokes, beregne den samlede hvelvytelsen, konsolidere gebyrer) og tar strategiske beslutninger basert på sin globale oversikt over systemet. {% endstep %} {% step %} **Distribusjon** Når beslutningene er tatt, distribueres nødvendige instruksjoner og transaksjonsdata tilbake fra Arbitrum til de relevante smarte kontraktene på spoke-kjedene for utførelse (f.eks. å sette midler inn i en bestemt strategi på et annet nettverk). {% endstep %} {% endstepper %} {% hint style="success" %} Dette modulære designet muliggjør: * **Sentralisert logikk, desentralisert utførelse**\ Denne modellen sikrer datakonsistens ettersom Arbitrum-huben fungerer som eneste sannhetskilde. Faktisk kapitalplassering skjer på tvers av spoke-kjedene, og utnytter de unike mulighetene hver kjede tilbyr. * **Modularitet og utvidbarhet**\ Nye kjeder, eiendeler, strategier og destinasjoner kan integreres på en plug-and-play-måte med minimale endringer i den eksisterende kodebasen.\ Dette sikrer et lavt angrepsareal samtidig som det legger til rette for utvikling av अतिरिक्त produkter. For ytterligere å styrke robustheten og funksjonaliteten integrerer OmniYield Protocol med ulike DeFi-primitiver og infrastrukturer, og gir den beste brukeropplevelsen og muliggjør sømløs samhandling med andre finansielle verktøy. {% endhint %} ### Krysskjedekommunikasjon Driften av vår hub-and-spoke-modell på tvers av mange blokkjeder er muliggjort ved å utnytte ledende leverandører av krysskjedemeldinger: LayerZero og Axelar (og potensielt andre som er tilpasset spesifikke tokens/kjeder/funksjoner i fremtiden). LayerZero muliggjør lettvekts og effektiv meldingsutveksling, og sikrer minimal latenstid og tillitsløs interoperabilitet på tvers av støttede nettverk. Axelar kompletterer dette med overordnet ruting og sikker levering av generaliserte krysskjedemeldinger. * **Kommunikasjonsryggraden:** Disse protokollene fungerer som den sikre og pålitelige kommunikasjonsinfrastrukturen som kobler vår Hub (Arbitrum) med alle Spoke-kjedene. De gir de essensielle kanalene for overføring av data og instruksjoner på tvers av blokkjedegrenser. All videresending, validering og oppgjør av meldinger utføres gjennom disse leverandørenes sikre meldingssystemer. * **Tilrettelegging for viktige operasjoner:** LayerZero og Axelar sender kritiske meldinger som kreves for kjernefunksjoner. Dette inkluderer: * Varsling av Huben om nye innskudd gjort på spoke-kjeder. * Videresending av uttaksforespørsler fra brukere på spoke-kjeder til Huben for behandling. * Sending av kommandoer fra Huben til strategi-kontrakter på spoke-kjeder for å utføre innskudd, uttak eller rebalansering. * Rapportering av generert avkastning, ytelsesmålinger og gebyrdata fra strategier på spoke-kjeder tilbake til Huben. ### Konsolidert gebyrrapportering I typiske multi-chain-oppsett fungerer hver kjede ofte som en silo med isolert logikk og ytelsesrapportering. OmniYield tar en radikalt annerledes tilnærming. Vi mener at økosystemet vårt skal fungere som én samlet protokoll, ikke som en fragmentert samling av kjedespesifikke utrullinger. Selv om OmniYield genererer gebyrer fra avkastningsstrategier som opererer på tvers av mange kjeder. Protokollen implementerer konsolidert gebyrrapportering, en prosess der data om gebyrgenerering fra alle støttede kjeder aggregeres, normaliseres og beregnes på Arbitrum (huben). {% hint style="success" %} Dette muliggjør: * **Fleksibel brukeropplevelse:** Brukere trenger ikke å bekymre seg for inkonsistente insentiver. De kan sette inn fra hvilken som helst kjede de foretrekker, vel vitende om at gebyrer, avkastningsmuligheter og belønninger forblir konsistente på tvers av hele OmniYield-økosystemet. * **Delte tokenomics:** Alle protokollgebyrer, uansett opprinnelseskjede, bidrar til den samme globale inntektsmodellen. * **Gjennomsiktige måledata:** Enhetlig rapportering eliminerer avvik og forbedrer revisjonssporbarheten. {% endhint %}