Binance Square
Sattar Chaqer
6.6k Publicações

Sattar Chaqer

Square verificado+
I’m back
Traders League Badge Expert
Traders League Badge Expert
141 A seguir
47.8K+ Seguidores
89.3K+ Gostaram
1 Emblemas
Publicações
PINNED
·
--
Uma coisa que se destaca para mim nas finanças onchain é como, com frequência, a conformidade é descrita como um processo em vez de ser demonstrada como um resultado. Uma plataforma diz que fez a triagem de uma carteira. Um gestor de cofre diz que seguiu a diretriz. Um protocolo diz que verificou as regras relevantes antes de permitir que uma ação avance. Em cada caso, ainda se pede ao usuário que confie que os controles certos existiam em algum lugar do fluxo de trabalho. É essa a parte a que eu continuo voltando. Uma promessa de conformidade te diz o que uma equipe afirma que aconteceu. Ela não necessariamente prova que a regra foi de fato aplicada na transação que moveu o valor. A abordagem da Newton parece diferente porque aproxima a conformidade da própria transação. Em vez de apenas dizer que as verificações aconteceram, a Newton é construída para produzir um resultado de autorização assinado ligado a uma intenção específica de transação antes da execução. Em outras palavras, o sistema não apenas descreve os controles em torno da transação. Ele cria um registro verificável de que a política foi avaliada antes de o valor ser movido. Essa distinção importa mais do que parece. Uma promessa geralmente existe em um documento de processo, um fluxo interno de trabalho ou um painel. Um recibo fica muito mais perto do caminho real da transação. Ele se torna evidência de que a transação foi verificada sob uma política definida em um momento definido. Para mim, essa é a verdadeira mudança que a Newton está fazendo. Ela transforma a conformidade de algo que uma plataforma afirma ter feito em algo que a infraestrutura realmente consegue mostrar. E, em um sistema construído para mover valor sem pedir confiança, isso parece um padrão muito mais forte do que simplesmente dizer “rodamos as verificações”. @NewtonProtocol $NEWT #Newt $LAB $VANRY O que importa mais na conformidade?
Uma coisa que se destaca para mim nas finanças onchain é como, com frequência, a conformidade é descrita como um processo em vez de ser demonstrada como um resultado. Uma plataforma diz que fez a triagem de uma carteira. Um gestor de cofre diz que seguiu a diretriz. Um protocolo diz que verificou as regras relevantes antes de permitir que uma ação avance. Em cada caso, ainda se pede ao usuário que confie que os controles certos existiam em algum lugar do fluxo de trabalho. É essa a parte a que eu continuo voltando. Uma promessa de conformidade te diz o que uma equipe afirma que aconteceu. Ela não necessariamente prova que a regra foi de fato aplicada na transação que moveu o valor. A abordagem da Newton parece diferente porque aproxima a conformidade da própria transação. Em vez de apenas dizer que as verificações aconteceram, a Newton é construída para produzir um resultado de autorização assinado ligado a uma intenção específica de transação antes da execução. Em outras palavras, o sistema não apenas descreve os controles em torno da transação. Ele cria um registro verificável de que a política foi avaliada antes de o valor ser movido. Essa distinção importa mais do que parece. Uma promessa geralmente existe em um documento de processo, um fluxo interno de trabalho ou um painel. Um recibo fica muito mais perto do caminho real da transação. Ele se torna evidência de que a transação foi verificada sob uma política definida em um momento definido. Para mim, essa é a verdadeira mudança que a Newton está fazendo. Ela transforma a conformidade de algo que uma plataforma afirma ter feito em algo que a infraestrutura realmente consegue mostrar. E, em um sistema construído para mover valor sem pedir confiança, isso parece um padrão muito mais forte do que simplesmente dizer “rodamos as verificações”.

@NewtonProtocol $NEWT #Newt $LAB $VANRY

O que importa mais na conformidade?
Compliance Promise
Compliance Receipt
Post Trade Monitoring
Manual Review
16 hora(s) restante(s)
PINNED
Verificado
Artigo
Por que os comprovantes de conformidade importam mais do que as promessas de conformidadeUma coisa à qual continuo voltando nas finanças onchain é com que frequência a conformidade é descrita como um processo, em vez de ser demonstrada como um resultado. Uma plataforma diz que analisou uma carteira. Um gerente de cofre diz que seguiu a determinação. Um protocolo diz que verificou as regras relevantes antes de permitir que uma ação prossiga. Em cada caso, o usuário é solicitado a confiar que os controles corretos existiam em algum lugar do fluxo de trabalho. Isso pode ter sido aceitável quando a cripto era menor e, em grande parte, autossuficiente. Mas quanto mais capital se move on-chain, menos convincentes se tornam essas promessas.

Por que os comprovantes de conformidade importam mais do que as promessas de conformidade

Uma coisa à qual continuo voltando nas finanças onchain é com que frequência a conformidade é descrita como um processo, em vez de ser demonstrada como um resultado.
Uma plataforma diz que analisou uma carteira. Um gerente de cofre diz que seguiu a determinação. Um protocolo diz que verificou as regras relevantes antes de permitir que uma ação prossiga. Em cada caso, o usuário é solicitado a confiar que os controles corretos existiam em algum lugar do fluxo de trabalho.
Isso pode ter sido aceitável quando a cripto era menor e, em grande parte, autossuficiente. Mas quanto mais capital se move on-chain, menos convincentes se tornam essas promessas.
Bem-vindos a todos
Bem-vindos a todos
avatar
@Sahil987
está a falar
[EM DIRETO] 🎙️ ....
717 reproduções
live
Continuo percebendo que aplicativos de cripto frequentemente tratam as verificações do usuário como algo que acontece antes da transação, em vez de algo que molda a própria transação. Uma plataforma decide se uma carteira pode acessar um recurso, entrar em um mercado ou usar um determinado fluxo de produto. Uma vez tomada essa decisão de acesso, a ação onchain em si geralmente é tratada como uma etapa separada. O usuário passa pela porta da frente, mas o caminho da transação continua se comportando como se essas condições não importassem mais. Quanto mais eu analiso a arquitetura do Newton, mais acho que essa separação é uma fraqueza estrutural. O que importa não é apenas se uma plataforma verificou o usuário mais cedo na jornada. O que importa é se a transação consegue avaliar as condições relevantes do usuário no momento em que está prestes a ser executada. É essa a mudança que eu vejo no Identity Oracle do Newton. Em vez de tratar as informações do usuário como algo que só importa durante o controle de acesso, o Newton transforma atributos selecionados do usuário em entradas de autorização. Condições de elegibilidade de status regional e outras regras vinculadas ao usuário podem se tornar parte do próprio fluxo de aprovação, de modo que o sistema deixa de perguntar apenas se um usuário entrou no produto. Ele pode perguntar se esta transação específica deve ser permitida sob esta política específica. Isso muda o papel dessas verificações dentro das finanças onchain. Elas deixam de ser apenas um portão para a aplicação. Elas se tornam parte da decisão da transação em si. Para mim, essa é a parte importante. O Newton está tentando aproximar regras vinculadas ao usuário do lugar em que o valor realmente se move, mantendo ainda detalhes pessoais sensíveis fora da camada pública de transações. Isso torna o modelo muito mais útil. Não porque ele transforme cripto em um sistema de identidade. Mas porque oferece às aplicações onchain uma forma de tratar condições do usuário como lógica programável de transação, em vez de deixá-las como uma etapa separada fora da cadeia que deixa de importar assim que o app é aberto. @NewtonProtocol $NEWT #Newt $HMSTR $LAB Onde a elegibilidade do usuário deve importar mais nas finanças on-chain?
Continuo percebendo que aplicativos de cripto frequentemente tratam as verificações do usuário como algo que acontece antes da transação, em vez de algo que molda a própria transação.

Uma plataforma decide se uma carteira pode acessar um recurso, entrar em um mercado ou usar um determinado fluxo de produto. Uma vez tomada essa decisão de acesso, a ação onchain em si geralmente é tratada como uma etapa separada. O usuário passa pela porta da frente, mas o caminho da transação continua se comportando como se essas condições não importassem mais.

Quanto mais eu analiso a arquitetura do Newton, mais acho que essa separação é uma fraqueza estrutural.

O que importa não é apenas se uma plataforma verificou o usuário mais cedo na jornada. O que importa é se a transação consegue avaliar as condições relevantes do usuário no momento em que está prestes a ser executada. É essa a mudança que eu vejo no Identity Oracle do Newton.

Em vez de tratar as informações do usuário como algo que só importa durante o controle de acesso, o Newton transforma atributos selecionados do usuário em entradas de autorização. Condições de elegibilidade de status regional e outras regras vinculadas ao usuário podem se tornar parte do próprio fluxo de aprovação, de modo que o sistema deixa de perguntar apenas se um usuário entrou no produto. Ele pode perguntar se esta transação específica deve ser permitida sob esta política específica.

Isso muda o papel dessas verificações dentro das finanças onchain.

Elas deixam de ser apenas um portão para a aplicação.

Elas se tornam parte da decisão da transação em si.

Para mim, essa é a parte importante. O Newton está tentando aproximar regras vinculadas ao usuário do lugar em que o valor realmente se move, mantendo ainda detalhes pessoais sensíveis fora da camada pública de transações.

Isso torna o modelo muito mais útil.

Não porque ele transforme cripto em um sistema de identidade.

Mas porque oferece às aplicações onchain uma forma de tratar condições do usuário como lógica programável de transação, em vez de deixá-las como uma etapa separada fora da cadeia que deixa de importar assim que o app é aberto.

@NewtonProtocol $NEWT #Newt $HMSTR $LAB

Onde a elegibilidade do usuário deve importar mais nas finanças on-chain?
During Onboarding Only
56%
When Accessing the App
22%
MomentTransactionAuthorization
22%
OnlyPosttrade Compliance Check
0%
9 Votos • Votação encerrada
Vamos reivindicá-lo
Vamos reivindicá-lo
Nadyisom
·
--
MODO DE DESLISTAGEM TLM ATIVADO 🚨
Minhas moedas acabaram de ser despejadas mais rápido do que meu ex saiu do grupo do chat.
Status do portfólio:
Token de suporte emocional: sumiu
Fornecimento de copium: criticamente baixo
Eu: ainda atualizando o gráfico como um otário 😭💀
$TLM $TLM
Artigo
Oracle de Identidade da Newton Como a Identidade Verificada se Torna Lógica de TransaçãoPor muito tempo, a elegibilidade dos usuários em cripto viveu principalmente nas margens do produto. Um aplicativo decide se uma carteira deve ou não ser autorizada a acessar um recurso, entrar em um mercado ou usar um determinado fluxo. Essas decisões frequentemente acontecem antes da transação em si e, uma vez que o usuário chega ao aplicativo, a ação on-chain real é tratada como uma etapa separada. Quanto mais eu olho para a arquitetura de Newton, mais penso que essa separação é uma das maiores fraquezas na forma como as regras on-chain são tratadas hoje.

Oracle de Identidade da Newton Como a Identidade Verificada se Torna Lógica de Transação

Por muito tempo, a elegibilidade dos usuários em cripto viveu principalmente nas margens do produto.
Um aplicativo decide se uma carteira deve ou não ser autorizada a acessar um recurso, entrar em um mercado ou usar um determinado fluxo. Essas decisões frequentemente acontecem antes da transação em si e, uma vez que o usuário chega ao aplicativo, a ação on-chain real é tratada como uma etapa separada.
Quanto mais eu olho para a arquitetura de Newton, mais penso que essa separação é uma das maiores fraquezas na forma como as regras on-chain são tratadas hoje.
Verificado
Continuo percebendo que apps de cripto ainda confundem restrições de interface com aplicação real.Ao lado de um frontend pode ocultar um botão, bloquear uma região ou impedir que uma carteira use um recurso. À primeira vista, isso parece conformidade. O usuário vê a restrição, o app pode apontar para uma camada de controle visível e o produto pode dizer que tem verificações em vigor.Mas nada disso significa que a transação em si esteja realmente sendo regida.Se o contrato inteligente ainda puder ser chamado diretamente, então a regra não existe de fato onde o valor se move. Ela fica na camada do app, acima do contrato. Isso pode reduzir o uso indevido casual, mas não cria uma aplicação real no nível da transação.Essa é a fragilidade que a Newton está tentando resolver.Na visão da Newton, a conformidade não deve depender de o usuário permanecer dentro da interface aprovada. Ela precisa ser aplicada antes do acerto, no ponto em que a transação está sendo autorizada. É por isso que a integração com a Persona importa para mim.Não é apenas sobre provar identidade ou residência. É sobre pegar esses atributos e usá-los dentro do próprio caminho de autorização, para que uma transação possa ser avaliada antes da execução, e não apenas filtrada no frontend.E isso muda completamente o padrão.O controle apenas no frontend diz: Tentamos impedir essa ação no app.Um controle na camada de transação diz: Essa ação não pode executar a menos que satisfaça a política.Isso é uma afirmação muito mais forte.Porque, nas finanças onchain, a pergunta real não é se a interface bloqueou o clique. A pergunta real é se o caminho do contrato ainda estava aberto.Se estivesse, a regra de conformidade era sempre contornável.É por isso que eu acho que a arquitetura da Newton importa. Ela afasta a conformidade das restrições de nível de UI e a aproxima do lugar onde as transações realmente se tornam reais.Na cripto, o contrato inteligente é o portão final. Se a conformidade não chega a essa camada, ela ainda está operando um passo distante demais daquilo que deveria controlar. @NewtonProtocol $NEWT #Newt $TLM $ARPA Onde a conformidade realmente deve ser aplicada na cripto?
Continuo percebendo que apps de cripto ainda confundem restrições de interface com aplicação real.Ao lado de um frontend pode ocultar um botão, bloquear uma região ou impedir que uma carteira use um recurso. À primeira vista, isso parece conformidade. O usuário vê a restrição, o app pode apontar para uma camada de controle visível e o produto pode dizer que tem verificações em vigor.Mas nada disso significa que a transação em si esteja realmente sendo regida.Se o contrato inteligente ainda puder ser chamado diretamente, então a regra não existe de fato onde o valor se move. Ela fica na camada do app, acima do contrato. Isso pode reduzir o uso indevido casual, mas não cria uma aplicação real no nível da transação.Essa é a fragilidade que a Newton está tentando resolver.Na visão da Newton, a conformidade não deve depender de o usuário permanecer dentro da interface aprovada. Ela precisa ser aplicada antes do acerto, no ponto em que a transação está sendo autorizada. É por isso que a integração com a Persona importa para mim.Não é apenas sobre provar identidade ou residência. É sobre pegar esses atributos e usá-los dentro do próprio caminho de autorização, para que uma transação possa ser avaliada antes da execução, e não apenas filtrada no frontend.E isso muda completamente o padrão.O controle apenas no frontend diz: Tentamos impedir essa ação no app.Um controle na camada de transação diz: Essa ação não pode executar a menos que satisfaça a política.Isso é uma afirmação muito mais forte.Porque, nas finanças onchain, a pergunta real não é se a interface bloqueou o clique. A pergunta real é se o caminho do contrato ainda estava aberto.Se estivesse, a regra de conformidade era sempre contornável.É por isso que eu acho que a arquitetura da Newton importa. Ela afasta a conformidade das restrições de nível de UI e a aproxima do lugar onde as transações realmente se tornam reais.Na cripto, o contrato inteligente é o portão final. Se a conformidade não chega a essa camada, ela ainda está operando um passo distante demais daquilo que deveria controlar.

@NewtonProtocol $NEWT #Newt $TLM $ARPA
Onde a conformidade realmente deve ser aplicada na cripto?
In the Frontend
55%
During Onboarding
9%
At the Authorization Layer
18%
Settlement Through Monitoring
18%
11 Votos • Votação encerrada
Verificado
Artigo
Por que a conformidade falha quando vive apenas no front-endPor muito tempo, os produtos de cripto trataram a conformidade como algo que acontece ao redor da transação, em vez de dentro dela. Um front-end bloqueia uma carteira de clicar em um botão. Um aplicativo web oculta um recurso dos usuários em uma região restrita. Um fluxo de onboarding executa verificações de identidade antes de conceder acesso a um painel. À primeira vista, isso pode parecer conformidade. A interface parece impor regras que o usuário enxerga, restrições e o produto pode apontar para uma camada de controle visível. O problema é que nenhum desses controles realmente governa o próprio caminho da transação.

Por que a conformidade falha quando vive apenas no front-end

Por muito tempo, os produtos de cripto trataram a conformidade como algo que acontece ao redor da transação, em vez de dentro dela.
Um front-end bloqueia uma carteira de clicar em um botão. Um aplicativo web oculta um recurso dos usuários em uma região restrita. Um fluxo de onboarding executa verificações de identidade antes de conceder acesso a um painel. À primeira vista, isso pode parecer conformidade. A interface parece impor regras que o usuário enxerga, restrições e o produto pode apontar para uma camada de controle visível.
O problema é que nenhum desses controles realmente governa o próprio caminho da transação.
Verificado
Continuo notando que a conformidade em cripto ainda é tratada como papelada em torno da transação, em vez de lógica dentro da própria transação. Esse modelo fazia sentido em sistemas financeiros mais antigos, nos quais restrições de aprovação e revisões podiam ficar em camadas operacionais separadas. Mas as finanças onchain não funcionam assim. Contratos inteligentes executam automaticamente, o valor é liquidado rapidamente e as transações não pausam para que uma equipe de conformidade interprete manualmente a política depois do fato. Se a liquidação já é programável, então a conformidade provavelmente também precisa ser programável. É essa a parte do Newton Protocol que acho especialmente interessante. A Newton não trata a conformidade como uma lista externa anexada a uma transação. Ela transforma política em algo que o sistema consegue avaliar antes da execução. Ao usar política como código com ferramentas como Rego e Open Policy Agent, regras de transação podem ser escritas como lógica legível por máquina, em vez de ficarem enterradas em PDFs de procedimentos internos ou em lógica de produto codificada de forma rígida. Isso muda completamente o papel da conformidade. Um limite de transferência vira lógica programável. Uma restrição de jurisdição vira lógica programável. Um requisito de elegibilidade do investidor vira lógica programável. Uma checagem de sanções vira lógica programável. Quando essas regras são expressas como código, a conformidade deixa de ser um processo operacional frouxo e passa a se comportar como infraestrutura. Ela vira algo que software consegue avaliar de maneira consistente antes que o valor se mova. Para mim, essa é a mudança real que a Newton está impulsionando. Contratos inteligentes tornaram a liquidação programável. A Newton está tentando fazer o mesmo para a política. E, se as finanças onchain vão dar suporte a atividades financeiras mais sérias, provavelmente a conformidade não pode ficar como papelada fora do sistema para sempre. @NewtonProtocol $NEWT #Newt $M $US Qual é o maior gargalo para as finanças on chain em conformidade?
Continuo notando que a conformidade em cripto ainda é tratada como papelada em torno da transação, em vez de lógica dentro da própria transação.

Esse modelo fazia sentido em sistemas financeiros mais antigos, nos quais restrições de aprovação e revisões podiam ficar em camadas operacionais separadas. Mas as finanças onchain não funcionam assim. Contratos inteligentes executam automaticamente, o valor é liquidado rapidamente e as transações não pausam para que uma equipe de conformidade interprete manualmente a política depois do fato.

Se a liquidação já é programável, então a conformidade provavelmente também precisa ser programável.

É essa a parte do Newton Protocol que acho especialmente interessante.

A Newton não trata a conformidade como uma lista externa anexada a uma transação. Ela transforma política em algo que o sistema consegue avaliar antes da execução. Ao usar política como código com ferramentas como Rego e Open Policy Agent, regras de transação podem ser escritas como lógica legível por máquina, em vez de ficarem enterradas em PDFs de procedimentos internos ou em lógica de produto codificada de forma rígida.

Isso muda completamente o papel da conformidade.

Um limite de transferência vira lógica programável.

Uma restrição de jurisdição vira lógica programável.

Um requisito de elegibilidade do investidor vira lógica programável.

Uma checagem de sanções vira lógica programável.

Quando essas regras são expressas como código, a conformidade deixa de ser um processo operacional frouxo e passa a se comportar como infraestrutura. Ela vira algo que software consegue avaliar de maneira consistente antes que o valor se mova.

Para mim, essa é a mudança real que a Newton está impulsionando.

Contratos inteligentes tornaram a liquidação programável.

A Newton está tentando fazer o mesmo para a política.

E, se as finanças onchain vão dar suporte a atividades financeiras mais sérias, provavelmente a conformidade não pode ficar como papelada fora do sistema para sempre.

@NewtonProtocol $NEWT #Newt $M $US

Qual é o maior gargalo para as finanças on chain em conformidade?
Manual Compliance Processes
60%
Slow Settlement Systems
10%
Limited Scalability
10%
Lack of Programmable Policy
20%
10 Votos • Votação encerrada
O conteúdo citado foi removido
Verificado
Artigo
Como políticas programáveis transformam a conformidade em códigoQuando as pessoas falam sobre conformidade em finanças, a conversa geralmente soa administrativa. Ela evoca requisitos legais formulários de onboarding aprovações internas e longas listas operacionais de verificação. O processo muitas vezes parece separado da própria infraestrutura, como se a conformidade existisse fora da transação em vez de dentro do sistema que a rege. Quanto mais eu observo a evolução das finanças on-chain, mais acho que esse modelo está começando a falhar. Sistemas de blockchain movimentam valor por meio de código. Contratos inteligentes não dependem de equipes do back office para atualizar saldos ou verificar manualmente a execução. Eles seguem regras determinísticas e produzem resultados automaticamente. Mas, se a liquidação já se tornou programável, a próxima pergunta lógica é se a conformidade também pode se tornar programável.

Como políticas programáveis transformam a conformidade em código

Quando as pessoas falam sobre conformidade em finanças, a conversa geralmente soa administrativa. Ela evoca requisitos legais formulários de onboarding aprovações internas e longas listas operacionais de verificação. O processo muitas vezes parece separado da própria infraestrutura, como se a conformidade existisse fora da transação em vez de dentro do sistema que a rege.
Quanto mais eu observo a evolução das finanças on-chain, mais acho que esse modelo está começando a falhar.
Sistemas de blockchain movimentam valor por meio de código. Contratos inteligentes não dependem de equipes do back office para atualizar saldos ou verificar manualmente a execução. Eles seguem regras determinísticas e produzem resultados automaticamente. Mas, se a liquidação já se tornou programável, a próxima pergunta lógica é se a conformidade também pode se tornar programável.
Eu costumava achar que autorização e liquidação eram apenas dois nomes diferentes para o mesmo processo de transação. Quanto mais eu explorava a infraestrutura financeira, mais percebi que elas resolvem problemas completamente diferentes. Liquidação é o movimento final de valor. Ela atualiza registros de saldos, mudanças de propriedade e dá à transação seu estado final na blockchain. É aí que as blockchains públicas provaram sua força por anos. A autorização tem uma finalidade diferente. Ela acontece antes da execução e se concentra em uma única pergunta: esta transação deve seguir em frente? Em vez de registrar um resultado, a autorização avalia a transação antes mesmo de a liquidação começar. As redes tradicionais de pagamentos sempre separaram essas responsabilidades. Um pedido de pagamento é autorizado primeiro e, depois, liquidado. Cada etapa desempenha um papel diferente, permitindo que os sistemas financeiros tomem decisões antes que o valor mude de mãos. O que chamou minha atenção é que o Newton Protocol aplica o mesmo princípio arquitetural às finanças onchain. Em vez de alterar a liquidação da blockchain, o Newton introduz uma camada dedicada de autorização que avalia a intenção da transação antes da execução. A liquidação continua fazendo o que já faz bem, enquanto a autorização se torna uma responsabilidade separada dentro do ciclo de vida da transação. Quanto mais penso nisso, mais essa separação faz sentido. A liquidação responde o que aconteceu. A autorização responde se deveria acontecer. Essas são perguntas diferentes e merecem infraestruturas diferentes. Entender essa distinção mudou a forma como eu vejo a arquitetura de blockchain. O futuro das finanças onchain pode não depender apenas de melhorar a liquidação. Talvez dependa também de reconhecer que a autorização e a liquidação funcionam melhor quando se complementam, em vez de tentar fazer o mesmo trabalho. @NewtonProtocol $NEWT #Newt Qual camada é mais importante para o futuro das finanças on-chain?
Eu costumava achar que autorização e liquidação eram apenas dois nomes diferentes para o mesmo processo de transação. Quanto mais eu explorava a infraestrutura financeira, mais percebi que elas resolvem problemas completamente diferentes.

Liquidação é o movimento final de valor. Ela atualiza registros de saldos, mudanças de propriedade e dá à transação seu estado final na blockchain. É aí que as blockchains públicas provaram sua força por anos.

A autorização tem uma finalidade diferente.

Ela acontece antes da execução e se concentra em uma única pergunta: esta transação deve seguir em frente? Em vez de registrar um resultado, a autorização avalia a transação antes mesmo de a liquidação começar.

As redes tradicionais de pagamentos sempre separaram essas responsabilidades. Um pedido de pagamento é autorizado primeiro e, depois, liquidado. Cada etapa desempenha um papel diferente, permitindo que os sistemas financeiros tomem decisões antes que o valor mude de mãos.

O que chamou minha atenção é que o Newton Protocol aplica o mesmo princípio arquitetural às finanças onchain.

Em vez de alterar a liquidação da blockchain, o Newton introduz uma camada dedicada de autorização que avalia a intenção da transação antes da execução. A liquidação continua fazendo o que já faz bem, enquanto a autorização se torna uma responsabilidade separada dentro do ciclo de vida da transação.

Quanto mais penso nisso, mais essa separação faz sentido.

A liquidação responde o que aconteceu.

A autorização responde se deveria acontecer.

Essas são perguntas diferentes e merecem infraestruturas diferentes.

Entender essa distinção mudou a forma como eu vejo a arquitetura de blockchain. O futuro das finanças onchain pode não depender apenas de melhorar a liquidação. Talvez dependa também de reconhecer que a autorização e a liquidação funcionam melhor quando se complementam, em vez de tentar fazer o mesmo trabalho.

@NewtonProtocol $NEWT #Newt

Qual camada é mais importante para o futuro das finanças on-chain?
Authorization
67%
Settlement
0%
Both are Equally Important
33%
It Depends on the use Case
0%
3 Votos • Votação encerrada
Verificado
Artigo
Por que a Autorização é Diferente da LiquidaçãoQuando as pessoas falam sobre infraestrutura de blockchain, a conversa geralmente gira em torno de velocidade das transações, segurança da rede e finalidade. Essas discussões muitas vezes tratam todo o processo de transação como um único evento, mas na realidade existem duas responsabilidades muito diferentes dentro de cada sistema financeiro: autorização e liquidação. Por muito tempo, eu assumi que eram apenas nomes diferentes para o mesmo processo. Quanto mais eu explorava a infraestrutura financeira, mais eu percebia que elas resolvem problemas totalmente diferentes.

Por que a Autorização é Diferente da Liquidação

Quando as pessoas falam sobre infraestrutura de blockchain, a conversa geralmente gira em torno de velocidade das transações, segurança da rede e finalidade. Essas discussões muitas vezes tratam todo o processo de transação como um único evento, mas na realidade existem duas responsabilidades muito diferentes dentro de cada sistema financeiro: autorização e liquidação.
Por muito tempo, eu assumi que eram apenas nomes diferentes para o mesmo processo. Quanto mais eu explorava a infraestrutura financeira, mais eu percebia que elas resolvem problemas totalmente diferentes.
Eu costumava achar que as blockchains já tinham resolvido o maior desafio das finanças porque conseguiam liquidar transações sem depender de um intermediário central. Quanto mais eu explorava a infraestrutura on-chain, mais eu percebia que a liquidação responde apenas parte da equação. Uma blockchain consegue confirmar que uma transação é válida de acordo com as regras da rede. Nem sempre ela responde se essa transação deve prosseguir antes da execução. Essa diferença se torna cada vez mais importante à medida que stablecoins tokenizam ativos e as aplicações institucionais se expandem por blockchains públicas. Sistemas financeiros frequentemente exigem decisões antes de o valor se mover — não depois. Uma vez que uma transação é liquidada, reverter o resultado raramente é simples. É por isso que acho a abordagem do Newton Protocol interessante. Em vez de competir com blockchains existentes, o NewtonProtocol introduz uma camada de autorização que fica entre a intenção da transação e a execução. A ideia não é substituir a liquidação, mas complementá-la, permitindo que transações sejam avaliadas antes de serem finalizadas. Isso cria um fluxo de transação mais completo, preservando o papel que as blockchains já desempenham bem. Visto dessa forma, isso muda como eu penso sobre finanças on-chain. Talvez a próxima etapa da infraestrutura de blockchain não seja apenas sobre processar mais transações a cada segundo. Pode ser também sobre introduzir uma tomada de decisão melhor antes que essas transações aconteçam. A liquidação registra o que aconteceu. A autorização ajuda a determinar se a execução deve acontecer em primeiro lugar. Isso parece menos como mais um recurso de blockchain e mais como uma camada adicional de infraestrutura, projetada para um ecossistema financeiro mais maduro. @NewtonProtocol $NEWT #Newt Qual é a camada ausente mais importante nas finanças on-chain?
Eu costumava achar que as blockchains já tinham resolvido o maior desafio das finanças porque conseguiam liquidar transações sem depender de um intermediário central.

Quanto mais eu explorava a infraestrutura on-chain, mais eu percebia que a liquidação responde apenas parte da equação.

Uma blockchain consegue confirmar que uma transação é válida de acordo com as regras da rede. Nem sempre ela responde se essa transação deve prosseguir antes da execução.

Essa diferença se torna cada vez mais importante à medida que stablecoins tokenizam ativos e as aplicações institucionais se expandem por blockchains públicas. Sistemas financeiros frequentemente exigem decisões antes de o valor se mover — não depois. Uma vez que uma transação é liquidada, reverter o resultado raramente é simples.

É por isso que acho a abordagem do Newton Protocol interessante.

Em vez de competir com blockchains existentes, o NewtonProtocol introduz uma camada de autorização que fica entre a intenção da transação e a execução. A ideia não é substituir a liquidação, mas complementá-la, permitindo que transações sejam avaliadas antes de serem finalizadas. Isso cria um fluxo de transação mais completo, preservando o papel que as blockchains já desempenham bem.

Visto dessa forma, isso muda como eu penso sobre finanças on-chain.

Talvez a próxima etapa da infraestrutura de blockchain não seja apenas sobre processar mais transações a cada segundo. Pode ser também sobre introduzir uma tomada de decisão melhor antes que essas transações aconteçam.

A liquidação registra o que aconteceu.

A autorização ajuda a determinar se a execução deve acontecer em primeiro lugar.

Isso parece menos como mais um recurso de blockchain e mais como uma camada adicional de infraestrutura, projetada para um ecossistema financeiro mais maduro.

@NewtonProtocol $NEWT #Newt

Qual é a camada ausente mais importante nas finanças on-chain?
Faster Settlement
100%
Better Authorization
0%
Lower Transaction Fees
0%
Greater Scalability
0%
1 Votos • Votação encerrada
Artigo
Por que as Finanças Onchain Precisam de uma Camada de AutorizaçãoPor anos, a inovação em blockchain se concentrou em tornar as transações mais rápidas, mais baratas e mais transparentes. As redes competem em taxa de transferência, finalização, escalabilidade e interoperabilidade porque a liquidação sempre foi vista como a base das finanças descentralizadas. Mas quanto mais estudo a infraestrutura onchain, mais penso que a liquidação nunca foi a história inteira. Cada transação começa com uma intenção. Alguém decide transferir valor, interagir com um contrato inteligente ou executar uma ação financeira. As blockchains são excelentes para registrar o resultado dessa decisão, mas raramente avaliam se a transação deveria prosseguir antes da execução. Assim que assinaturas válidas e regras de protocolo são atendidas, a liquidação acontece.

Por que as Finanças Onchain Precisam de uma Camada de Autorização

Por anos, a inovação em blockchain se concentrou em tornar as transações mais rápidas, mais baratas e mais transparentes. As redes competem em taxa de transferência, finalização, escalabilidade e interoperabilidade porque a liquidação sempre foi vista como a base das finanças descentralizadas.
Mas quanto mais estudo a infraestrutura onchain, mais penso que a liquidação nunca foi a história inteira.
Cada transação começa com uma intenção. Alguém decide transferir valor, interagir com um contrato inteligente ou executar uma ação financeira. As blockchains são excelentes para registrar o resultado dessa decisão, mas raramente avaliam se a transação deveria prosseguir antes da execução. Assim que assinaturas válidas e regras de protocolo são atendidas, a liquidação acontece.
A qualidade sempre deve importar mais do que a quantidade. Criadores merecem recompensas justas por pesquisas reais e insights originais. Está na hora de a Binance repensar essas exigências diárias de conteúdo. @richardteng @Binance_Square_Official
A qualidade sempre deve importar mais do que a quantidade.
Criadores merecem recompensas justas por pesquisas reais e insights originais.
Está na hora de a Binance repensar essas exigências diárias de conteúdo. @Richard Teng @Binance Square Official
Nadyisom
·
--
Por que as tarefas diárias de conteúdo da Binance estão explorando criadores É hora de mudar os critérios
Eu negociei criptomoedas em tempo integral desde 2018 e criei conteúdo sobre DeFi, agentes de IA e projetos de blockchain por anos. Plataformas como a Binance Square e seus programas Write-to-Earn e creatorpad deveriam recompensar criadores. Ainda assim, quando vejo alguns dos requisitos mais recentes de suas tarefas, fico genuinamente desapontado(a).
A Binance parece estar impulsionando um modelo em que os criadores precisam entregar uma postagem curta, um artigo completo e uma postagem no X todos os dias, por 15 dias seguidos. Todo esse esforço apenas para ganhar um total de 40 a 60 USDT.
Meu TP 0.45 e SL 0.21 $BSB
Meu TP 0.45 e SL 0.21 $BSB
Um pensamento voltou constantemente ao estudar a OpenGradient. Por anos, pensei que as blockchains foram projetadas principalmente para registrar transações. Mover valor. Armazenar dados. Alcançar consenso. Quanto mais exploro a infraestrutura de IA, mais penso que o próximo papel delas pode ser muito diferente. A IA traz um novo desafio. A pergunta mais importante nem sempre é se uma transação aconteceu. É se um sistema inteligente chegou à sua conclusão de uma forma que possa ser confiável. Isso muda o que as blockchains estão sendo solicitadas a fazer. Uma coisa que se destaca na OpenGradient é o seu foco em IA verificável, em vez de simplesmente levar IA para dentro de uma blockchain. Em vez de tratar a blockchain como o lugar onde a inteligência acontece, a arquitetura a trata como parte de um processo mais amplo de verificação que ajuda a estabelecer confiança na execução de IA. Essa distinção parece ser importante. À medida que os sistemas de IA se tornam mais capazes, a confiança nas suas decisões pode se tornar tão valiosa quanto as decisões em si. Quanto mais me aprofundo na arquitetura da OpenGradient, mais acredito que as blockchains estão evoluindo além da infraestrutura financeira. Elas estão se tornando infraestrutura para confiança. Talvez o próximo grande papel da blockchain não seja processar mais transações. Será ajudar a verificar a inteligência em um mundo em que sistemas de IA estão tomando decisões cada vez mais importantes. Às vezes, a maior evolução de uma tecnologia não é mudar o que ela é. É expandir o que ela torna possível. @OpenGradient $OPG #OPG $TAC $BSB Qual será o maior papel da blockchain na era da IA?
Um pensamento voltou constantemente ao estudar a OpenGradient.

Por anos, pensei que as blockchains foram projetadas principalmente para registrar transações.

Mover valor.

Armazenar dados.

Alcançar consenso.

Quanto mais exploro a infraestrutura de IA, mais penso que o próximo papel delas pode ser muito diferente.

A IA traz um novo desafio.

A pergunta mais importante nem sempre é se uma transação aconteceu.

É se um sistema inteligente chegou à sua conclusão de uma forma que possa ser confiável.

Isso muda o que as blockchains estão sendo solicitadas a fazer.

Uma coisa que se destaca na OpenGradient é o seu foco em IA verificável, em vez de simplesmente levar IA para dentro de uma blockchain.

Em vez de tratar a blockchain como o lugar onde a inteligência acontece, a arquitetura a trata como parte de um processo mais amplo de verificação que ajuda a estabelecer confiança na execução de IA.

Essa distinção parece ser importante.

À medida que os sistemas de IA se tornam mais capazes, a confiança nas suas decisões pode se tornar tão valiosa quanto as decisões em si.

Quanto mais me aprofundo na arquitetura da OpenGradient, mais acredito que as blockchains estão evoluindo além da infraestrutura financeira.

Elas estão se tornando infraestrutura para confiança.

Talvez o próximo grande papel da blockchain não seja processar mais transações.

Será ajudar a verificar a inteligência em um mundo em que sistemas de IA estão tomando decisões cada vez mais importantes.

Às vezes, a maior evolução de uma tecnologia não é mudar o que ela é.

É expandir o que ela torna possível.

@OpenGradient

$OPG #OPG $TAC $BSB

Qual será o maior papel da blockchain na era da IA?
Processing Transactions
67%
Storing Data
0%
Verifying AI
33%
Coordinating networks
0%
6 Votos • Votação encerrada
J U L I E
·
--
[Terminado] 🎙️ Um novo capítulo começa🌸 hoje é o meu dia 😁🎂
448 reproduções
O que você acha que será o próximo movimento de $ZEC 250$ ou 650$ {future}(ZECUSDT)
O que você acha que será o próximo movimento de $ZEC 250$ ou 650$
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma