Meetup #22 - OIF and ERC7786 - Luiz Vasconcelos

Transcript

Eh, deixa eu ver o volume rapidão aqui. Tá comigo >> do do not. Boa noite. >> Eh, então, gente, aqui no Mac mesmo dá um m eh, eu posso falar assim, mas acho que o EC de B.

Gente, só lembrando então que a gente vai começar esse ano com os encontros, mas já tem bastante conteúdo gravado. Eu tô dividindo a tela aqui do nosso canal do YouTube, né? Eh, a ideia é sempre trazer os últimos tópicos aí que ainda não chegou, que não chegaram no Brasil. O próximo meetap, o do mês, do mês que vem vai ser Cassol sobre uma tech nova da Chinlink, mas já tem coisa legal aí. Zero Knowledge foi um tópico que a gente bateu bastante ano passado. Eu acho que vai até ver, vai ter coisa de zer que toca zero knowledge em cross chain ou ou não?

Boa. Então, Zonology é algo que a gente bateu bastante ano passado. Account abstraction também, né? Teve mais de um meetap sobre account abstraction. Teve alguns eh meetaps de ferramental, né? Então tem um com o Mateus que é do time do Solidity que ele deu um para onde que o Solidity tá indo. Teve um só Foundry mais introdutório. É, também tá no roadmap aqui pr pros próximos Meetups, um sobre AI tools, que é um pouquinho fora do escopo, mas nem tanto, porque a gente vai trazer dois devs do mercado, o Denis que trabalha na Nethermind e eh o Thiago que trabalha na Trust Wallet,

para eles contarem como que eles estão usando AI ali no dia a dia deles, eh, de dois ângulos diferentes, um ali no topo do stack de wallet, né, de client facing e o Denis na parte bem infra, né? Então vai ser legal. E se vocês o o ponto principal é quem tiver sugestão de tema de algum tema que tá sendo falado lá fora e que quisesse que a gente procurasse palestrante aí é só mandar. Valeu, conteúdo fica gravado. E sobre o Luiz, obrigado Luiz por ter topado. O Luiz é sempre topa tudo. Ano passado a gente foi fazer uma apresentação em Recife e a galera ele chegou lá explicando posição

de no SOP V3. Eh, ninguém entendeu nada e mesmo assim ele foi lá, lá pro Nordeste levar conteúdo onde não é tão fácil de chegar. Eh, e feliz também na trajetória que eu eu acho que o Luiz ele sai desse lance de comunidade, né? Se você puder também comentar um pouco de como que você chegou em É tipo aqui é mais do que só lance técnico também é um negócio para deve conhecer os devs. Então, se você puder contar um pouco da trajetória e como que você chegou na Open Zaplin em cripto, legal também. Luiz, obrigado por ter topado e aí o palco é seu agora.

Opa, fala pessoal, tudo bem? Vou ligar a câmera aqui. Eu vou compartilhar a minha tela. Acho que vocês tão vendo todo mundo vendo aí. É, eu eu deixo essa câa aqui ligada ou deixar aqui ligado que eu vou ficar sentado mesmo e daí se alguém se alguém tiver alguma pergunta tanto online quanto aqui parael pode pode falar. Eu tô acho que é é legal também se a gente tiver alguma dúvida, alguma pergunta.

Eh, só me apresentando um pouquinho, né? Eh, meu nome é Luí, eu sou engenheiro de computação, eu tô em B3 já tem uns 4 anos agora. E assim foi, eu comecei tour de comunidade assim até 2022. Eu nunca tinha, eu já tinha ouvido falar de Bitcoin por nome, mas eu nunca tinha aberto a Metamesk. E daí um dia do nada eu tava na na faculdade e me e me falaram que ia ia acontecer a a a Etherium R, que eu também não sabia o que era, mas mas parece interessante. Eu eu eu moro em São José dos Campos, então a gente organizou uma viagem lá para levar a galera pro Racaton. E daí o o Rob inclusive ajudou aí a Solonge

também. Daí aí a gente chegou lá e foi a primeira vez que eu vi o que que era web 3 e o primeiro primeiro primeiro racatom e também a primeira vez que eu tive que contar com com qualquer coisa Etheréreum. E aí nesse momento eu falei: "Pô, tenho que entrar nesse nesse mercado assim, achei muito legal". Na época eu eu estagiava num fundo de investimento de análise de ações na bolsa, então não tinha muito a ver. Eh, mas daí eu eu mas eu gostei muito da parte financeira também. Daí eu vi que era o que eu queria e daí logo eu eu foquei nisso, né? lá na na faculdade no ITA, a gente criou um clube de

blockchain logo depois disso, a ITA Blockchain Clube, que o foco foi fazer racatom até até finalizar a faculdade. Assim, a ideia era a gente ter cada vez mais contato com várias empresas, tanto no Brasil quanto fora, participar de conferência e tudo mais. E então aí e o o que foi muito bom que a gente acabou tendo muita oportunidade para cada dia 2024. Então, em geral, eu sempre falo para quem quer começar como deve na web, acho que a Ron é é uma coisa muito legal. Hoje em dia tá tendo cada vez mais, eh, online também tem muito, então acho que vale muito a pena. E quando você tem oportidade de ser presencial, melhor ainda. Acho que é bem legal.

Eh, acho que sobre mim é isso, né? Ah, e daí eu me eu me formei em 2024 e daí eu eu assim eu eu gosto muito de smart, né? e Deffi em particular. Então eu apliquei para para Opens Applzinho de 24. Daí a gente teve uma teve um round round de entrevista e eu entrei em fevereiro de 2025 na Openzep. Tô lá eh já tem agora um ano e dois meses como engenheiro de smart contracts. Bem legal, open source.

Ah, eu já trabalhei num projeto principalmente de Deffi e interoperabilidade. Então, DeFi a gente fez o projeto da UNISAPUs, que é basicamente eh customização de disciplina da UNIS V4. E eh o que eu tenho focado recentemente é o que eu vou falar hoje, né, que são protocolos prochain, em particular o OIF, que é o Open Intent Framework, que é um projeto que aí que que a Open tá fazendo junto com a Etherum Foundation e com outros players bastante relevantes do mercado também, que é possente padronizar como é que a gente eh usa Intentes, né? Eu vou falar um pouco do que do que do que que

eu entende qual de qual que é a ideia e em geral, né? Como é que daí falando sobre a a toal em geral, como é que a gente por que que o porquê e o que e como que a gente repadronizar crochen e por que esses esses standards existem, né? Então sou eu aqui se alguém quiser seguir. Eu sou desenvolvedor open source no open appling, tá? Eh, a primeira a primeira pergunta que a gente faz é por que a gente tem tanto standard, né? Na Etheréum, para quem para quem é desenvolvedor, a gente tem vários, a gente tem vários vá vários. E por que que é que é importante a gente fazer isso para pra crochin em particular? Eu

acho que o principal e daí tá um dos focos da Open Zeplin, eu acho que é escalar Etheréum e as e as e as leer dois. E pra gente poder escalar, a gente precisa que elas se comuniquem. E então a gente tem várias redes, várias eh blockchain de segunda camada, até layer três hoje em dia. E a gente precisa que elas se comunicam, que se comuniquem entre si. Só que eh uma uma coisa muito interessante de de defi, talvez acho que o ponto mais interessante é composabilidad, né? Hoje você tá numa mesma rede, né? Sei lá, você tá na Etheréum, você consegue fazer uma posição na AV. que integra direto com a Unisap, que integra direto com a

Pendula, por exemplo. Então você tem consegue usar vários protocolos ao mesmo tempo e criar e criar um produto em cima disso. Só que quando a gente está entre vários blockchain, a gente tem eventualmente vários protocolos em diferentes redes e você e e é difícil usar a composability que a gente tem entre eles e entre chames, né? Então, para que a gente consiga fazer isso, a gente precisa ter padrões, que é se todo mundo manda mensagem e se comunica da mesma maneira, você consegue e isso é um padrão aberto, né? também o foco é é tudo isso é é é open source, as pessoas conseguem usar essa essa composability de maneira nativa. E por último, mas não

menos importante também um problema que a gente tem eh eh principalmente em Prochin, é vendor lockin, né? Então, talvez vocês já tenham tenham tenham reparado de várias vári vários vários protocolos muitas vezes lançam, por exemplo, em parceria com algum padrão, sei lá, o padrão da Legiira, o padrão da Tinink ou outros padrões. E várias vezes, eh, eles vão ficar presos, porque se você usa alguns tipos de padrões, eh, você e e se usa isso, né? Porque esses essas empresas são empresas com com fins lucrativos e elas querem dominar o mercado, mas o ponto de vista

de quem tá lançando lançando um token, por exemplo, é muito ruim, porque você fica vai ficar preso naquela camada de interoperabilidade. Então, se no futuro, por exemplo, eh, a Liro lançar, botar si, por exemplo, que é uma coisa que eles talvez coloquem, vai ficar bem mais caro para todo mundo que tem o FT, por exemplo. Então, e e isso e e em particular, esse esse protocolo, por exemplo, é bem difícil de você sair e ir para outro, né? que você é porque isso já tá bem nativo no token. Então a gente quer tentar e se a gente consegue ter padrões open source que todo mundo usa, a gente consegue forçar um pouco as as pessoas a não ter tanto vender lockin, então elas vão ter liberdade. Porque,

por exemplo, se eu tenho dois provedores que usam o mesmo padrão e um tá muito caro, eu posso simplesmente sair dele e plugar em outro. Isso me dá liberdade para eu para inclusive de de competição entre os dois. E eu consigo também diminuir preço, eu consigo aumentar segurança sim, mas se eu não tenho essa possibilidade vou estar preso ali para sempre e e a segurança, se tiver algum problema também vou estar preso ali. Então, pensando ah, e daí, só que aí tem sempre aquele problema, né? Eh, a gente tem muitos padrões, então se a gente tem cinco padrões, a gente tá criando mais um.

Eh, a gente tem que tomar cuidado para não ter seis padrões que cada um que cada um vai vai usar de um jeito diferente. Mas a ideia aqui é a gente criar algo bom, eh, open source, todo que seja simples o suficiente para todo mundo usar, mas ao mesmo tempo tem opinião suficiente para ser para ser relevante. Então, a gente vai começar primeiro na camada mais baixa que é o e rc7786. A ideia desse desse padrão aqui, ele é de ele ainda não é de intentes, é outra, é bem mais é bem diferente, mas é quando a gente quer mandar qualquer qualquer mensagem de maneira abstrata entre eh

qualquer entre duas entre duas duas duas blockchain. A ideia aqui é ser algo parecido com o que o HTTP é, tipo assim, você padroniza como é que funciona um header, como é que funciona um body de um de um request, assim como a gente quer padronizar como é que o RC7786 vai ser. E daí para isso ele funciona da seguinte maneira, né? Você vai ter eh ele é bem a ideia é que ele seja simples, então a gente tem ele é feito para para as pessoas poderem criar em cima dele, né? Então, eh, sempre vai ter um protocolo de interoperabilidade, eh, é, que, que, que que, que que vai ser o que, que vai est underline, que

vai est usando o 7786, porque, por exemplo, pode ser que se porque vai dependendo do nível de segurança e do nível de confiança que você tem. Então, por exemplo, pode ser que seja um MSIG, pode ser que seja um protocolo super descentralizado ou a ideia é que você tenha liberdade para escolher de acordo com a sua necessidade, né? Então, a ideia aqui é que a gente tem a source chain e a destination chain e a gente tem esses gatways aqui. O gator vai ser um contrato que ele vai basicamente eh traduzir qualquer ele vai traduzir e padronizar qualquer coisa que um sender vai que ele mandar para uma uma mensagem padrão para mandar para outro para

mandar para outra outra chain. Então a ideia aqui é que, por exemplo, digamos que eu tenha eu tenho esse protocolo de interapide aqui. Pensa que esse inter protocol é a layer zero, pensa que é a tinc, pensa que é axel que também é um dos um dos fundadores desse desse standard, por exemplo, eh pensa que é qualquer protocolo de interoperabilidade aqui. E a ideia é que esse protocolo ele sempre vai ter esse esses dois caras, um outbox e um inbox, que é basicamente eh outbo vai ser um contrato ou não prec ele vai ser algum tipo de evento, alguma coisa, eh, que que a gente vai chamar aqui e na minha outra team eu eu eu

sempre tenho um inbox, é quem vai mandar as minhas mensagens. Então, eh, a ideia do desse desse standard aqui é que, por exemplo, aqui a gente pode, a gente vai vai padronizar. Então, por exemplo, digamos que eu queira mudar de um protocolo de interoperabilidade para outro. Este gateway aqui, ele vai, eu, eu, eu mudo de gater, mas eu mantenho a mesma interface. Então aqui eu vou chamar e esse gate, ele tem uma função que chama send message. Eu vou chamar a função send message do do mesmo jeito e não vai mudar como é que ela vai ela vai funcionar. Ela vai funcionar do mesmo jeito, mesmo que eu use um protocolo de mensageria diferente. Essa é a principal

ideia. E daí como desenvolvedor, né, a gente precisa fazer duas coisas, né? Eh, a gente tem que saber qual que é o é o gateway e daí para bim, eh, chamar essa esse send message que você vai padronizar com o endereço com o caldito que que você vai querer para mandar e o receiver, esse o contato que vai receber, ele tem que também implementar uma certa interface. Então, ele implementa uma interface específica para ele poder receber. Então, os desenvolvedores de de apps, no caso, a ideia é que eles vão eh desenvolver o sender e o receiver. E daí isso aqui tudo a gente já tem. Então você pode eh escolher qual gateway que você quer e

vai tá acoplado, que a gente chama de adapter. Ele vai est adaptado a cada a cada protocolo de interagir mandar mensagem. É como que ele funciona? basents. Essa aqui é é a função send message, ele tem basciente um recipiente, o payload e os e os atributos. A ideia é que ele de fato seja bem simples, eh, para que para que bastante você consiga fazer com qualquer coisa, né? Eh, o que que é esse recipiente aqui? Eh, tem um novo padrão, eu não coloquei na apresentação, mas vocês podem dar uma olhada. é o eh 7930, acho que é acho que é 7930, que é o

interoperable address, que é basicamente uma maneira de padronizar eh endereços em qualquer rede, né? A gente tem alguns padrões, é, como a gente tem alguns padrões, eh, por exemplo, tem um que é o Cape 2 e o Cape 2 e o Cape 10, que são que era que era chanostic e interopable e interropable standard, é o cap, que era aquele padrão que a gente tinha string. Então você tem, sei lá, o eming ID e a string e e o e o endereço. Só que isso é muito bom para pro ser humano ler, mas pro contado inteligente não é muito eficiente, né? Porque a gente não tem que ficar trabalhando com string a

nível de contrato. Então para isso, a gente foi foi criado esse esse padrão que é um padrão que meio que faz um endereço binário, eh que daí padroniza eh como qualquer uma qualquer qualquer rede vai vai ser vai ser chamado. Daí isso tanto para EVM quanto para não EVM. A ideia é que você vai ter alguns bytes falando, ah, eu tô, eu tenho nesse tipo de de rede, tá? Por exemplo, eu tô numa IVM, eu tenho esse identificador que vai ser uma T ID que vai ter tantos bytes e daí eu tenho o endereço mesmo. Então, a ideia é que isso aqui vai funcionar para para Solana, Bitcoin e qualquer outro outro padrão. Então isso isso a gente também tem focado bastante em usar. Eh, a

Openep também foi foi ajudou a fazer esse standard de próprio Vitalic. Eh, também é é que tem uns uns 15 autores, mas ele é um dos autores desse standard também. Mas então na essa mensagem aqui, ela vai usar esse padrão eh para interpredas, que vai ser um bytes. O payload aqui é o seguinte, esse recipiente, né, a ideia é que ele seja aquele esse esse endereço aqui, ó, esse 7786 receiver. Esse endereço ele vai ter que implementar uma função que é a interface, ela vai uma interface que a função é execute message. Então basicamente você vai chamar o

esse gateway na lá na minha change destino, vai chamar o meu receiver um payload específico. Vai ser esse aqui. Então basicamente você vai você vai criar você vai mandar o endereço nesse nesse padrão. é binário e também vai passar o caldeta que você quer para chamar mensagem. Então, basicamente, vai ser isso que vai ser chamado direto. Eh, esses atributos aqui, isso aqui não é obrigatório, mas é um padrão, porque quando você tá aqui, pode ser que o seu protocolo de ou interoperabilidade tenha diferentes atributos. por exemplo, vários protocolos desse, você tem que pagar uma

FIE e daí pode ser que você pague uma FI em em token nativo, em, mas também pode pagar no token do tal protocolo de interoperabilidade. Então você precisa e daí você tem que comunicar isso de alguma maneira, né? Então, a ideia é que eh o gator ele vai ser específico para cada protocolo. Então, a gente então cada protocola vai ter uma lista de atributos possíveis que isso tem que estar documentado, mas aí se quando for necessário você pode passar esse esses atributos para eh customizar como é que você interage com uma pergunta?

Eh, isso aqui. Ah, tá. A a pergunta é a pergun a pergunta dele é sobre a Mercopo se a gente vai precisar eh verificar a a Mercur na change destino. Então, nessa camada aqui é abstrato. Então, o seguinte, a gente quer deixar o nível de assim, você vai usar o gate que você achar mais mais necessário. Por exemplo, se você tá numa, quer usar a Mercur Proof, por exemplo, eh, você tá usando, você vai ter o mesmo tempo que a que a que a bridge nativa, né? E a

bridge nativa num rollup otimistico demora 7 dias. Então, é um nível de é um nível de segurança grande, mas ao mesmo tempo é um nível com eh de tempo maior. Então a ideia é que nesse nível nesse nível aqui ele não ele vai depender da implementação. Então, por exemplo, você quer fazer um protocolo aqui que em que o relayer é só uma multig, por exemplo, a relay é uma brief, você pode usar esse esse padrão ao mesmo tempo em que a gente também na na Open a gente desenvolveu junto com a árbitro um protocolo chamado broadcaster, que é um protocolo que usa eh Merklef para você verificar isso. a gente usa, ter

consegue, vai ter o mesmo nível de de confiança que a que a Bridge nativa e você consegue mandar mensagem entre qualquer dois rollaps, basicamente. E daí você pode usar o broadcaster, que é o RC 788, que é outro standard, junto com esse aqui. Então, por exemplo, a gente você pode mandar uma mensagem que underline vai est usando o broadcaster para mandar para fazer o broadcast da mensagem. Daí o broadcast vai ser o receip bastante, vai. Então é assim que ele vai funcionar. Então aqui essa ideia nesse nível é bem bem abstrato e daí você pode escolher diferentes tipos.

>> Tá. Ah, tá. É que eu não Ah, ã. Esse receiver é um GTI global ou um contrato por usuários de ordenação? Tá, boa pergunta. Eh, existe um get global? Não. A ideia aqui é que cada assim, ah, você a gente pode ter várias camadas. Eh, a ideia a princípio é que o que você vai ter um gator para cada protocolo de interoperabilidade. Então, por exemplo, a ideia é que, sei lá, a Lerziro teria

um a ah ou ou pode ser inclusive nativo, né? Aí assim, idealmente, no mundo ideal, eh, isso seria inativo, não é que a Lerziro tem um contrato que daí vai ter um outro contrato em cima dela que vai adaptar. No mundo ideal, a Leriro ou a Tinlink ou qualquer outro protocolo já criaria os contratos usando esse padrão. Só que isso não é muito ainda ainda não é verdade, né? Então, a gente vai precisar de um contrato eh anterior para para falar com ela. Eh, só que e daí tem isso, né? E o que e fora isso, uma possibil e só que e daí idealmente os

contatos, os novas brides daqui pra frente que forem criando, idealmente usariam esse protocolo, esse standard que daí a gente padroniza para todo mundo, né? Se isso é realístico ou não, é difícil dizer, mas a gente tá tá tentando eh para que esse padrão se use sobre a segunda a segunda pergunta, não, eu o mecanismo de de ordenação é com certeza um problema, eh, mas não nível desse padrão não existe. E eu não sei de nenhum protocolo que faz isso nativamente. Sei, tem alguns que você consegue tentar ordenar, mas mas você não tem como controlar a ordem que eles chegam, que você pode ter algum tipo de customização, por exemplo,

ah, se você tem algum tipo de noms, por exemplo, que se uma mensagem chegar antes da outra, você reverte, depois você tenta de novo, depois na ordem correta e daí você executa de um e daí você dá um retry, né? Porque aqui você você p em tese você poderia tentar mais de uma vez, mas nativamente não. Esse problema de de ordenação a gente não resolve aqui por esse esse standard, não. Eh, pergunta >> sim.

Caso do >> Sim. Exato. >> Sim. Exato. Aqui é bem é bem abstrato mesmo. Essa aqui é para ser a camada HTTP e daí você vai criar a camada financeira em cima. Inclusive a gente também lá, se vocês forem lá o pinapeplin contracts, a gente tem tanto isso, tanto esse standard quanto o standard para o ah, é bridable, é acho que é fungible, bridge fungible, então para fazer breed de token e RC20, bridging de bridge de NFT também usando

esse standard. Então, eh, tem um padrão, é o, acho que é 802, talvez. É que é muito número, gente, mas tem alguns padrões já. E e daí a ideia é só que a ideia até para não ter vendor lockin é que eh você tenha a breed em cima do token. Então o token em tese ele não tem ele não tem uma eh ele não tem a bridge nativa nele, mas aí você cria em cima dele. Então, basicamente o que você dá eh quando a gente usa esse padrão aqui, você dá, você cria uma breed e você dá um poder de mint burn para ela. Então, a quando você quer fazer uma uma troca de

tokens usando esse padrão aqui, você vai dar um burn na chain, mandar a mensagem, o recipiente que também tá white listed na ultra chain vai receber e vai fazer o mint. Então assim, isso é o isso é inclusive isso aqui a gente depois vai falar eh a gente vai falar de de intentes. Isso aqui é uma é uma comparação quando a gente fala de token, a gente tem pelo menos esses dois modelos, né? Uma é um um intent que a gente não tem nenhum minting burn, então é tudo uma uma mensagem financeira, mas não tem uma um um mting burn envolvido, enquanto a gente também tem padrões quando a gente tá falando dessa camada

mais baixa que a gente pode mandar uma mensagem de mint burn, por exemplo. Então são dois dois modos diferentes. No mundo ideal, assim, no mundo, mais uma vez, no mundo ideal, se se você tem chass, que elas t uma finite muito rápida e sei lá de sub sub de menos de de um segundo e se comunica com a layer do também em muito muito pouco tempo, não tem porque você tem, você só vai dar um burn que vai ser automático em um segundo você tá na na outra chain, é melhor porque daí você não perde valor, né? Porque você tá falando de intent é uma ordem. É.

Uhum. Essa semana não é aumentou. Sim. Eh, sim. Eh, neste o 7786, ele tem eh ele é meu agnóstico, como eu disse, ele tipo assim eh a pergunta dele foi se eh porque hoje quando você vai usar a brid nativa demora 2 minutos, ele ele ele perguntou se nesse padrão a gente também vai ter

vai ter este tempo. E a ideia aqui que do standard é que você vai ser agnóstico em relação a qual protocolo você vai usar. Você pode usar a brid nativa, inclusive, inclusive a, se eu não me engano, a Zyc, a bridge deles tem uma breed que é já no padrão RC 787786. Então você pode dar bridge nativa deles, que vai demorar os 2 minutos ainda, mas eh nesse padrão, então aqui a gente tá falando mais de padrão do que de acelerar por si só. Eh, só que inclusive nesse ponto, essa semana saiu uma notícia de fast finality para para 13 segundos. É na é na L one. Eu não sei

quando é que isso vai tá de fato operacional, mas pelo pela notícia parece que vai ser logo. >> Uhum. Isso. Exato. Exato. É exato. Quando a gente tá falando de de intent, a gente a gente tá falando de uma mensagem puramente financeira aqui e de um risco. Eu vejo um como um short time long. É um como se fosse um empréstimo.

>> Exato. É um é um empréstimo de curto prazo. Então o sover ele paga e depois ele recebe. Se como ele paga para receber depois, ele primeiro tem um risco de de não receber se der algum BO ali. Eh, e ele tem um tempo para receber que o tempo vai depender do nível de confiança da brid dele. E daí ele tem, inclusive eu vou falar depois no AF que a gente também é bem modular nesse sentido. Então, se você usar uma brid lenta, vai demorar para você pro sver poder dar o cliente nos tokens dele também. Então tem tem isso, mas é mas hoje em dia a solução mais rápida que a gente tem é de intent em que você transfere esse risco pro sver que vai usar diferentes oráculos.

Eh, enquanto no mundo que a gente já tem e que se quando a gente tiver eh comunicação muito rápida da lei um para leer dois, por exemplo, é faz mais sentido você ter usar padrões de mint burn, por exemplo, você não precisa porque daí você não tem nenhuma perca de valor, né? Não entende você ainda você vai ter que pagar a taxa do sover e tudo mais, enquanto que nesse modelo você não tem. Então é meio que é um tradeoff. Eh, e daí, claro, se você não tem a o plano de tempo, geralmente vai ser mais melhor em algum sentido. Você, ah, eu dou min burner aqui, mint e burn no chain e um min na outra, desde que você consiga garantir essa essa finance que vai

depender da sua bridge, basicamente de de qual protocolo você você tá usando underline assim. Eh, mais alguma pergunta? É, isso aqui é o padrão do recipiquent, né? Então, assim como a gente tem padrão de mandar mensagem, a gente também tem o padrão de receber. Então, basicamente, você quer um contrato que seja um recipiente, você vai implementar essa essa interface, que é basicamente implementar esta função. Eh, esse receive ID aqui é a mesma, é o mesmo sense ID aqui.

Esse send ID, o sender vai ser o a usou também usando esse binary interpable address também, que segue o mesmo padrão. Eu acho que é 7930, RC 7930 que padroniza isso para para qualquer chain. É, e o payload que foi recebido, né? Então, basicamente essa essa vai é isso aqui é o gator, né? E daí a gente vai daí você processa a mensagem desse jogo e daí você recebe isso e e daí você vai chamar o é você vai você vai executar e daí esse processo mestre aqui você vai basicamente fazer do jeito que você preferir. A ideia é que isso aqui por

exemplo pode ser uma breed, né? Então aqui você tem um gatorizado. Então um gatorway que é específico, que é o o gator correto, né? você tem que eh aquele é o gator daquela chain ativa. Daí você ness nesse process message é onde você vai, por exemplo, mintar um token, você vai verificar se o sender é o sender correto. Vai ness nessa payload aqui você pode mandar algum algum tipo de prova, por exemplo. Eh, pode ser que esse payload seja qualquer coisa, basicamente. E daí você vai fazer o, vai ter, por exemplo, a quantidade aqui, se for um mint em born, e daí você vai poder fazer o o mint na natinha que você tá. Então, eh, isso aqui é algo bem legal, que é o o quê? Um problema hoje é

você ter confiança em defense brid. Lembra que a gente tem vários vários protocolos? a gente criou a a Open Bridge, que é basicamente um padrão único em que a gente tem que a gente usa e vários como se fosse um multisig de bridges, digamos, se eu queira mandar uma mensagem da Etherum para base, por exemplo, só que eu não tenho 100% de confiança em todo nos protocolos. Digamos que eu acho que um eu tem três protocolos possíveis. Eu até confio neles, mas eu eu gostei de ter uma certa caso algum algum seja hackeado ou caso algum saia fora do ar, eu quero ter uma garantia que vai chegar na minha

na minha outra rede. Então eu posso fazer uma multisig 2 de três, por exemplo, em que eu mando a mesma mensagem para diferentes eh para diferentes protocolos. E daí quando ele chega lá na outra chain, eh, eu não tenho uma garantia de ordem, né? Como a gente comentou ordem, quando a gente tá falando, esse sistema de subidos é complicado, mas você garante que, ah, se chegar duas mensagens iguais, eu executo e eu não executo antes disso. Isso aqui pode ser, por exemplo, eh, até até inclusive falando do broadcast ali, usando usando mercen falou, eh, digamos que, por exemplo, lá, eu tenho essa mensagem, é esse protocolo que ele é trustless, só que ele demora 7

dias, eu tenho esse protocolo que demora 2 segundos. Eh, mas ele pode ficar fora do ar. Ou eu tenho dois protocolos aqui que cada um demoram, eles demoram 2 segundos, mas ficam fora do ar. que eu posso falar o seguinte, eu vou mandar pros três a mesma mensagem, só que se por acaso um deles forqueado ou eles ele não executar a mensagem, eh, eu posso, eu tenho um fallback de 7 dias, eu tenho um fall depois que eu tenho certeza que vai tá certo desde que a a bridge nativa, a bridge nativa funcione. Então, que é a mesma garantia da minha lei dois, então a não ser que ela saia fora do ar, eu tenho a minha garantia. Então, a acho que a principal utilidade que a gente vê pro broadcaster, por exemplo, que é esse esse padrão eh que verifica a nível

criptográfico mesmo com Mercur Proofs, é para ser um fall. Então você vai eh assim na tem dois dois casos ou você tem um um intente ou uma mensagem de valor muito alto, então sei lá, você vai fazer uma bridge de 10 milhões de dólares e você pode estar disposto a esperar 7 dias para não perder 10 milhões de dólares. Se for o caso, você espera e daí você tem a mesma garantia da LER 2. ou você até que você manda para outros protocolos, mas você tem como fback broadcaster em caso de de erro, por exemplo. Então você essa acho que essa é a principal utilidade que que a gente vê, porque usar no dia a dia algo que demora demora tanto é complicado, mas

ter isso como fallback é bom. Uhum. >> Sim. Aham. Seg o o gater já tá já tá depoado. Você pode mandar direto via Gater.

>> Aham. Sim. >> Essa. E lá dentro. Eu não sei porque us o o user per você vai geralmente vai mandar para um para um paymaster, né? Então, por exemplo, você não precisa mandar pro Pay, mas por exemplo, se você implementa uma 7702, por exemplo, então a sua, digamos que a sua implementação do 7702, ela também, ela também implementa o 7786 com com receive message. Então, ela é um

recipiente possível. Então a sua própria account abstractor já é o recipiente possível. Então você pode, por exemplo, o seu payload pode ter um approve um swap. Então você faz o approve swap, a sua a sua account com a sua conta na minha chain inicial, ela você faz uma call qual call s ele vai vai chamar o send message no gaten e vai vai passar como recipiente o próprio endereço dela, só que na outra chain, por exemplo, e daí o payload vai ser direto o payload de approve swap. E daí, só que aí ela tem que a sua a sua conta na outra chain, se ela pode implementar um 7702 e ela delega para e ela delega na e ela delega para ele

bastante. E daí você ela pode daí você executa. Claro que você precisa aprovar o o gateway como um executor, né? que é um, na verdade seria um, é 75, 70, é o 75, que eu falo em inglês, mas em inglês ou 75 é você tem, por exemplo, um módulo que segue o padrão RC 7579, você pode ter um módulo que é o módulo 7786, que o que o recipiente. Então, esse módulo ele implementa isso e daí ele e daí ele aprova o gateway como um executor. Então quando você chama o gateway, ele o gateway chama direto a minha a minha conta que é uma co abstraction.

Então se você usa se você usa um protocolo de interpalabilidade aqui no meio, você só você vai chamar a sua você a o seu user operation vai ser o send message pro gaten com com o payload que você quer na outra chain e daí você vai mandar direto pro Paymaster. você é pro PMAS da T inicial e daí ele vai mandar isso. Na outra t você vai ter o protocolo de interpalidade lá que ele vai mandar pro pro gateway na ida na aqui, ó, na destination. E o seu receiver ele pode ser a mesma, ele vai ser a Não, não, o receiver não é o PMAS. O

receiver aqui é a própria conta, só que usando só que usando o módulo que que habilita isso. Você não precisa mandar pro Paymaster. Isso é porque, por exemplo, o sender aqui ele é uma tem uma co abstraction, né? Então aí ou ele pode ou ele pode delegar se for uma EOA, mas se for um contrato, você só precisa ter você faz uma conta que que que implementa isso. >> Já tem já tem 700. Esse >> esse mózgo em particular eu não sei.

>> É exato. É um exato. Exato. Que esse módulo que daí você delega para isso, você coloca esse módulo, usa crochen. E daí você pode falar assim: "Não, eu o eu gosto do protocolo da relay, por exemplo, que é um protocolo que é meio meio que uma multiga, mas eu confio nesse nesse nesse protocolo. Ele vai ter um gator específico, você aprova esse gator e daí a sua conta ela habilita isso. E só que o sender ele é ele mesmo, certo? Porque o sender tá vindo da outra, então você fala só eu, só a própria conta pode me chamar. Então você garante que é é a própria conta chamando ela mesma, então você consegue e daí você abstrai isso.

Então acho que se fosse fazer eu faria algo nesse sentido. Fazido mais alguma algum alguma pergunta a gente online também? Show. Então, até agora a gente a gente falou desse primeiro modelo, né, de mining burn, de como que a gente faz transações mais eh um modelo abstrato de transações, que acho que é a primeira coisa que a gente veio com bridge e tudo mais. Agora a gente vai para intentar breed, uma breed reversa, porque ele também vai usar uma breed eh, que inclusive pode usar o 7786, só que ao contrário,

né? Aí, primeiro eu vou falar do RC 777 7683, que é um um standard eh conhecido, já tem quase uns dois anos agora, acho que um ano e meio. É, o open frameor ele implementa quase esse standard aqui, porque ele tem algumas falhas ou algumas coisas que ele não é tão eh não é tão otimizado, mas eu vou vou falar do RC do do RC primeiro e depois eu vou falar do OF que ele é parecido, mas tem algumas diferenças, só que a gente é porque o esse sistema aí ele tá sendo modificado, eh, só que ainda não tá Não tá. É, a a discussão é pública, mas não tá público

o resultado ainda. Eh, e daí, mas eu vou falar qual que é a ideia por trás dele, né? Basicamente aqui eu eu não eu tô basicamente só most vou mais mostrar qual achou que faz mais sentido. A ideia do intent é o seguinte, eh pensa que é com uma ordem, certo? A gente tá falando aqui que é que é o seguinte, você enquanto usuário, você tem é você tem SDC na Etherum, você quer receber ether na B, por exemplo, você tem algo assim, eh, você eh você enquanto usuário vai basicamente postar uma ordem no CH falando assim, ó, eu

tenho 1000 US SDC e quem me der um ou agora meio meio ether na base eh pode pegar esses 1000 SDC. Então você meio que e aí isso vai ser uma ordem, você vai deixar essa ordem assinada e qualquer e solver é a sua contraparte. Então o solver qualquer solver que vê isso vai falar assim: "Pô, eu topo e dar os os meio eter por esses .000." Então você o o solver ele vai f a ordem que seria fazer o pagamento na base nesse caso. E depois que ele fizesse esse pagamento na base, ele vai falar assim: "Agora eu vou provar que eu de fato fiz esse pagamento

para eu dar o claim nos tokens do meu usuário". Então, quando o usuário ele abre essa O e ele meio que dá um lock nos no nos tokens dele. Tem maneiras diferentes de fazer isso, inclusive tem maneiras que não tem tanto lock, mas em tese o o usuário ele dá um lock no nos tokens dele, o sover ele faz ele paga o output e depois ele ele o o software vai e e dá um claim nesses tokens, né? Eh, por isso que tem essa parada do desse shortterm long, porque como porque primeiro você tem um tempo de finality de entre as duas chans que você tem que que tem esse esse tempo que você tem que

provar que eu executei alguma transação na minha change destino para eu ir na minha change de minha inicial para dar o clain. Então, esse tempo e daí nesse tempo algumas as coisas podem dar errado. Pode ser que você não consiga gerar essa prova, pode ser que tenha algum delay, pode ser que ah, tem, porque aqui na ordem a gente tem algo, tem uma deadline de f, tem uma deadline de de expiração também. Então, o usuário pode dar um refund, então tem alguns riscos e por conta dos riscos tem uma taxa, né?

Daí por isso que aqui funciona na lógica de inputs e outputs. Eh, que inclusive pode ser mais de um o usuário, o que que ele fala? Ó, eu tenho tais inputs. Os inputs, ó, eu tenho um hetter aqui, eu tenho eh meio rapider, eu tenho 1000 USDC, tenho 500 USDT. E daí eu penso falar: "Ah, eu tenho todos esses inputs e eu dou todos esses inputs para quem me der o output de 500 de três aves na outra chain." Então, eh, esse essa ideia ela meio que abstrai um pouco de si. Por quê? Porque eu não tenho FI. Quando a gente é mais fácil pensar em FI, quando eu tô indo de USDC para USDC. Tá. Eh, eu tenho 1000 SDC e eu e eu vou te dar

aí na outra estudou 999. Eu tenho um SDC de taxa. Só que aqui a se a gente tiver falando de eh de do mesmo token, ah, eu tô em USDC, tô indo para base, a é mais fácil entender o conceito de fi. Só que se eu tô indo de de um de um token aqui para um token na outra rede e se eu tô indo de eventualmente múltiplos tokens aqui para múltiplos tokens na na outra rede, eu tenho vários inputs e vários outputs. É, o conceito de f ele fica meio complexo, mas basicamente o importante pro Sverinte, o Sver e daí o Sover ele vai fazer um trabalho que é complicado, que ele tem que manter muito bem traqueado quanto ele tá gastando para originar

esses esses fundos, porque ele tá pagando para receber e daí ele tá, digamos que ele tá pagando em e ele vai receber em USDC e tem um delay. Então ele não só não só é um é um um empréstimo de curto prazo, mas eventualmente ele tem um risco direcional do token também. Então, e e então a fi que ele vai ter vai ser, por exemplo, o quão bem ele consegue originar o token, que é para, digamos que eventualmente pode ser num exchange centralizado, ele consegue pegar muito barato ou mais barato, um pouco mais barato que o mercado, eh, ou alguma dex, alguma rota que ele consegue originar um token muito bem para ele dar um fio num preço bom para ele, para que dá que que

a FI fica implícita. A FI não tá explícitamente dita a FI é 1%. Vai dep assim, você ele meio que tenta calcular. Então quando você assina ou você como usuário, você vai assinar uma ordem, você meio que vai botar implista o o você tem que concordar com o Sver, né? Mas você vai botar uma F ali implícita para que o Sover queira executar. Só que o o a FI vai ser tão tão grande prover quanto ele consigo originar e dar o claim nos tokens num tempo bom. Se ele não conseguir não conseguir fazer isso, eventualmente ele pode inclusive eh perder dinheiro, fora as taxas de gás.

Então pro Sver aqui é algo um pouco arriscado, mas a gente tenta facilitar o máximo pro usuário e deixar um pouco do do risco pro Sver. Tinha uma pergunta. Aham. Sim, sim. E isso?

>> Ah, boa. É, a a pergunta dele foi sobre front. Front run. E não, e a gente protege sim. Isso aí não tem o risco de você dar um fio numa ordem e vir vi vir outro cara e dar um fio também. Eh, você não tem risco. O o que tem o risco é o seguinte. O usuário quando ele abre a ordem, ele tem dois tipos. Ele pode abrir uma ordem sem um sobre específico e daí qualquer sobrever pode resolver. Ou ele pode abrir para um sobre específico. A gente chama de é exclusivo, né? A gente pode abrir uma ordem exclusiva ou não ou não ou não exclusiva. Se for uma ordem exclusiva, só tem um server que vai conseguir lá dar o fio e ninguém mais vai conseguir.

Então não tem nenhum risco de front run. Eh, se você quiser uma ordem não exclusiva, eh, daí você pode ter vários olhando lá e ver, ah, essa ordem aqui é uma ordem boa e daí o primeiro que executar, ele executou e os outros não. E e daí, mas não tem risco de duas pessoas executarem a mesma ordem. Isso e isso não. O que tem é alguém executar na sua frente sobre uma ordem não exclusiva. E daí também tem um mecanismo de preço, tem o padrão que é o output é fixo e tem o dutch order que é o seguinte que é quando não é exclusivo.

Ah, eu eu vou deixar para ser qualquer um, só que quanto mais demorar para dar o fio, mais o menor é o output. Ou seja, o Sover, ele gostaria de esperar mais para dar o filme, só que como é público, é só o primeiro que vai receber. Então você tem uma uma maneira de criar uma competição para ver quem vai ser s que vai resolver que resolver primeiro. Então a gente tem eh exclusivo e não exclusivo. E a gente tem também dois tipos de precificação da ordem, que é no output específico ou com o d order. O que é mais usado mesmo é o output específico e exclusivo, que os os preferem que seja exclusivo até para não ter esse risco de de alguém na sua

frente e tudo mais, mas não tem o risco de ter um double spending, isso não pode falar fazer um >> Não, isso não. Por quê? É, ele vai ter que fazer. Eh, ele, ele perguntou para quem, para quem tá, ele ele perguntou se é possível múltiplos resolveram a mesma ordem. Não, ou pelo menos no >> é uma parcial no hoje no modelo que tá não, porque basicamente eh é é porque assim o que acontece, a

gente tem um output, quando você dá vai dar um fio, você dá um fio no output, não na ordem. Então é, e daí uma ordem pode ter vários tal de fudos. Só que a gente tentou fazer o mais gás eficiente possível. Então, quando você dá um fio, eh, não existe o conceito de, ah, esse, esse output é dessa ordem, isso é só quando você vai dar o clan, mas quando você dá, quando você dá um um set, um fio, eh você não tem esse conceito. Então não, a gente não traqueia eh todas as informações que seriam necessárias para poder fazer isso por uma uma questão de eficiência, eh para que a gente tentou fazer o mínimo de storage possível, porque gás, porque assim, o business de

intents ainda hoje é um business de margens muito pequenas. A gente tá falando assim de 03, 05% ou 01%. É um business de taxas pequenas. Então o gás nesse caso ele passa a ser relevante. Se a gente então a gente priorizou bastante ser bem eficiente em gas, só que para isso a gente, ou seja, a gente tem o mínimo de storage possível. Então a ordem de tudo ele é meio que construído em vez de stored. Então daí a gente não traqueia algumas coisas para ser eficiente. Só que daí para por conta da gente fazer isso, a gente por exemplo não consegue fazer um partial até e e também tem um problema de de

comunicação, né? Então assim, digamos, você faz um partial e depois você finaliza, mas aí entre um e outro você faz um submit para dar o claim. E daí o que que tá correto? É um ou outro? Ou seja, você tem vários servers para uma mesma para uma mesma ordem. Eh, quem que assim vai eu e daí? E quem que resolveu qual de qual ordem? Eh, isso é possível, só que daí você ia ter que ter muito storage, você tem um contato com muito storage e ia ser muito ineficiente em questão de gas. Então, a gente não tem isso. Então, uma ordem só pode ser resolvida por um sover. Inclusive, eh, o server de uma ordem é o server do primeiro output. Isso aí é um que é o

seguinte, se você uma ordem tiver múltiplos outputs e vai e diferentes resolverem diferentes outputs, o ganhador é o primeiro server. Então você tem que verificar se for uma ordem exclusiva, então você sempre tem que ver, tem que dar um fio do primeiro output primeiro, porque se você der um fio do segundo e outra pessoa dá o fio do primeiro, o quem vai dar o clim é é o é o do primeiro sempre. Então você tem que aí dos segundos, digamos que tem 10, do segundo pro 10o maior não importa, mas o primeiro output ele sempre tem que ser o primeiro a ser filtro, porque senão você ou se for exclusivo também aí não importa também, que daí você pode

colocar em qualquer ordem, mas se for não exclusivo tem que ser o primeiro primeiro output. Isso aí é um é um é um requisito que a gente tá a gente tem documentado. Então aqui eh essa aqui é a primeira ideia do do 783. a gente não esse essa resolve fora e resolva a gente a gente não tem, mas a ideia aqui é o open e o open for, que é o seguinte, é basicamente abrir ordem, então você o usuário que ele vai chamar uma ordem daí tem duas maneiras. O usuário pode chamar direto on change na função open e daí o message sender, né? é quem tá abrindo a ordem open ou open for, que daí é quando o usuário faz uma assinatura e daí tem

um relay ou o apodinatura e vai chamar a função open for. Então, provavelmente para vocês vai ser mais a função open for, que é basicamente isso. Você vai chamar a ordem, a ordem que o usuário assinou, a assinatura do do usuário e vai e vai mandar para ele, basicamente. Eh, então aí essa aqui é isso aqui. Eu vou eu vou passar porque é basicamente isso. Eh, o Então assim, a ideia é a seguinte, ah, só para explicar, né? Eh, a gente vai, quando a gente for fazer o intent, a gente tem essa ideia de ordem, né? a gente vai ter uma uma chain de orbit e uma chain de de destino. E a ideia é que a gente vai ter dois settlers, um origin settler, no caso a

gente mudou para input settler, é que aqui é o antigo 783, mas é a gente mudou para input, então é o input settler e o output settler. A ideia é que isso vai ser um singleton em cada champ. Então, cada rede vai ter um um input settler e um output settler. Então, todo mundo, inclusive diferentes protocolos, vão chamar open e open for para abrir ordens e vão chamar a função fdens. E daí aqui que a gente a gente garante que não vai ter não vai ter duplicidade no pagamento, porque para você resolver você não vai transferir os tokens pro usuário. Você vai chamar fio e daí o fio

vai transferir pro usuário e daí e daí se já foi field revertão tem o risco de da double spending aqui. Esse aqui é o como é a ordem, né? Eh, a ordem que o usuário assine é assim. Então esse user aqui é é o seguinte, é porque pode ser que o quem tá chamando a função, na verdade não é o próprio usuário, é um intermediário. Então na ordem você pode botar o usuário. Esse usuário aqui é quem pode dar o refund se for o caso. Daí tem o nomes, né, do da ordem. E daí é isso. A a ordem tem ID, a inspiração que é o que é o que acontece. Você abre a orn com input e com output, certo? Ela só vai ser field se algum software ver lucro naquilo. Então pode ser que ela

nunca nunca seja field, só que ela tá lá. Então você bota uma inspiração. Depois daquela inspiração, você pode dar um refund, que é o esse usuário aqui, ele ele vai ser o ele ele vai conseguir dar refund. Só que daí tem um risco, né? Esse daí aqui é o tempo que você deu o claim. Se o solver resolveu, mas ele não conseguiu provar antes da inspiração, o usuário também pode dar refund. Então aqui esse tempo aqui ele tem que ser porque por exemplo lá eu boto uma eu abro uma ordem queira em 30 segundos. para ele eu resolver se

chamar função >> na outra cha ele não sabe, entendeu? E e digamos, ah, eu boto inspiração que de não tem riscos. Aí assim, é porque o Solver ele vê, se ele vê que o que que a inspiração em 10 segundos ele não vai resolver, ele não vai pegar porque ele sabe que é golpe, mas ele tem que pegar de algum jeito. Ele pode conectar na UNISUAP e comprar o token na hora de dar o fio ou ele pode ter um estoque. Então tem a gente, inclusive esse é um problema, tipo assim, como é que você faz o rebalancing? que daí você tá em várias redes e daí digamos, a cara, eu eu fui gastando os tokens de uma rede para dar o fio e eu recebi os tokens na outra rede, como é que eu rebalanceio para eu

ter estoque suficiente? Eh, e daí esse o business do solver, ele é como que ele origina o token da maneira mais barata possível e para ele ter a mar possível. Então, o business dele principalmente é rebalancear os tokens e originar os tokens da forma mais barata. E daí como você vai originar? Depende de como você tem. Você pode ter um estoque, eh, ou você vai ter que comprar nodex ou e daí você pode ter que, por exemplo, você pode ter que redear um pouco para você, eh, para você não tomar o risco de direcional. Então, eventualmente, você tem um estoque de um token que ele é volátil, mas você faz um head na Hyper Liquid, por exemplo, para diminuir esse

custo. Só que daí isso isso é um custo que você tem de R, né? daí esse custo a sua temente para pagar isso, por exemplo. Então, o business do Svergem pequena, tá? Então, muitos dos S hoje em dia eles ainda ainda são ão são pagos para existir. Mas tem daí tem rotas que mas são melhores ou piores, enfim, tem. É complicado. Se aí a inspiração funciona assim. Então, sei lá, eu vou, eu abro uma ordem com inspiração em 10 segundos, um sover resolve em cim, só que ele resolveu, só que ele tem que mandar a mensagem de volta e o protocolo de mensageria demora 10 minutos. Aí já era. O o usuário ele recebeu os token.

Só que como o cara, o sover não conseguiu provar a tempo, o usuário vai lá e pode pegar um refund. Então o sover ele tem que tomar tomar esse cuidado. Em geral o que acontece? A gente tem um um API também de agregador. Então o usuário ele vai falar: "Ó, eu quero comprar isso aqui." O server ele vai dar os parâmetros que ele aceita e os e o usuário vai assinar. Então o S vai falar assim, pô, uma inspiração de dois dias ou não, ou se menos se for para rápido uma inspiração de 5 minutos, pelo menos um fio aí ali além da inspiração tem a line de fio também que é o tempo para dar o fio que não precisa ser não precisa ser igual a inspiração, pode ser diferente. Tipo assim, ah, eu você tem

que dar um fio em até 1 minuto, mas você tem até 5 minutos para dar o clan, entendeu? Então essa é a diferenças. Ah, e aí a gente tem a questão do oráculo, que agora é uma é uma coisa bem importante. Eh, lembra que a gente tem as provas, né? Ah, eu fiz o claim que eu denuncio na minha change destino. Essa prova é muito abstrato, n, eu falo prova, prova, mas o que que é isso? Isso eh como a gente quer ser um protocolo modular, você quando você ó, você abre uma ordem, você usuário e over também eles vão concordar, vai ter uma é meio que uma que uma assina e o outro executo. Então os dois têm que concordar nos termos. Vocês vão escolher um

oráculo ou dois, né? Um defino e um de de input para falar qual que é o nível de confiança que vocês têm. Esse oráculo vai falar é o seguinte, ó. num minha change input, eu vou chamar o meu input oracle e ele vai responder sim ou não. Aquela ordem ela foi field ou não? Se ela foi field, então o meu sover pode dar o clan. Se ela não foi field e já passa o tempo de inspiração, meu usuário dá o refund. Eh, então, basicamente, esse esse oráculo ele vai dizer isso. Daí pensa e daí esse oráculo ele e mas aí como é que ele tem essa informação, né? Eh, a gente tem um uma interface de como que esse oráculo é e a gente tem alguns exemplos também que é,

mas basicamente e a gente vai tem um a gente você vai vocês podem usar diferentes protocolos. Então, por exemplo, o que a gente vai usar na Pinv como a demo e como padrão é o broadcaster, que é que é o que acontece. O broadcaster é o que é o que eu falei que é o modelo eh de Merkleproof em que você manda mensagem e você verifica a a Miracle proof direto trustless, né, na outra chain. Daí a gente criou um oráculo em cima dele. Esse oráculo ele vai verificar a prova da outra chain. Então eu sei lá, eu dou um f, quando eu dou um f eu dou um broadcast. Eu quando eu dou um broadcast eu vou basicamente vou escrever em storage lá e eu consigo gerar uma prova.

Então, na minha change input, eu vou lá, mando essa prova e daí no meu oráculo, né, se o meu oráculo verificar, ele vai dizer true, então daí eu consigo dar o claim, entendeu? Então, do ponto de vista do solver, ele vai chamar a opção que chama finaliz, que vai tá chamando o o oráculo. E a ideia é que daí daí o que a gente tem hoje é um oráculo com a Hyperlan, que acho que é o mais usado, um dos mais usados. Tem um oráculo com a Wormhole, também tem o oráculo com Broadcaster. E tem um que não é muito usado, que é com Bitcoin, que daí eu sinceramente nem tenho certeza como funciona, porque ele usa Bitcoin nativo, umas verificação lá lá no Bitcoin. Eh, isso é que a gente junto com a Alify tá para usar isso com

Bitcoin, mas basicamente a gente tem pelo menos esses três oráculos. Eh, o a hyper lane a warm roll para mais rápido e a o broadcaster como um fall que é bem rápido, quer dizer que é bem rápido, que é bem seguro, não tão rápido. >> É. >> Uhum. Vai ser uma >> é, você tá falando do broadcaster ou você tá falando do do oráculo em geral?

É porque o que o que eu falei foi foi do broadcast sobre Stories. É >> isso. É os oráculos eles funcionam de maneira diferente. Um oráculo o padrão é eu sempre tenho que mandar uma mensagem da minha chain de destino pra minha chain de origem. É, e daí por isso que o a breed o o intent é quase que uma uma bridge reversa, porque do ponto de vista do usuário, ele abre a ordem, o sover vê essa ordem e resolve na hora. Então para ele durou 2 segundos. Só que agora, agora que começou pro Sver que daí o Sver ele resolveu, só que agora ele vai ter que usar uma bridge de verdade, que daí inclusive essa bridge pode usar o 7781, um oráculo usando 778, por exemplo. Aí essa breed vai aí daí no caso o oráculo, né? O oráculo ele tem as

páginas, ele vai usar uma brid no meio. Então a ele é ele é modular, mas a ideia é que você vai mandar uma mensagem pelo oráculo de destino para o oráculo de de input, né, de de início. E daí quando essa mensagem chegar você consegue dar o claim entendeu? É, você pode fazer, você pode fazer esse oráculo, só que o seguinte, o usuário ele assina, assim, é uma concordância, né? É, o usuário ele assina a ordem e você executa. Então, os dois t os dois têm risco. Então, você como usuário, você tem você tem que eh confiar que aquele oráculo tá correto, que ele não é

malicioso e você sover também. Porque, por exemplo, se se o solver o oráculo pode ser malicioso pro usuário ou pro usuário tomar vantagem, porque vai que é um um oráculo que nunca a mensagem nunca chega, aí o o usuário ele recebe os tokens lá e ele dá refund. Ou então o contrário, pode ser um um oráculo que sempre fala assim e daí o o sover sem dar um fio pode dar o claim. Então, as duas pontas são importantes. Eh, e os e o no caso o usuário tem que concordar com os oráculos e o solver também. O em geral como que vai acontecer o seguinte, a gente tem o agregator, o usuário vai chamar o API e vai falar: "Ah, eu tenho tais inputs, eu

quero tais tais outputs." E daí o o solver ele vai usar alguns oráculos e ele vai mandar como resposta e daí o usuário vai verificar se ele se ele confia naquilo e assina. Então daí você meio que tem uma concordância do solver com o usuário para executar aquele interno. Então agora a gente chegou no Open, até agora a gente estava só padronizando, mas mas eu já tava falando do OAF. Eh, aqui essa aqui é é é uma apresentação também de como do que que a gente tá fazendo e tudo mais. Eu vou entrar um pouco mais em código aqui. Eu tô com código aberto também. Mas o que que é o Oif, né? Basicamente é esse framework open source que a gente não que não é só o os contratos, a gente tem os contratos

de de abertura e de resolução de intentes, mas a gente também tem o Svergator. Então tudo isso é é é open source. Então, é claro que, como eu falei, o business dover é fazer, por exemplo, a originação do token para otimizar o a a FI dele. Então, isso a gente não faz, mas dado que você tem o token de alguma maneira, dado que você origina ele de alguma maneira, assim, tem um open source que vocês podem usar, tá? Tá tudo open source, tem um agregator também que é que vocês vocês vocês podem usar já.

Eh, como ele funciona aqui? Eu já expliquei um pouco, mas eu vou basicamente um pouco mais aqui. Se aí se vocês conseguem ver. >> Ah, tá verdade. Eu não tinha certeza se você tava vendo isso. Show. Beleza. Então aqui, ó, a gente Vamos, deixa eu pensar aqui. Eh, beleza. Vamos por passos aqui. Tá vendo? Eh, como eu falei, ó, a gente tem um usuário interagindo com a com a UI. Aqui, a primeira coisa que ele vai fazer, ele vai dar um get code, ele vai pedir uma cota, uma cota pro pro Silver, que daí aqui ele ele ele vai tá usando o agregator, que é o seguinte: "Ah, eu tenho 1000 SDC, eh, qual que é um preço

bom para pra Eter? Quanto de você me dá por isso?" Porque apesar de que o o usuário ele vai assinar um input, um um um input, um um output, ele tem que saber um valor que faça sentido, senão ninguém vai executar a ordem dele. É, então ele ele ele pede uma cota e daí o Sover/agregator vai dar uma cota para aquilo e vai mandar uma ordem, ó. Eh, se você se você topar eh esses preços aqui e esse oráculo eh assina isso, a assina essa ordem e daí basicamente o usuário ele vai verificar na I se ele concorda com aquilo, né? A I também tem que verificar os oráculos que ela que ela construia. Acho que isso é

bem importante. Então tem que ter um uma list de de oráculos lá. Eh, e daí basicamente o usuário assina isso, manda pro prover. E aí agora a gente vai começar, né? Então o sover agora ele vai abrir o intent. Então pensa, a gente tem aqui, ó, a or assim essa a chain B é a cha de origem e a chain A é a cha destino. Então na minha cha de origem eu abro o intense. Então eu tenho meu input settler aqui que eu vou dar um open que aqui lá eu vou pegar a minha ordem e vou chamar a função open. Quando eu chamar essa função open, eu vou dar um lock no nos nos tokens. Então os tokens do usuário vão ser loped aqui e daí tem algumas maneiras. Aí daí pode ser open

for também. Então você pode dar ou ou você que vai ter que dar um approve direto no no contrato do input settler. Ou então você tem a gente tem dois tipos de assinatura, tem uma permit, daí você a sua prova o permitir uma vez e também tem o 3009, que é o padrão do SDC que só o SDC usa. Mas também pode ser. É, e daí você dá e você vai dar um lock nos nos tokens aqui. Aí, aí, beleza. Aí por aqui acabou. Agora depois de open, o usuário vai f, tá? E o usuá o sover, né? O server vai dar um fio. Então, lembra, esses dois contratos aqui são singletons, né? Então, eu tenho um contrato por chain e depois de open, ele

vai lá na minha chain de destino e daí ele vai dar um f. Aí o o Sver, então ele tem que ter os tokens na rede de destino para para apagar, né? E daí quando ele faz esse fio, ele vai esse tokens vai ser transferido pro usuário. Nesse ponto o usuário já foi, ele já já recebeu, ele já recebeu os tokens dele agora. E agora é a parte que o Sober vai ter que dar o clan. E daí tem duas partes, é, tem dois tipos de oráculos. Tem um oráculo que quando que o fio já chama oráculo e já manda mensagem. E tem oráculo que são dois, duas partes separadas. Em geral vai ser separado. Por quê? Eh, a ideia é que você possa mandar mensagem bet, né?

Porque pensa o seguinte, lembra que eh crashin as mensagens tem são um pouco mais caras, então geralmente você não vai querer dar eh e também lembrando que a margem é apertada, você não vai querer mandar uma mensagem crochin para todo o intente. Você vai fazer um back, então geralmente vai dar uns fil em vários. Então, sei lá, em uma hora você dá um fio em 20 anos, aí você dá um fio em 20 e daí no fim de cada hora ou pode ser menos tempo, de a cada certo tempo, você vai pegar um bet desse tipo assim, ó, eu tenho peguei esses 20 intentos aqui, daí você vai dar um submit. É isso, esse padrão de submite ou não, ainda vai depender do oráculo, mas em geral é assim, eh, vai no oráculo de destino, então você chama de destino pro de

origem, né? às vezes é a gente fica meio meio confuso. Então, no oráculo de destino, eu vou mandar essa prova pro meu, então é basicamente o meu oráculo de destino, ele vai ver se o meu output cent se se o se o as ordens realmente foram field e se foram meu oráculo de destino vai mandar essa mensagem via hyperl, via ou via broadcaster, por exemplo, pro meu oráculo de de input. Então ele vai do destino pro input e daí esses aqui pode vai ter algum tempo. E daí e daí tem, por exemplo, tem contratos em que você precisa chamar o contrato para receber a mensagem. Eh, tem protocolos, né? E tem e tem protocolos automático. Em geral é

automático. Eh, hyperl é automático. Você manda mensagem, você já paga o gás aqui e daí o é automático a recepção na change de input. No broadcaster não. No broadcaster você vai ter que ir lá e validar a minha e validar o seu validar a mensagem. Então é o seguinte, você vem aqui e daí aqui quando aí daí é eventualmente essa mensagem chega e daí basicamente a mensagem vai dizer: "Não, essas esses intentes aqui foram todos field e daí todos eles vão estar como true lá no meu oráculo." Aí depois disso acontecer o meu solver, ele vai chamar um input setter de novo. Então ele

chamou uma vez para abrir o intent, agora ele vai chamar de novo para dar o settlement que vai ser o quê? Esse meu input settler, ele vai validar com o meu oráculo de input para ver se de fato a mensagem chegou e deu tudo certo e se sim ele vai poder dar o cliente dos tokens que o usuário deixou lock lá no começo. Então esse é o fluxo completo. Aí claro, né? Se não, aí tem aqueles casos, ah, se a mensagem não chegou a tempo ou se o se o server nunca executou aqui, vai tá false e daí o meu usuário ele vai poder no input set também vai poder dar refund depois da inspiração.

Não me não me conta que as ordens elas vão >> vão chegar a tempo. >> Isso eu tô assim se eu tenho >> dar refund. Sim. É, por exemplo, digamos que você é um protocolo que você tem 50 transações por minuto, sei lá, por exemplo, e daí você dá uma inspiração de 5 minutos. Você pode esperar 30 segundos ou minuto, ah, 1 minuto 50, bet. Então, aí você vai fazer isso. Ou então se aí que dar isso é, vai ser para uma rota

mais líquida. Agora, digamos que, pô, é uma rota super líquida, eh, que eu quero dar um tempo e o usuário top, um tempo maior também, eh, aí não vou botar uma inspiração de 2 horas por, ou se, por exemplo, ah, é uma rede super estranha e eu não sei se o tempo vai dar, então eu boto inspiração de 2 horas para garantir e daí eu espero dar todos, eu espero dar meia hora lá, todos os meus intentos e eu dou um >> diga digamos assim, >> para você fazer isso, a sua inspiração tem que ser alta. A o usuário tem que topar uma inspiração de de 2 dias, três dias. Só que pensa o

seguinte, eh, do ponto de vista do do usuário, digamos que, eh, você tem que pensar também que o Sver às vezes ele não resolve a ordem por conta do preço, porque se não tiver preço bom, ele não vai resolver. Então, pensa no ponto de vista do usuário. Ah, eu abri uma ordinha aqui, só que o preço, só que do nada o preço aumentou, caiu e daí não faz mais sentido, nenhum resolveu para mim. Eu só vou conseguir dar um refund daqui dois dias. É meio também. Então tem tem que ter esse balanço de se for uma rota líquida, dificilmente alguém vai topar. Agora são alta não líquida, tipo assim, ah, é uma falta meio estranha que que não tem uma brid muito boa, tá assim, ah, eu topo,

usuário topa isso para para ser mais rápido, mas em geral eh você quer dar um dar um refund mais rápido pro usuário. Agora, se o usuário tiver de boa de refund em dois dias, aí você pode fazer um por dia. Depende do quanto que o usuá e o usuário também é, né? Pensa que o usuário, mas o usuário não vai não vai ficar olhando esse detalhe, né? Quem vai olhar de fato é a UI. Eh, e a UI e daí se o usuário não cons ele vai brigar com a UI, com os caras da carteira lá. Então e você tem que pensar um um tempo que faça sentido dado desses físicos e também dado o tempo do dado tempo do protocolo. Então a hyperl geralmente em

10 segundos ou menos a mensagem chega em geral para normais tem ser muito estranhos. Só ti mensagem. >> É mensagem do quê? Do coach? >> É.

>> Ah, da coach. Sim. Não, a coach não. Esse quando você pega a coach, ela ela ele vaiar um Jon que é a ordem, né? Us mas ele não precisa chamar >> não. É por isso que tem a função open for. Lembra que a gente tem duas funções? Tem a open, que é quando o próprio usuário chama um chamenda que vai estar transferindo. E tem open for, a open for é o gasless, que é quando é você chama você, por isso que é open for para abrir para alguém. E daí você vai pegar uma assinatura que pode ser que vai ser um permit >> você. Ah, o fio você não precisa de

assinatura, né? O o fio você é sver. Então o software vai o software tem que é ou você pode fazer uma user op e mandar para um mas eu acho que você vai tá gastando mais g >> é é uma é uma limit order isso é um limit order só que o usuário ele pode não aceitar sua coach tipo assim ele ele manda uma cota lá e daí se ele aceitar ele assina senão ele não assí ele só faz a assinatura e manda Eh, e daí basicamente é esse o fluxo total do do OF, né? Eh, aí, né, o que o que que a gente tá construindo, né? Os

contatos inteligentes. Então, eu junto com a galera da LIFI trabalhei no nos nos contratos. Então, se vocês tiverem alguma dúvida de contratos, é isso. Eh, do Sver eu eu não fiz diretamente, mas eu eu tô no time, então eu também eh sei. E daí a partir de agora eu provavelmente vou ficar um tempo também no Sver e na na a API, é o agregator. Aí o agregator é o seguinte, você vai mandar uma cota, dar um agregator vai mandar eh vai mandar vai vai pedir a cota para vários servers. E daí é a ideia que o Gegeto vai mandar pro usuário uma lista de softs, é, com a lista de diferentes cotas, né? E daí ele vai ele vai pegar

que ele acha melhor e vai assinar e daí ele vai mandar pro, para aquele server lá. Eh, e daí os contratos, né? Acho que assim, eu já falei bastante, ah, uma coisa interessante também, eh, duas coisas, na verdade, a gente tem callback, que é o quê? Ah, no seu caso lá que a sua, você pode fazer com que a a própria conta que recebe o intent, ela ela ela tem uma interface específica para você fazer o fazer um composer. Então, ah, eu quero receber os tokens da minha conta, mas eu quero pegar esse token e depositar na ave, por exemplo. Você consegue fazer isso. Claro que você vai precisar de um contrato intermediário, então você pode ter uma uma smart

account que tem isso já, só que ela vai é mais é mais o módulo. Então assim como você pode ter um módulo que é um 786 recipients, também pode ter um um módulo para receber o callback do do intente. Daí você vai pegar esse esse dado e daí você vai executar, você pode deporcionar, pode fazer o que você quiser também. Então, a gente tem a posade de callback, isso é bem interessante. Você pode assinar o intent e daí o seu intento, né? Eh, eh, inclusive o que a gente vai lançar agora junto com a Lify é o seguinte, eh, o callback é um novo intante, porque digamos que eu tô indo de uma rede para outra, só que eu tenho

liquidez numa rota, mas na rota final a liquidez é muito ruim. Eu não tenho liquidez nenhuma. O que eu posso fazer é, eu abro uma, eu abro uma chain, eu abro o intent de uma rede para outra e daí o callback dessa na change destino, ela abre ela abre uma ordem para outra cha e daí onde eu tenho liquidez. Então você consegue fazer inclusive composability, tipo multihop entre different diferentes chass, é onde você tem mais liquidez. A gente tá fazendo isso já, porque a ideia inclusive é o seguinte, a gente quer deixar isso isso disponível para para redes que são meio longe, que são menores e daí para isso a

gente não tem liquidez em toda a rota. Então a gente vai ter liquidez numa rota numa rede lá. Então você, como você, se for a própria rede, você pode deixar um estoque numa numa noa rede que é que é a principal e daí você usa um protocolo grande para ir para lá. Então, Lipi, ah, o Arth, só que daí você faz um callback para outra cha, então você consegue fazer esse multihop, que é bem interessante. Eh, então a gente aí, como eu falei, a ideia da gente trazer essa composability crosschain também é isso.

E a gente tem também e eu eu falei da posada de aqui, que é o padrão, né, que você dá, você abre a ordem e daí você transfere tokens. Existe uma outra possibilidade que tá live, mas ninguém tá muito usando muito ainda, que a Unisap tem o decompact, não sei se vocês já viram, eh, é um é o que eles chamam de resource lock, que é o seguinte, e se porque assim, eu não quero ficar transferindo tokens, então eu deixo todos os meus tokens no mesmo lugar e daí eu assino coisas para gastar esses tokens e daí cada token que eu coloco lá usa o 69. Tipo, a un V4, ela funciona assim, eh, as suas posições são 6999 e o

decompat também é assim. Então essa é uma é uma possibilidade e claro, a modalidade de oráculos que a gente tem, que a gente tem alguns e daí eh os soers podem inclusive fazer novos oráculos e usar oráculos próprios eh dependendo das coisas. O mais importante é que tanto o usuário quanto o server eles tem que concordar no que que eles estão assinando. Basicamente essa é a principal é essa é a principal coisa que que a gente que a gente que a gente precisa no OR. O Sver, né, como eu falei, é uma é uma API, tem vários tokens e várias networks lá. Over tá em Rust é open source, então vocês podem olhar e se quiser

melhorar ele ou eventualmente fazer coisas mais complexas, né? Adicionar a lógica de rebalance, adicionar a lógica de quais tokens estocar, quais rotas fazer e tudo mais. Eh, a API aqui é o é o é duas coisas. a a gente padroniza o server para ele também ter essa API e o agregator também, que daí é meio que para padronizar como é que vai pegar a cota, como é que vai submeter o intent, tipo como é que vai assinar e mandar o intent pro prover, né? E também o status da do intent. Mas isso aqui é uma é uma PI. Eh, a gente tem o Sver aggregate, open source, tem a spec também. Então tem a vocês podem ir lá no olhar spec das APIs e vai tá tudo

lá para vocês dar darem uma olhada. É o agregator, como eu falei, é, ah, aqui tem isso aqui. É basicamente, como eu falei, o cliente vai dar um get float aqui. E aí, aí por isso que é bom, né? Tanto o aggregator quanto o Sver, eles vão ter a mesma interface, eh, interface API, no caso. Então, o cliente ele vai pegar uma cota do agregator. Agregate vai pegar uma cota dos e daí os soversão, vão mandar as cotas e daí o o agregator manda as cotas pro cliente, o cliente vai escolher qual a melhor.

Lembrando que não é só o custo, né? Eh, tem acho o preço é é o primeiro a o a primeira coisa, mas os oráculos escolhidos, o tempo de expperação e o tempo de fio também são variáveis importantes. Então, todas essas variáveis são importantes em maior ou menor grau pro pro usuário. E ah, aqui é aqui são as próprias funções. Então, aqui é quando a gente dá o dá um inputush, tá vendo? Quando a gente dá um open, eh, por dentro, a gente tá fazendo isso aqui. Então, a gente, como eu falei, o input é o, a gente tem é uma lista de inputs, então você pode ter vários inputs, o tamanho é qualquer e daí a gente vai transferir,

vai dar um esc de todos os inputs dos usuários. O se é isso. Então a gente vai dar um fio e vai e vai guardar o hash do out. Ah, perceba o seguinte, a open é de ordem e a ordem dentro dela tem os outputs, que é uma lista, só que o fio é purp, então é uma mesma ordem. Se eu tiver mais de um output, eu tenho que chamar o fio mais de uma vez. Ou então tem um uma um fio bet lá que você pode chamar vários. Mas por quê? Como eu falei, do ponto de vista do settler, ele cada output é separado. Tanto é que tem aquele detalhe, né? Se eu tenho mais de

um output, o os que vai ganhar o dinheiro, que vai poder o clan, é o server do primeiro output. Se alguém for lá e resolver o segundo e outra pessoa resolver o primeiro depois, quem vai ganhar o dinheiro é o primeiro. Então você sempre resolve o primeiro primeiro e depois eventualmente os outros. Em geral só vai ter um output assim, apesar de a gente ter possibilidade por por padrão, até para simplificar pro software, vai ser um input e um output. E eu até recomendo, se começar a complicar demais, fica uma loucura.

Então, um input e um output. Eh, mas pode fazer o que a cabeça de vocês acharem melhor. Aí a gente pode dar, inclusive ele aceita tokeno. Então você pode o você pode mandar o SDC e o token nativo como como output, mas não como input. Eu é acho que como input não tem como ser o token ativo, mas como output sim. Eh, ah, aqui o submit, né? Porque aí lembrando, aí a gente deu um fio e daí agora depois de dar um fio o solver ele tem que dar um submit. Esse aqui é o do é o da Hyperlane. Eh, todos eles vão ser mais ou menos parecidos, mas eh vai ter

alguma eventualmente alguma diferença por conta do protocolo. Mas aí basicamente aqui você depois de dar um fio, você vai chamar um submit que vai mandar a que vai mandar a prova do destino pro input. E daí isso aqui é um no no destino, né? Você vai dar um submit e no input, esse rend aqui é automático, tanto é que ele é only mail box, no caso da hyperlan, então você não vai chamar isso aqui, mas é assim que ele chega. Então perceba que na change de input a gente faz as as verif, a gente chegou a mensagem, né?

Eh, a gente verifica, mas basicamente o que a gente faz é só isso. A gente só a gente só pega o sender, a aplicação que é o settler, o pelo o hash e a e a e a e a no caso aqui a tinha ID, a gente pega isso aqui e bota true. Então, basicamente o submit lá ele é grande, manda mensagem, a gente só recebe essa mensagem e bota como true, basicamente. E daí agora, a partir de agora, quando o usuário chamar finalize ou over chamar finalize, ele vai chamar o o finalize aqui, ele vai dar um validate f. Deixa eu ver se eu botei o vale. Eu não botei, mas o valid date fs aqui é basicamente

isso. Ele vai lá no meu oráculo e vai verificar se tá true ou false. E se tiver true vai dar certo. Daí eu vou poder fazer isso. E eu tenho callback também aqui. Eh, aí a gente a o nosso foco agora é expandir para mais eh dar um onbard nas nas layer do solver agregator. A gente tá expandindo, mas já tá operacional. Mais oráculos, né? A gente também tem um oráculo da Leer Giro, tem da Tinlink. Então a ideia é que o Sover pode escolher o oráculo que fizer mais sentido do ponto de vista de tempo, custo e que gosta também de confiança. Mas eh e daí o usuário os usuários vão a aceitar isso também. É

isso demo. Essa demo aqui eu não trouxe porque a gente tá lançando agora, eu acho que ela não tá deploiada. >> A ideia é >> isso é aí ele pode ser exct input ou exct. O exct output aqui é no na no no na no ponto de vista de contrato é é a mesma coisa, mas ele vai mudar só na cópia. Então ele tá aqui, ó, eu tenho 1000 USDC, eu tô na base de Cepolia, eu tenho USDC, eu tô indo para otimiza, no caso é o SDC também, mas poderia ser outro. É, no caso aqui a gente fez um mais simples, né?

>> Então, open source. Eh, isso aqui é, esse aqui é só uma demo, mas tem open source assim, é tudo. Eu, eu o agregator, não sei se tem isso aqui. >> E aí ele tá falando assim, tô enviando >> é isso aqui é é a cota. >> Sim, >> isso vai mantendo o agregate. Aí no caso só teve uma uma resposta, tá vendo? Só teve um um solver. O nosso Oifver, ele tem ele, ele deu esse input, lembra que é uma lista, né? Mas por padrão vai ser um só na a gente tem de list e tudo mais, mas na prática vai ser um. Então vai ser um input, um output e daí tá aqui ele já botou a cota, tá

vendo? A a fi, tá vendo que o input é 1000 a o output é 989? Ah, porque pensa que eu tô falando do agregator. Eu eu mandei o agregator assim, ó, agregator, me dá uma cota para isso. Aí o agregator ele mandou para vários que ele confia, por exemplo. E daí tem duas, ou ele só tem um server lá por algum motivo, só tem um um rodando, ou pode ser que aquela cota era meio ruim, só um respondeu. E ele tem, >> ah, não sei, alguns segundos assim na prática. É porque isso aqui é o penur não tá live ainda, tipo assim, não sei

quanto que é o tempo, mas na prática vai ser um segundo, talvez um segundo ali, coisa errada. Mes ou não? Tipo, eu te pedi um coach. >> Aham. >> Sim. Já tá com esse request aberto. >> É um request só. Agora tá sendo um request. Sim. Então é um um um só. E para aquela para aquela rota, né? Geralmente como é que vai ser feito? Eu tenho o agregator, você o sover lá, você vai se cadastrar com agregator. Fala assim, ó, eu eh gero rotas para eh eu provejo liquidez, né, nessas rotas aqui. E daí se e daí você fala assim: "Ah, eu e daí você vai me

perguntar, tem um tempo de time out que eu não vou saber qual que é". Mas aí você tem que responder com qual que é a sua qual que é a sua cota. Eh, e daí se se você receber uma cota e você não executar depois, você não é obrigado, né? Mas aí você vai perdendo pontuação do score. É que isso aqui é daí é um business que a gente a gente não tá rodando a gente mesmo. Então, eh, mas na Lify, por exemplo, que a LIFI faz isso já. Então, tem um agregator, você manda a cota, né? Se o solver começa a a não executar a ordem, por exemplo, ele vai perdendo pontuação lá de de como é que é o nome?

Eh, da qualidade dele e tal. E daí o agator vai começar a mandar menos cotas. Então você tem que se se comportar bem mais. Você não é obrigado na prática a nível de contato. É mais que assim você começar a dar cota e não dar um fio, aí começa a ficar ruim. Pode perguntar. Isso >> é, não é isso aqui é é a é a resposta. É porque só tem uma. Isso. Exato. Eh, nesse caso, sim.

Isso. Exato. Isso é na prática, eh, o que mais é usado que os sers preferem é o exclusivo. >> É por causa do front, porque se não for exclusivo é mais complicado, eh, é mais previsível se for exclusivo. Então, por aqui a gente sempre vai tanto até que a gente tá pedindo cota, né? Pensa no no exclusivo, eu não preciso de agregador, eu só submeto lá e daí quem quiser resolver resolve. Só que daí, por exemplo, e o preço? Que preço eu coloquei? Eh, alguém já vai resolver se o preço for bom e tem que ficar monitorando e tal. Então, em geral, você

pega de uma cota de você abre uma ordem já num preço que faça sentido. Então, aí, por exemplo, você pode achar, pô, aqui a taxa é o quê? De 1%, né? É 1% aqui. É, tá meio alto, talvez eu não quero. Então você aí você, ah, eu não quero essa cota aqui, aí eu vou ver outras. Só que aí, ah, essa cota aqui é 1%, mas ela usa um oráculo top, é super seguro. A outra lá é 0.01, mas um oráculo muito sigue lá que eu não sei o que que é. >> É o I. É. E I é pro usuário, né? >> Pro usuário. É. Esse aqui eu não sei se é o usuário. Eu acho que esse aqui fo essa aqui é uma demo que acho que por 120 segundos foi só uma

>> eh isso aqui é pro usuário. Então >> eh, então é porque então é aí é que tá. Em geral, simples, o usuário na UI dele não vai ter todas as informações, porque senão ia ter o endereço do oráculo, o field de line, o o a inspiração, você pode colocar eh só que já é muita informação. Então aí o I geralmente não vai mostrar tudo ou só se ah, se for, acho que aqui acho que tem um jeito de você clicar em avançado e ver todos os dados. Eh, mas em geral a UI não vai ter tudo. Ela vai mostrar o mais importante ali e não vai ter tudo. Então, por isso que a UI também vai ter que ter uma curadoria disso para saber o que que é um fio de line bom, o que que é uma

inspiração boa, dependendo do usuário, a inspiração também vai depender do tamanho da ordem, porque imagina se for uma ordem muito grande, eu quero dar um tempo prover ele originar aquele token, né? que imagina que é um 10 milhões de dólares lá. Às vezes o Sver ele até tem o dinheiro, mas ele não tem estoque. Ele vai precisar dar uma originação ali e o tempo é importante, né, por conta da volatilidade. Então você quer dar um tempo para ele montar isso para conseguir executar para você. Então você vai querer dar um tempo maior. Então tudo isso é variável que geralmente a UI vai pensar e vai fit. Exatamente. Exatamente. Porque o Exatamente. Perfeito.

O o porque pensa o solver pensa que é esse esse empréstimo de curto prazo do do ponto de vista do solver. Quanto mais tempo eu tenho para para dar o claim, mais eu tenho que eu tenho que cobrar de taxa e a taxa fica implícita no output. Perceba que não tem aqui, até pode estar escrito 1% de taxa, mas eh aqui é meio implícito, você só dá o output e aí a taxa é o que o Solver pegou ali entre um e outro. Eh, e daí aí a cota, né? Aí geralmente isso aqui não não tá em a nível de de contrato, né? É uma, por exemplo, não é não é porque o Sver deu a cota que ele tem uma obrigação a nível de contado inteligente de de pass resolver, mas tem

uma obrigação ali com os stakeholders que é isso é tudo eficiente assim, ah, não me assim, ah, você me garante esse preço por 30 segundos, que é, ah, se você assinar aqui agora, eh, eu executo esse preço. Se você demorar para assinar e também não dá, porque eh pode ter volatilidade, o preço pode tá ruim. Então assim, ó, eu te dou aqui se você quiser aí. Daí você vê, tá vendo o solver, esse aqui, o o amount, né? E daí é, e no caso é uma é uma estrã lock. É isso aqui é basicamente aí você assina dentro desse tempo. Se passar o tempo você essa cota pode ser que você pode ser que passe o tempo, você assine e o sove ainda resolva se fizer sentido,

mas ele não tem essa obrigação. Mas isso é tudo offchain, essa obrigação de assinar é offchain. Ele só tem obrigação, ele só ass mesmo quando ele de fato der um fio. É. E daí essa assinatura aqui, tá vendo que é um permit? geralmente assinaturo. Então o usuário vai assinar via permit, que é bom que é uma assinatura só. Eh, e é isso. Daí ele gera essa assinatura. Ah, é que é que isso aqui essa demo foi para mostrar os passos, né? Então, mas na você não vai mostrar a assinatura, mas o usuário foi lá, assinou, tem essa assinatura e daí ele vai mandar essa assinatura paraa PI do Sver aggregator e o agregator pro Sver.

Isso tem exato. Que daí é daí para padronizar tem uma spec lá que é a o server recebe essa essa assinatura que o usuário assina, manda assinatura, ele resolve. É, é isso. É isso, gente. Essa foi a apresentação por hoje. Obrigado. Mais uma pergunta, perguntas, sugestões. >> Hã, >> permitidores.

>> Não, não, não. O o PM2 é o approvo. Nossa, >> o >> é não, o o permit do é um singon. Hã, quando e chama open, quando openou open for, no caso, não disso, é quando o server chama open for com assinatura do usuário, só que o permit é um singulton, né, que vai que o usuário, então antes disso, o usuário tem que assinar uma transação de de approve do singleton, que daí isso pode ter um uma user op lá,

mas aí basicamente o solver usuário vai ter que aprovar e o o permite. E daí quando ele fizer a assinatura lá, ele manda a assinatura via permite. >> O open for. Aí ele transfere o transfer prom. Isso. >> Ah, tá. Eita, cham >> visuário que assinou, né? Aí, aí, aí reverteu. É, é bem simples.

>> É exato. Tipo assim, eh, tudo isso é é off chain, mas on chin você não vai conseguir a ordem se se o se o usuário não não tiver. Aí, por exemplo, com resource lock tem maneiras de de fazer fazer esse tipo de abertura com crédito e tudo mais, mas é no decompato, mas pode ser que seja usado. Então, o jeito é apag o setler. >> Settler é não são nomes, não precisa.

Mas lá na outra rede o cara já pagou a o período de transporte. >> Sim. Não, na verdade não, sinceramente, porque, por exemplo, digamos que eu tenho a assinatura do do usuário. Se você quiser, você pode fis, digamos que seja uma não exclusiva. Você só que o usuário mandou para você assinatura. Se você open for, aí qualquer um vai poder dar um fio. Você pode dar um fio primeiro e depois open for, porque pensa que as duas box elas elas não sabe da extensão da outra, né?

Então nada impede você fio e open for depois. Claro que tem o tempo de tem o a fio da line e tem o tempo de inspiração. Se você dar um fio primeiro e depois você não conseguir abrir a ordem, aí já aí saber uma ideia. >> É só que a ideia é calculada até até a você consegue saber a ideia. Exato. Até até por conta de ser a gente não fica guardando, a gente e dá um store do mínimo possível. Então, cada ordem, cada ordem ela é única e você consegue eh gerar a ID dela. Então você já sabe a ID da ordem mesmo que não deu o open for.

Se eu não me engano, Alif faz algo mais ou menos assim, dá um f, depois um open for. Só que assim, na prática, se é uma ordem exclusiva, você pode open for e depois fi o que acontece, o token só é transferido do usuário no no quando é open for. Então, sei lá, digamos, você tem um usuário ali que, pô, você deu um fio e antes você dar o open for, ele foi lá e e transferiu os tokens para outra carteira, tirou os tokens, aí vai reverter, só que você já deu fio, já perdeu o dinheiro, entendeu? Então não tem, enfim, tem esses detalhes aí, mas o importante é o open for vai ou open, né, o mas no caso de vocês vai ser vai ser open for. O open for vai dar o vai transferir os tokens pro settler,

vocês vai vão vão dar um f e depois vocês vão dar um finalize. Daí o finalize vai ser o que vai dar o o finalize vai ser o que vai dar o ah o claim. Isso que o server vai poder pegar os tokens. Então o que importa quando ele der o finalize é que esteja eh é que esteja você tem mandar manda a prova. Então não importa a ordem do open do fio, desde que, enfim, tem os os tempos lá sejam corretos, porque primeiro já existe o R6 783. Então o RC 783 ele foi criado primeiro pela UnisP,

pela Cross e a ideia foi criar o o OF sendo uma implementação do 783. Então a ideia que o o que também porque o open não é só o contrato, né, todo o standard de como criar a a criar as ordens, padrizar os oráculos e tudo mais. É sim, só que no caso a gente tentou deixar bem mais modular assim e também já existiu o RC 783, eu acho que eles não quiseram complicar tanto. Tanto é que o IF hoje ele não implementa o 783 porque ele tá meio desatualizado assim.

Eh, mas se tudo der certo, quando ele for quando o 783 atualizar, a gente vai atualizar o IF também. Mas, mas vai mudar muita coisa não. >> Isso. O IF intentes, nada, é só a ordem, assinatura. Não, não acho que não a nível de

de client eh o que assim, por exemplo, falando de a de mensagem mais abstrata de quando você vai mandar token para mint burn, eh, você quanto mais rápido, melhor. Então, por exemplo, ah, se o, por exemplo, se o, se você tivesse uma finite muito mais rápida, é, entre changes, a gente poderia ter um tipo de oráculo de mais para um um só tipo de oráculo que já manda a prova direto, por exemplo, e daí a gente seria um pouco diferente. Mas hoje, como isso não é verdade, a gente é modular para deixar as pessoas escolherem diferentes tipos de oráculos com diferentes níveis de segurança. faz sentido, mas não, mas a nível de clientes, a não

ser que deixa ele mais rápido, melhor, mas nada específico assim. perguntas. Eh, tem mais é pros dois assim, é basicamente é porque, cara, é para simplificar a vida do do usuário no sentido de que a gente a ideia que tem a a Etheréum tem diferentes layer dois e layer três, não sei o quê, só que pro usuário retail principalmente você quer que seja uma coisa só. Então,

pô, o cara ele tem ele tem ether primeiro. Ah, é assim, o quando a gente é possível fazer com inputs em múltiplas. Então, digamos que, pô, hoje a gente tem a USDC na Etheréum, base e optimum arbitron. E se pros usuários já tiver lá o SDC e daí tiver lá e ele tem aí, ele tem o SDC e ele quer? Ele não precisa necessariamente nem saber qual o L2 tá. E daí, só que daí a gente precisa de um protocolo que, pô, eu pego os diferentes tokens que ele tem, abro ass abro ordens para diferentes coisas, faço um output só para reditar.

Então, meio que a ideia é abstrair e idealmente a gente abstrair tudo quando o usuário quiser, pô, comprar uma a mimic que ele gosta de de comprar, ele não precisa saber em que rede tá, ele não precisa de nada disso, ele consegue abstrair e claro, né? E daí daí meio que faz o rapel do swap, breed, só que ainda tem muita coisa, né? Tipo assim, a originação do token, que é o trabalho do do Sver ainda é um trabalho grande aí que o que o Sof vai conseguir ganhar algum dinheiro com isso. Se ele for um bom S, >> que você falou da das 7786 que é >> isso é na base mais abstrata.

>> Você pode usar, você pode usar na mesma ch. Tá, não usa, mas mas poderia eh poderia, só que daí talvez para por questão de curso, talvez você queira que algumas coisas a gente tem porque a crosschain, né? Porque a gente assume que a gente não sabe o estrado da outra chain. Se você tá numa mesma chain, às vezes você consegue deixar a coisa mais ótima e os contratos mais ótimos simplificando algumas coisas. Mas a princípio funciona. Inclusive o out também é um oráculo. Ele além ele também funciona como oráculo para esse caso em que você pode usar usar uma mesma mesma cham pros dois, mas não

>> é não. Exato. Você pode exato ele mesmo é o oráculo. Por isso mesmo. Out já é o oráculo que daí tá na mesma rede. Só que não é para isso que ele foi a gente não fez ele otimizado para isso. A gente fez otimizado pra múltiplan >> é o 783. Ele é o http. A gente quer que seja pelo menos o http de mensageria para >> entende na mesma cha? Não é eh você é que eu não sei se tem um padrão para isso, porque já existe, é uma ordem assim assim, já tem muitos já tem muitos protocolos que fazem isso de maneiras

diferentes. Eu acho que a gente tenta resolver o problema específico de dessa fragmentação de liquidez entre múltiplas redes e que novas redes novas do elas têm dificuldade de de, por exemplo, de eh de fazer os protocolos deployar lá é é custoso. Então, se você tem um padrão open source e e já padronizado, uma nova chain, ela já pode deploir ela mesma, um output setter e começar a rodar o ela mesma ali pra galera começar a começar a ter liquidez para entrar naquela rede, porque por exemplo, você vai contar, você quer que a Link, você quer que a esteja na sua rede, vai ser caro. Muitas

vezes você vai criar uma nova, você não precisa disso, você só roda um settler, você deploy um settler, você mesmo roda um sover e você consegue fazer isso meio que ah, faz a preço de custo só pros usuários poderem ter uma bridge reliable. outra perguntava um pouco fora do tema, mas pegando no passado você fez aquele curso que a gente até te >> Aham.

Ah legal da galera da Euroglob. Aham. Sim, >> uma grandeção. >> É, é muito preso com broadcaster. Sim, é a mesma cois é a basicamente o seguinte, o que que é o é o broadcaster? Basicamente é o seguinte, a gente tem blockchain EVM, né? Vou falar de EVM aqui. É uma mera, uma mercalle tree, né?

Então, se eu tenho um storage, eu consigo gerar uma prova que aquele que aquele slot ele tá escrito lá. E daí que acontece? Quando eu tenho uma ler um meu a ler dois, ela se comunicam através da block hash. Então, por exemplo, ah, eu hum eu na leer dois eu vejo o estado da lei um e na lei um eu vejo o estado da leer dois. Então, por exemplo, ó, se eu quero verificar que na minha na Arbitrum tal coisa foi executada, por exemplo, a as ordens foram executadas. Se eu quero verificar isso, eu escrevo, eu vou dar um broadcast, eu vou escrever no storage e eu vou gerar uma storage, uma storage proof dessa, dessa cha, eu vou uma uma storage proof

na Arbitrum que eu vou verificar na Etheréum. A Etheréum, por ser uma layer um com layer do, a Etheréum tem acesso ao block hash da árbitro. Então eu consigo verificar eh que aqui de fato aquela storage proof ela tá contida no block da árbitro. Então eu consigo de maneira trustless verificar um storage escrito, que no caso esse storage pode ser o que a prova que foi escrita. A mania de fazer isso, Z é o seguinte, que é eu em vez de fazer a verificação Mercoo, eu eu gero uma uma z proof, né? Eu gero uma prova de que aquele storage foi escrito, que é mesmo

no fim a mesma coisa. Ao em vez de usar uma storage proof, eu faço uma z proof que aquele storage foi escrito. Para ele funcionar de maneira trustless, ele tem o mesmo o mesmo problema de tempo que é o quê? Eu preciso é a minha ler, eu preciso verificar com o meu state root, só que o meu state root ele só vai ser atualizado quando aquele bloco tiver finality, que no caso de uma leer dois para leer um são 7 dias. Então eu tenho que ter sete dias eh para para ter a finality para eu poder verificar que de fato aquele que que aquela prova tá naquele state root. Aí essa prova pode ser um provas ou pode ser um story uma uma storage proof. O broadcaster a gente

implementou via storage proof. Você gera gera storage pro na arbitron verifica na na et. Inclusive a gente e a gente fez isso mais legal ainda, acho que é o principal em cadeia. Digamos que eu quero verificar da base paraa árbitro. Só que a Arbitro só sabe da lei um, ela não sabe da base. Só que eu consigo em cadeia porque eu tenho uma umas cópias lá, tem é bem complicado de explicar, mas basicamente como funciona é digamos que eu eu mandei eu fiz um broadcast ou uma mensagem na base. Se eu fiz um broadcast na base, eu consigo verificar na na Mainnet, certo? Só que se eu consigo verificar na Mainnet, a Mainnet também consegue provar para árbitro.

Então eu faço um encadeamento de duas provas. Eu pego uma prova da base e uma prova da porque daí o que acontece, eu consigo provar porque a base ela tem o block hash dela na layer um num certo num certo slot. Então eu provo na Etherum que a base colocou aquele storage proof e verifico que tá correto e depois eu verifico que aquele block hash da Etheréum tá correto na árbitro. Então eu consigo encadear isso e daí é o que a gente chama, eu consigo fazer uma verificação síncrona, eh, de via ler dois para ler dois ou até ler três para ler dois, é com bem menos dado do que eu não preciso mandar muito dado, eu só preciso eh verificar via block hash.

Tá, isso tá online. Tá, eu eu fiz foi difícil para caramba >> e funciona. a dizer assim de leer da lei dois para lei um da lei um para leer dois vai ser mais rápido porque daí é o que o até o Henrique tava falando que é 13 minutos de finality que inclusive tá sendo melhorado para 13 segundos essa semana >> o Btec. Isso, >> isso.

>> Sim, porque eles são bem mais rápidos. Zic rollap é assim, cara. Eu fiz, eu deploiei, eu fiz de todos da Arbitro, optimis, Z5, Linear, Scroll e Type. Aí a gente tá live nesses seis. Eh, paraas K5, assim, por exemplo, o tempo da lei um para leer dois é o mesmo, mas a lei dois para lei um, enquanto a árbitro é 7 dias, na Z5, é 20 minutos. ou uma hora no máximo. Eh, é diferente a verificação, mas é mas é a mesma ideia, essa ideia de que a gente inclusive a gente mudou, né? A árbitro tinha o se eles fizeram o broadcaster, inclusive mudou para ser mais geral, para ser qualquer state commitments.

Então qualquer commitment que que é uma layer dois faz para layer um. Se eu consigo verificar ele, eu vou conseguir provar essa essa cadeia. Então, se eu vou para um zic rollap, para um zer rollap também vai ser bem mais rápido. Isso nativo eh com a mesma confiança que você tem na própria bridge nativo. É legal. E tá live, olhem isso. Deu muito trabalho fazer. Eh, mas foi bem foi bem legal. Eu aprendi bastante também escrevendo esse esse contato. Foi bem bem bem interessante.

>> Perguntas >> gravar. >> Tá gravado, >> gente. Mais alguma? >> Mais alguma pergunta? Obrigado. Então, eh, a gente vai fazer um obrigado aí. >> Valeu, gente. Obrigado. Valeu, gente, que tava online também.

>> Falta pergunta, tá? Ah, tem pergunta aqui. Ah, LAN, não acho só verificar o meu primeiro pró. Faz mais difícil verificar o consenso porque como você sai no meu curso? Então, eh, Loran, eh, essa essa é é exatamente isso, por, eh, a ideia é que a leer dois ela vai ter eh o block has rayer um e a layer um ela tem acesso ao blockcha e daí ela tá num num slot específico. Então, por exemplo, lá, digamos que você fez uma transação na base, certo? Essa transação foi num bloco, num certo bloco que tem um certo bloco hash. Então eu tenho duas provas.

Eu gero uma prova da base, beleza? Só que se eu verificar a prova da base na árbitro, eu não sei se é que ela de fato tá válida, porque eu não tenho às vezes a block da árbitro. Só que qual que é a parada? O block has ras tá na artérium no slot específico. E daí inclusive eu tinha teve que lá calcular o slot certinho. Mas beleza, ele tá no slot, certo? Então o que que eu faço? Eu gero uma prova que naquele slot na Etherum tá correto num certo outro bloco e a Arbitron ela acessa o o blockh da Etheréum. Então eu faço em duas camadas, ó. Eu verifico que um certo slot na Etheréum foi escrito via eh verificação direto na ST root com a com a block hash e depois, ou seja, aí com isso eu tenho,

ó, esse aqui é o block hash correto na base. Então agora o que que eu faço? Eu tenho também a minha prova na base. Daí eu verifico que aquela prova na blaze na base tá correta, eh, tá válida baseada naquele block hash. Então, eu consigo fazer esse encadeamento baseado nas blockhas hash. E daí a gente inclusive também fez um sistema para layer um poder mandar eh o block hash para layer dois, que a gente chama de pushs. É tudo isso também em open source. Eh, tá lá no opense framework, o no GitHub. Então pode dar, pode comentar lá, Loran. O que o que eu falei fez sentido?

Não, exato, Loran, a ideia do Broadcaster é para ser layer dois. Não, para não ser layer dois. A ideia do broadcaster é qualquer rede que ela manda o state dela para Etherum. Então, a gente tá falando de ou se não for Etheréum para Lerum, né? Então, a gente tá falando aqui eh não não é de uma rede qualquer para uma rede qualquer. A gente tá falando de Etheréum com a sua segunda e terceiras camadas. A ideia que aqui eu consigo fazer uma verificação. Esse encadeamento pode ser de uma leer 4 para uma leer do, por exemplo. E e daí então no caso aqui é o foco em em etéreo mesmo.

Uma pergunta >> solução aceita ISO. Eu não, eu não tenho ideia do que que é isso. Isso isso 200 >> é assim a nível de contrato eu diria que não, mas você pode fazer uma API que que sim, eu acho. Não tenho certeza. >> É assim na não, mas ah tô falando do 7786 talvez porque qualquer tipo de mensagem, né? Então você pode fazer um um protocolo de mensagem de linha que seja compliant com esse ISO aí, mas eu diria que não é muito eficiente botar XX ML on ch vai ser caríssimo. Então talvez não, não

exatamente. >> Vou parar a gravação aqui. >> Valeu, gente. Boa noite aí. Qualquer coisa pode mandar mensagem. Eh, eu tô disponível. Valeu,