Li.Fi

Ang LI.FI ay isang multi-chain liquidity aggregation protocol na sumusuporta sa any-2-any swaps sa pamamagitan ng pagsasama-sama ng mga bridge at DEX aggregator sa +20 network.

Ang aming JS/TS SDK ay maaaring ipatupad sa anumang front- o backend para mabuo mo ang iyong UX/UI sa paligid ng aming bridge at swap functionality. Higit pa rito, pinangangasiwaan nito ang lahat ng komunikasyon sa pagitan ng aming smart routing API at smart contract at nagbibigay ng natitirang kaganapan at paghawak ng error.

Ang aming REST API ay nagbibigay sa iyo ng lahat ng impormasyon at nagbibigay-daan sa mas malalim at custom na pagsasama.

Ipinatupad sa loob ng 5 minuto, nakakatulong ang widget na mag-onboard ng mga user mula sa kahit saan.

Kung wala kang oras upang isama kami, mag-link sa aming website gamit ang iyong token at chain na paunang na-configure.

Ang iyong mga matalinong kontrata ay open source, ngunit ang aming API ay hindi. Ito ang aming mapagkumpitensyang kalamangan, at pinangangasiwaan namin ito at inihahanay ang aming diskarte sa malalaking DEX aggregators tulad ng 1inch at Paraswap, na nagpapanatili ring saradong source ng kanilang API.

Habang ang aming mga matalinong kontrata ay tumatakbong desentralisado, ang aming backend ay kailangang sentralisado.

Bakit? Ang halaga ng pagpoproseso ng data ay hindi mapoproseso sa blockchain sa sapat na mabilis na paraan, at sa parehong oras, ito ay nagkakahalaga ng daan-daang dolyar bawat swap computation mula sa isang gas-fee perspective.

Magbabago ba ito? Gusto rin naming i-desentralisa ang aming imprastraktura kung papayagan ito ng hinaharap. Alam namin na may ilang proyekto ang gumagawa nito, at sinusubaybayan namin silang mabuti. Sa paligid nito, kailangan din namin ng wastong dev-ops ecosystem na nagbibigay-daan sa amin na panatilihing gumagana at mapanatili ang naturang imprastraktura habang pinapanatili itong mabilis at secure para sa user.

Sumulong kami sa tatlong hakbang na paraan:

Suriin ang mga kasalukuyang tulay sa kanilang mga kakayahan (kung saan ang mga chain ay suportado) at seguridad.

Suriin kung ang lahat ng umiiral na chain sa aming system ay hindi gaanong sinusuportahan ng dalawang tulay na aming ipinatupad. Sa ganoong paraan, tinitiyak namin na mayroong fallback na solusyon kung walang laman ang liquidity o kung kailangan naming isara ang tulay dahil sa isang hack o iba pa.

Magpatupad ng isang tulay na nagba-back up sa isa pa o isang tulay na nagpapalawak ng aming mga kakayahan upang tulay patungo sa mga bagong chain.

Ang bawat tulay ay manu-mano at awtomatikong namarkahan batay sa mga salik ng husay at dami. Ang mga qualitative factor ay, halimbawa, trust assumptions at attack vectors. Maaaring masukat ang mga quantitative factor tulad ng bilis, mga bayarin, mga gastusin, at pagiging maaasahan. Inaayos ng aming algorithm ang paggawa nito ng desisyon batay sa mga salik na ito at sa pangkalahatan ay kumikilos pagkatapos ng aming default na pattern ng prioritization, na nagsasabing seguridad > bilis > mga gastos. Naniniwala kami na ang pattern na ito ay nagbibigay ng pinaka responsable at napapanatiling karanasan ng user. Maaaring isaayos ng sinumang nagpapatupad ng aming bridge aggregation protocol o SDK ang pattern ng prioritization.

Oo, sinusuportahan namin ang pag-whitelist at pag-blacklist ng ilang tulay. Pinapayagan din namin ang pag-prioritize ng isang tulay sa kabila, at pinapayagan namin ang pagbabago ng default na pattern ng prioritization. Sa ganoong paraan, pinapayagan ka naming kumilos nang may kinikilingan. Halimbawa, maaaring gusto mo ang isang partikular na bridge protocol o DEX aggregator dahil hindi ka nagtitiwala sa ilang iba pa.

Hindi mahalaga kung pagmamay-ari ng Ethereum ang karamihan sa merkado, magkakaroon ng maraming chain:

ginagawang mas nasusukat ang Ethereum (optimistic- at zk-rollups)

sinusubukang makipagkumpitensya sa Ethereum (tingnan ang Solana, Terra, Near, Tezos, atbp.)

ibinibigay ng malalaking kumpanya o nation-state

mga nakatuon sa aplikasyon (hal. pananalapi, paglalaro, panlipunan, pag-iimbak ng data, pagproseso ng data (hal. bioinformatics)

Ang pagkatubig ay kailangang i-bridge, at ang isang one-stop na solusyon/isang aggregator para doon ay palaging makakahanap ng espasyo nito.