Binance Square
AHMAÐ
4.5k Publicações

AHMAÐ

Binance Square verificado
DCA: Don't Care Anymore
Detentor de DEXE
Detentor de DEXE
Trader Frequente
2 ano(s)
276 A seguir
32.0K+ Seguidores
11.0K+ Gostaram
Publicações
·
--
Alguém abriu um $BTC long de $70 milhões com 40x de alavancagem Ele está a apenas $460 da liquidação agora.
Alguém abriu um $BTC long de $70 milhões
com 40x de alavancagem

Ele está a apenas $460 da liquidação agora.
·
--
Em Alta
🍎 $AAPL Apple acabou de entrar na era dos dobráveis. O primeiro iPhone dobrável deve chegar com um preço inicial de US$ 1.999. Por que isso importa para o cripto? O enorme ecossistema da Apple pode acelerar a adoção de pagamentos digitais, ativos tokenizados e experiências de Web3 no celular. Um dispositivo premium, uma base gigantesca de usuários e, possivelmente, um novo portal para a economia digital. 👀 #Apple
🍎 $AAPL Apple acabou de entrar na era dos dobráveis.

O primeiro iPhone dobrável deve chegar com um preço inicial de US$ 1.999.

Por que isso importa para o cripto?

O enorme ecossistema da Apple pode acelerar a adoção de pagamentos digitais, ativos tokenizados e experiências de Web3 no celular.

Um dispositivo premium, uma base gigantesca de usuários e, possivelmente, um novo portal para a economia digital. 👀

#Apple
·
--
O mercado vai permanecer normal ou sofrer uma correção?
O mercado vai permanecer normal ou sofrer uma correção?
·
--
·
--
Mapa de calor (capitalização de mercado das 30 principais) $DEBIT $DEXE
Mapa de calor (capitalização de mercado das 30 principais)
$DEBIT $DEXE
·
--
Mapa de calor (Volume de negociação dos 30 principais) $DEXE $AAPL.US
Mapa de calor (Volume de negociação dos 30 principais)
$DEXE $AAPL.US
BTC+0,72%
DEXE-0,62%
AAPLUS+1,86%
·
--
O DETALHE DA DUSK AO CREPÚSCULO QUE PODE IMPORTAR MAIS À MEDIDA QUE OS TRABALHOS DE PRIVACIDADE CRESCEM Eu estava analisando novamente a arquitetura de execução da Dusk e uma decisão de design se destacou: a Dusk não força que cada operação criptográfica cara aconteça inteiramente dentro da VM. A Piecrust oferece o ambiente de execução WASM, mas a Dusk usa funções do host para lidar com operações como hashing, verificação de provas e validação de assinaturas. O whitepaper afirma que isso permite que tarefas criptográficas complexas sejam executadas com mais eficiência do que seriam apenas dentro da VM. Uma rede financeira com foco em privacidade não está apenas processando transferências comuns. A arquitetura dela depende fortemente de verificação criptográfica, e essas operações podem se tornar uma carga computacional significativa conforme o uso aumenta. Ao mover primitivas caras para funções do host, cria-se uma separação: a VM lida com a execução de contratos, enquanto uma infraestrutura especializada lida com operações criptográficas pesadas. O whitepaper também aponta que os resultados são replicados entre os nós, então a otimização não deveria eliminar a exigência descentralizada de verificação. Mas há um equilíbrio que eu acho vale acompanhar. Quanto mais funcionalidade é transferida para capacidades especializadas do host, mais importante se torna a interface entre a VM e essas capacidades. Você ganha desempenho e eficiência, mas o ambiente de execução também passa a depender mais de infraestrutura específica do protocolo. Para a Dusk, isso pode ser um trade-off razoável. Se a rede quiser aplicações que preservem a privacidade com cargas de ZK significativas, tratar o cálculo criptográfico como uma preocupação de infraestrutura de primeira classe faz mais sentido do que fingir que toda operação é apenas mais uma instrução WASM. O teste real é se essa arquitetura continua oferecendo eficiência conforme as cargas de privacidade se expandem. A execução criptográfica especializada é o caminho certo para tornar a privacidade prática em escala de rede? @Dusk_Foundation $DUSK #dusk
O DETALHE DA DUSK AO CREPÚSCULO QUE PODE IMPORTAR MAIS À MEDIDA QUE OS TRABALHOS DE PRIVACIDADE CRESCEM

Eu estava analisando novamente a arquitetura de execução da Dusk e uma decisão de design se destacou: a Dusk não força que cada operação criptográfica cara aconteça inteiramente dentro da VM.
A Piecrust oferece o ambiente de execução WASM, mas a Dusk usa funções do host para lidar com operações como hashing, verificação de provas e validação de assinaturas. O whitepaper afirma que isso permite que tarefas criptográficas complexas sejam executadas com mais eficiência do que seriam apenas dentro da VM.

Uma rede financeira com foco em privacidade não está apenas processando transferências comuns. A arquitetura dela depende fortemente de verificação criptográfica, e essas operações podem se tornar uma carga computacional significativa conforme o uso aumenta.

Ao mover primitivas caras para funções do host, cria-se uma separação:
a VM lida com a execução de contratos, enquanto uma infraestrutura especializada lida com operações criptográficas pesadas.

O whitepaper também aponta que os resultados são replicados entre os nós, então a otimização não deveria eliminar a exigência descentralizada de verificação.

Mas há um equilíbrio que eu acho vale acompanhar.
Quanto mais funcionalidade é transferida para capacidades especializadas do host, mais importante se torna a interface entre a VM e essas capacidades. Você ganha desempenho e eficiência, mas o ambiente de execução também passa a depender mais de infraestrutura específica do protocolo.

Para a Dusk, isso pode ser um trade-off razoável.
Se a rede quiser aplicações que preservem a privacidade com cargas de ZK significativas, tratar o cálculo criptográfico como uma preocupação de infraestrutura de primeira classe faz mais sentido do que fingir que toda operação é apenas mais uma instrução WASM.

O teste real é se essa arquitetura continua oferecendo eficiência conforme as cargas de privacidade se expandem.

A execução criptográfica especializada é o caminho certo para tornar a privacidade prática em escala de rede?
@Dusk $DUSK #dusk
·
--
$BTC ultrapassou US$ 81 mil. Vai chegar a US$ 100 mil?
$BTC ultrapassou US$ 81 mil. Vai chegar a US$ 100 mil?
·
--
Eu estava olhando para o modelo de transação transparente da Dusk e, inicialmente, passei por cima de algo que soava quase bom demais para ser verdade: o nonce. Moonlight é o modelo de transações baseado em contas da Dusk. Cada conta tem uma chave pública, um saldo e um nonce, sendo que o nonce atua como um contador das transações enviadas a partir daquela conta. Esse pequeno contador tem uma função maior do que parece à primeira vista. O whitepaper conecta explicitamente o nonce à proteção contra replay. Uma transação não é apenas autorizada porque a assinatura é válida; a sequência de transações da conta também precisa fazer sentido. Esta é uma daquelas peças da infraestrutura de blockchain que os usuários quase nunca notam quando funciona corretamente. Você assina uma transação, a rede a processa, seu saldo muda e você segue em frente. Mas sem mecanismos que impeçam que uma transação válida e antiga seja aceita novamente, a mesma autorização poderia potencialmente se transformar em um problema de segurança completamente diferente. O que acho interessante sobre a Dusk é que Moonlight e Phoenix resolvem os mesmos requisitos fundamentais de transação por meio de modelos bem diferentes. Moonlight expõe publicamente o estado da conta, os saldos e os metadados da transação. Phoenix leva a verificação de saldo e a proteção contra double-spend para dentro de provas ZK e nullifiers. Ainda assim, ambos precisam estabelecer propriedade, impedir malleabilidade e parar double spending. Então a decisão de design real não é simplesmente pública vs. privada. É quanto da transição de estado a rede consegue verificar diretamente versus quanto precisa ser provado criptograficamente. Isso torna o humilde nonce mais interessante do que parece. A transação visível é apenas a superfície. Por baixo dela há um conjunto de regras garantindo que a mesma autorização não possa simplesmente ser repetida. Quantos “recursos” de blockchain são, na verdade, suposições invisíveis de segurança que os usuários só percebem quando falham? @Dusk_Foundation $DUSK #dusk
Eu estava olhando para o modelo de transação transparente da Dusk e, inicialmente, passei por cima de algo que soava quase bom demais para ser verdade: o nonce.

Moonlight é o modelo de transações baseado em contas da Dusk. Cada conta tem uma chave pública, um saldo e um nonce, sendo que o nonce atua como um contador das transações enviadas a partir daquela conta.

Esse pequeno contador tem uma função maior do que parece à primeira vista.

O whitepaper conecta explicitamente o nonce à proteção contra replay. Uma transação não é apenas autorizada porque a assinatura é válida; a sequência de transações da conta também precisa fazer sentido.

Esta é uma daquelas peças da infraestrutura de blockchain que os usuários quase nunca notam quando funciona corretamente.

Você assina uma transação, a rede a processa, seu saldo muda e você segue em frente.
Mas sem mecanismos que impeçam que uma transação válida e antiga seja aceita novamente, a mesma autorização poderia potencialmente se transformar em um problema de segurança completamente diferente.
O que acho interessante sobre a Dusk é que Moonlight e Phoenix resolvem os mesmos requisitos fundamentais de transação por meio de modelos bem diferentes.

Moonlight expõe publicamente o estado da conta, os saldos e os metadados da transação. Phoenix leva a verificação de saldo e a proteção contra double-spend para dentro de provas ZK e nullifiers. Ainda assim, ambos precisam estabelecer propriedade, impedir malleabilidade e parar double spending.

Então a decisão de design real não é simplesmente pública vs. privada.

É quanto da transição de estado a rede consegue verificar diretamente versus quanto precisa ser provado criptograficamente.
Isso torna o humilde nonce mais interessante do que parece.

A transação visível é apenas a superfície. Por baixo dela há um conjunto de regras garantindo que a mesma autorização não possa simplesmente ser repetida.

Quantos “recursos” de blockchain são, na verdade, suposições invisíveis de segurança que os usuários só percebem quando falham?

@Dusk $DUSK #dusk
·
--
A PARTE MAIS INTERESSANTE DO MODELO DE PRIVACIDADE DA DUSK PODE SER O QUE ELE NÃO COLOCA ONCHAIN Fiquei pensando na arquitetura de privacidade da Dusk a partir do sentido oposto: não no que ela esconde, mas no que a rede ainda precisa saber. A Phoenix usa UTXOs blindados, nos quais as notas são comprometidas em uma árvore de Merkle e gastas usando nullifiers. A transação subjacente pode permanecer confidencial enquanto a rede verifica as regras necessárias para transições válidas de estado. Isso cria uma divisão muito específica da informação. O whitepaper descreve a estrutura da transação como contendo a raiz de Merkle, nullifiers, novas notas, depósitos/dados opcionais, parâmetros de gás e uma prova ZK. A rede verifica a prova em relação a entradas públicas, em vez de checar diretamente os detalhes escondidos da transação. Mas aqui vai o detalhe que eu acho mais importante. A Dusk não está tentando tornar tudo invisível permanentemente. A arquitetura também inclui o Citadel 2, onde os usuários podem divulgar credenciais de forma seletiva quando uma aplicação precisa de prova de elegibilidade. O Executive Summary descreve isso como permitindo que um usuário comprove a posse de uma licença registrada sem revelar o conteúdo da licença. Então o design não é realmente: privado vs público. É mais próximo de: privado por padrão + provar apenas o que a aplicação exige. Esse é um modelo muito mais útil para finanças reguladas. Mas ainda existe uma questão operacional não resolvida. A pesquisa destaca especificamente a possibilidade de que a integração com sistemas de KYC e informações de sessão possa criar capacidade de vinculação (linkability), mesmo quando os dados pessoais subjacentes não são armazenados onchain. A criptografia pode proteger a transação. Ela não consegue garantir automaticamente que cada aplicação construída em torno da transação preserve as mesmas propriedades de privacidade. Essa é a parte que eu observaria. A Dusk consegue manter a divulgação seletiva sem permitir que a infraestrutura de conformidade ao redor recrie silenciosamente a vigilância que ela foi desenhada para evitar? @Dusk_Foundation $DUSK #dusk
A PARTE MAIS INTERESSANTE DO MODELO DE PRIVACIDADE DA DUSK PODE SER O QUE ELE NÃO COLOCA ONCHAIN

Fiquei pensando na arquitetura de privacidade da Dusk a partir do sentido oposto: não no que ela esconde, mas no que a rede ainda precisa saber.
A Phoenix usa UTXOs blindados, nos quais as notas são comprometidas em uma árvore de Merkle e gastas usando nullifiers. A transação subjacente pode permanecer confidencial enquanto a rede verifica as regras necessárias para transições válidas de estado.

Isso cria uma divisão muito específica da informação.

O whitepaper descreve a estrutura da transação como contendo a raiz de Merkle, nullifiers, novas notas, depósitos/dados opcionais, parâmetros de gás e uma prova ZK. A rede verifica a prova em relação a entradas públicas, em vez de checar diretamente os detalhes escondidos da transação.

Mas aqui vai o detalhe que eu acho mais importante.
A Dusk não está tentando tornar tudo invisível permanentemente.

A arquitetura também inclui o Citadel 2, onde os usuários podem divulgar credenciais de forma seletiva quando uma aplicação precisa de prova de elegibilidade. O Executive Summary descreve isso como permitindo que um usuário comprove a posse de uma licença registrada sem revelar o conteúdo da licença.

Então o design não é realmente:
privado vs público.
É mais próximo de:
privado por padrão + provar apenas o que a aplicação exige.

Esse é um modelo muito mais útil para finanças reguladas.

Mas ainda existe uma questão operacional não resolvida. A pesquisa destaca especificamente a possibilidade de que a integração com sistemas de KYC e informações de sessão possa criar capacidade de vinculação (linkability), mesmo quando os dados pessoais subjacentes não são armazenados onchain.

A criptografia pode proteger a transação.
Ela não consegue garantir automaticamente que cada aplicação construída em torno da transação preserve as mesmas propriedades de privacidade.
Essa é a parte que eu observaria.

A Dusk consegue manter a divulgação seletiva sem permitir que a infraestrutura de conformidade ao redor recrie silenciosamente a vigilância que ela foi desenhada para evitar?
@Dusk $DUSK #dusk
·
--
$DUSK
$DUSK
Noor221
·
--
Em Alta
Qual é a melhor moeda para manter.... qual moeda dá grande lucro...$BTC

$BNB

$ETH
·
--
POR QUE O CERTIFICADO DE BLOCO DO DUSK É MAIS INTERESSANTE DO QUE “FINALIDADE RÁPIDA” Eu ficava vendo o consenso do Dusk descrito por meio de finalidade determinística, mas o mecanismo por trás tem um detalhe que acho que merece mais atenção: a rede precisa saber exatamente quais eleitores foram responsáveis por um bloco finalizado. A Atestação Succinct do Dusk usa comitês de votação para validação e ratificação. Cada comitê atualmente tem um parâmetro global de 64 créditos, e os votos são ponderados de acordo com os créditos atribuídos a cada provedor. A parte interessante surge quando há mais votos do que o limite de quorum. O whitepaper explica que, de outra forma, poderiam existir múltiplas atestações válidas para a mesma iteração. Por isso, o Dusk inclui uma atestação do bloco anterior dentro de cada bloco, criando um certificado de bloco que determina um conjunto único de eleitores. Esse conjunto único de eleitores é então usado para contabilização de recompensas e penalidades. Isso parece um pequeno detalhe de implementação até você pensar sobre o sistema de incentivos. Consenso não decide apenas: “Este bloco é válido?” Ele também estabelece: “Quais participantes exatos devem receber crédito ou penalidades por este resultado?” O Dusk então usa assinaturas BLS para que votos de uma etapa específica possam ser agregados em uma única assinatura, enquanto um bitset identifica quais membros do comitê de fato participaram. Eu considero essa separação importante porque, em geral, a economia dos validadores e a correção do consenso são discutidas como se fossem independentes. Aqui elas estão conectadas pela estrutura da atestação. A questão restante é o que acontece operacionalmente quando os comitês falham repetidamente em alcançar o quorum. O whitepaper diz que uma rodada pode iterar novamente, com um máximo atualmente definido em 50 iterações, mas o teste real e interessante é com que frequência a rede realmente se aproxima desses casos-limite sob condições adversas. A finalidade rápida vira manchete. A contabilização de quem de fato garantiu essa finalidade é a parte que acho mais reveladora. @Dusk_Foundation $DUSK #dusk
POR QUE O CERTIFICADO DE BLOCO DO DUSK É MAIS INTERESSANTE DO QUE “FINALIDADE RÁPIDA”
Eu ficava vendo o consenso do Dusk descrito por meio de finalidade determinística, mas o mecanismo por trás tem um detalhe que acho que merece mais atenção: a rede precisa saber exatamente quais eleitores foram responsáveis por um bloco finalizado.

A Atestação Succinct do Dusk usa comitês de votação para validação e ratificação. Cada comitê atualmente tem um parâmetro global de 64 créditos, e os votos são ponderados de acordo com os créditos atribuídos a cada provedor.
A parte interessante surge quando há mais votos do que o limite de quorum.
O whitepaper explica que, de outra forma, poderiam existir múltiplas atestações válidas para a mesma iteração. Por isso, o Dusk inclui uma atestação do bloco anterior dentro de cada bloco, criando um certificado de bloco que determina um conjunto único de eleitores. Esse conjunto único de eleitores é então usado para contabilização de recompensas e penalidades.
Isso parece um pequeno detalhe de implementação até você pensar sobre o sistema de incentivos.
Consenso não decide apenas:
“Este bloco é válido?”
Ele também estabelece:
“Quais participantes exatos devem receber crédito ou penalidades por este resultado?”
O Dusk então usa assinaturas BLS para que votos de uma etapa específica possam ser agregados em uma única assinatura, enquanto um bitset identifica quais membros do comitê de fato participaram.
Eu considero essa separação importante porque, em geral, a economia dos validadores e a correção do consenso são discutidas como se fossem independentes.

Aqui elas estão conectadas pela estrutura da atestação.

A questão restante é o que acontece operacionalmente quando os comitês falham repetidamente em alcançar o quorum. O whitepaper diz que uma rodada pode iterar novamente, com um máximo atualmente definido em 50 iterações, mas o teste real e interessante é com que frequência a rede realmente se aproxima desses casos-limite sob condições adversas.

A finalidade rápida vira manchete.
A contabilização de quem de fato garantiu essa finalidade é a parte que acho mais reveladora.
@Dusk $DUSK #dusk
·
--
HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL
HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL HODL
·
--
MODELO DE IDENTIDADE DO CREPÚSCULO I MAIS INTERESSANTE QUE KYC Fiquei pensando no problema desconfortável que as finanças regulamentadas têm em blockchains públicas: as instituições precisam saber que um usuário é elegível, mas publicar a identidade do usuário e suas credenciais financeiras anula boa parte do argumento de privacidade. A Citadel 2 da Dusk aborda isso de forma diferente. Primeiro, o usuário obtém uma licença de um Provedor de Licenças confiável após um KYC fora da cadeia. A credencial é registrada on-chain, mas quando o usuário interage posteriormente com um serviço, ele pode provar a posse da credencial exigida usando provas de conhecimento zero sem expor o conteúdo da licença. O detalhe que chamou minha atenção é o que, na verdade, é colocado on-chain. De acordo com a pesquisa, a cadeia não precisa dos dados pessoais do usuário, da chave específica do Provedor de Licenças nem dos detalhes da licença. Em vez disso, a Citadel verifica uma prova genérica e cria uma sessão efêmera que o Provedor de Serviço pode usar para aplicar a própria política. Então, em teoria, uma aplicação poderia pedir: “Você é um participante credenciado/elegível?” sem exigir: “Mostre meu registro completo de identidade.” Isso cria uma relação bem mais interessante entre conformidade e privacidade. Mas há um trade-off que eu não ignoraria. A garantia de privacidade depende de como os provedores de serviço integram a camada de identidade. Se as aplicações começarem a adicionar metadados vinculáveis em torno dessas sessões, a privacidade criptográfica da credencial não garante automaticamente privacidade em toda a experiência do usuário. Por isso, estou mais interessado na camada de aplicação do que na própria alegação de conhecimento zero. A Dusk parece estar tentando separar comprovação de elegibilidade de revelação de identidade. A divulgação seletiva pode se tornar o ponto intermediário que falta entre DeFi completamente público e sistemas financeiros restritos a instituições? @Dusk_Foundation $DUSK #dusk
MODELO DE IDENTIDADE DO CREPÚSCULO I MAIS INTERESSANTE QUE KYC
Fiquei pensando no problema desconfortável que as finanças regulamentadas têm em blockchains públicas: as instituições precisam saber que um usuário é elegível, mas publicar a identidade do usuário e suas credenciais financeiras anula boa parte do argumento de privacidade.
A Citadel 2 da Dusk aborda isso de forma diferente.
Primeiro, o usuário obtém uma licença de um Provedor de Licenças confiável após um KYC fora da cadeia. A credencial é registrada on-chain, mas quando o usuário interage posteriormente com um serviço, ele pode provar a posse da credencial exigida usando provas de conhecimento zero sem expor o conteúdo da licença.
O detalhe que chamou minha atenção é o que, na verdade, é colocado on-chain.
De acordo com a pesquisa, a cadeia não precisa dos dados pessoais do usuário, da chave específica do Provedor de Licenças nem dos detalhes da licença. Em vez disso, a Citadel verifica uma prova genérica e cria uma sessão efêmera que o Provedor de Serviço pode usar para aplicar a própria política.
Então, em teoria, uma aplicação poderia pedir:
“Você é um participante credenciado/elegível?”
sem exigir:
“Mostre meu registro completo de identidade.”
Isso cria uma relação bem mais interessante entre conformidade e privacidade.
Mas há um trade-off que eu não ignoraria.
A garantia de privacidade depende de como os provedores de serviço integram a camada de identidade. Se as aplicações começarem a adicionar metadados vinculáveis em torno dessas sessões, a privacidade criptográfica da credencial não garante automaticamente privacidade em toda a experiência do usuário.
Por isso, estou mais interessado na camada de aplicação do que na própria alegação de conhecimento zero.
A Dusk parece estar tentando separar comprovação de elegibilidade de revelação de identidade.
A divulgação seletiva pode se tornar o ponto intermediário que falta entre DeFi completamente público e sistemas financeiros restritos a instituições?
@Dusk $DUSK #dusk
·
--
Isso é uma grande dica de que $BTC vai bater US$ 100 mil em breve!? Todos os olhos no touro!👀🐂
Isso é uma grande dica de que $BTC vai bater US$ 100 mil em breve!?
Todos os olhos no touro!👀🐂
·
--
Eu geralmente vejo títulos tokenizados sendo discutidos como se a parte difícil fosse colocar a propriedade onchain. Ao olhar o design do Zedger da Dusk, foquei no que acontece quando o emissor ainda tem responsabilidades depois de um ativo já ter sido emitido. O Zedger foi projetado para títulos e ativos do mundo real que podem ser tokenizados ou emitidos nativamente na Dusk. Seu modelo de contrato inclui cunhagem e queima (minting e burning), ações corporativas como dividendos, auditoria de transações e até transferências forçadas iniciadas pelo próprio emissor. Essa última capacidade é a parte para a qual eu continuei voltando. Uma narrativa cripto normal tende a equiparar propriedade de tokens a uma transferência irreversível de carteira para carteira. Títulos regulados nem sempre funcionam assim. Ordens legais, ações corporativas, procedimentos de recuperação ou requisitos específicos de jurisdição podem criar situações em que o emissor precisa de intervenção controlada. Portanto, o Zedger não está simplesmente tentando reproduzir um modelo de transferência de criptomoeda para títulos. Ele foi desenhado a partir da realidade desconfortável de que ativos regulados podem ter regras sobre quem pode mantê-los e como a propriedade pode mudar. Mas há um trade-off óbvio. Um mecanismo de transferência controlado pelo emissor pode tornar títulos regulados mais compatíveis com estruturas legais existentes, enquanto simultaneamente introduz um nível de autoridade que usuários de cripto sem permissão podem não gostar. Isso não é necessariamente uma falha. É uma decisão de design. A questão real é se a Dusk consegue tornar esses controles suficientemente transparentes e limitados para que as instituições confiem neles, sem fazer com que os usuários sintam que títulos tokenizados são apenas bancos de dados com carteiras anexadas. Talvez o futuro da infraestrutura de RWA não seja remover a autoridade humana. Talvez seja transformar essa autoridade em algo programável, auditável e explícito. Quanta autoridade do emissor uma segurança genuinamente onchain deve ter? @Dusk_Foundation $DUSK #dusk
Eu geralmente vejo títulos tokenizados sendo discutidos como se a parte difícil fosse colocar a propriedade onchain.

Ao olhar o design do Zedger da Dusk, foquei no que acontece quando o emissor ainda tem responsabilidades depois de um ativo já ter sido emitido.
O Zedger foi projetado para títulos e ativos do mundo real que podem ser tokenizados ou emitidos nativamente na Dusk. Seu modelo de contrato inclui cunhagem e queima (minting e burning), ações corporativas como dividendos, auditoria de transações e até transferências forçadas iniciadas pelo próprio emissor.

Essa última capacidade é a parte para a qual eu continuei voltando.

Uma narrativa cripto normal tende a equiparar propriedade de tokens a uma transferência irreversível de carteira para carteira. Títulos regulados nem sempre funcionam assim. Ordens legais, ações corporativas, procedimentos de recuperação ou requisitos específicos de jurisdição podem criar situações em que o emissor precisa de intervenção controlada.

Portanto, o Zedger não está simplesmente tentando reproduzir um modelo de transferência de criptomoeda para títulos. Ele foi desenhado a partir da realidade desconfortável de que ativos regulados podem ter regras sobre quem pode mantê-los e como a propriedade pode mudar.

Mas há um trade-off óbvio.

Um mecanismo de transferência controlado pelo emissor pode tornar títulos regulados mais compatíveis com estruturas legais existentes, enquanto simultaneamente introduz um nível de autoridade que usuários de cripto sem permissão podem não gostar.
Isso não é necessariamente uma falha. É uma decisão de design.

A questão real é se a Dusk consegue tornar esses controles suficientemente transparentes e limitados para que as instituições confiem neles, sem fazer com que os usuários sintam que títulos tokenizados são apenas bancos de dados com carteiras anexadas.
Talvez o futuro da infraestrutura de RWA não seja remover a autoridade humana.

Talvez seja transformar essa autoridade em algo programável, auditável e explícito.

Quanta autoridade do emissor uma segurança genuinamente onchain deve ter?
@Dusk $DUSK #dusk
·
--
Inicialmente, eu olhei para os tokens FT e XT da TermMax como uma outra forma de dividir uma posição de empréstimo. Quanto mais eu me aprofundava no mecanismo, mais importante ficava a relação contábil. Quando um credor deposita uma unidade do ativo-base, a TermMax cria uma FT e uma XT. A FT representa o principal mais a reivindicação de juros fixos, enquanto a XT representa o componente flutuante restante. Juntas, 1 FT + 1 XT = 1 unidade do ativo-base, com o valor da XT se aproximando de zero à medida que o vencimento se aproxima. Isso cria uma maneira incomum de separar exposição fixa e variável sem fingir que o ativo subjacente “virou” renda fixa magicamente. A FT pode ser negociada abaixo do seu valor de resgate de uma unidade antes do vencimento, e esse desconto, na prática, expressa a taxa fixa. A XT captura o valor residual que não está representado pela reivindicação fixa. O que acho interessante é o que isso possibilita. Em vez de tratar uma posição de empréstimo como um objeto indivisível, a TermMax transforma seus componentes econômicos em representações separadas em ERC-20. Esses componentes, então, podem participar de diferentes estratégias de mercado. A pesquisa também observa que a XT pode funcionar como um token de prêmio de opção nos mercados Alpha. Mas essa flexibilidade tem um custo: complexidade. O sistema precisa manter a relação FT/XT de forma economicamente consistente durante a negociação, o vencimento e a liquidação. Um mecanismo que oferece aos usuários mais formas de expressar exposição a taxas de juros também cria mais suposições que contratos inteligentes e mercados precisam manter corretamente. Por isso, estou menos interessado em chamar FT/XT de inovador. O teste real é se os usuários entendem o que estão segurando quando o mercado fica pressionado. Separar exposição fixa e flutuante cria primitivas financeiras genuinamente úteis, ou apenas transfere complexidade do protocolo para a experiência do usuário? @termmax #TermMax
Inicialmente, eu olhei para os tokens FT e XT da TermMax como uma outra forma de dividir uma posição de empréstimo. Quanto mais eu me aprofundava no mecanismo, mais importante ficava a relação contábil.
Quando um credor deposita uma unidade do ativo-base, a TermMax cria uma FT e uma XT. A FT representa o principal mais a reivindicação de juros fixos, enquanto a XT representa o componente flutuante restante. Juntas, 1 FT + 1 XT = 1 unidade do ativo-base, com o valor da XT se aproximando de zero à medida que o vencimento se aproxima.

Isso cria uma maneira incomum de separar exposição fixa e variável sem fingir que o ativo subjacente “virou” renda fixa magicamente.

A FT pode ser negociada abaixo do seu valor de resgate de uma unidade antes do vencimento, e esse desconto, na prática, expressa a taxa fixa. A XT captura o valor residual que não está representado pela reivindicação fixa.

O que acho interessante é o que isso possibilita.
Em vez de tratar uma posição de empréstimo como um objeto indivisível, a TermMax transforma seus componentes econômicos em representações separadas em ERC-20. Esses componentes, então, podem participar de diferentes estratégias de mercado. A pesquisa também observa que a XT pode funcionar como um token de prêmio de opção nos mercados Alpha.

Mas essa flexibilidade tem um custo: complexidade.
O sistema precisa manter a relação FT/XT de forma economicamente consistente durante a negociação, o vencimento e a liquidação. Um mecanismo que oferece aos usuários mais formas de expressar exposição a taxas de juros também cria mais suposições que contratos inteligentes e mercados precisam manter corretamente.

Por isso, estou menos interessado em chamar FT/XT de inovador.
O teste real é se os usuários entendem o que estão segurando quando o mercado fica pressionado.

Separar exposição fixa e flutuante cria primitivas financeiras genuinamente úteis, ou apenas transfere complexidade do protocolo para a experiência do usuário?
@TermMax #TermMax
·
--
$DEXE rompe sua principal resistência e os compradores estão entrando🚀 É hora decomprar mais stack. Clique abaixo para comprar👇🏻 {spot}(DEXEUSDT)
$DEXE rompe sua principal resistência e os compradores estão entrando🚀
É hora decomprar mais stack.
Clique abaixo para comprar👇🏻
·
--
🚀 O Bitcoin rompe os US$ 75K! $BTC acabou de ultrapassar a marca de 75.000 USDT, negociando atualmente a 75.523 USDT.📈 Subiu 8,23% nas últimas 24 horas!Será que este é o começo da próxima grande alta? #btc70k #strategy #Write2Earn‬
🚀 O Bitcoin rompe os US$ 75K!
$BTC acabou de ultrapassar a marca de 75.000 USDT, negociando atualmente a 75.523 USDT.📈 Subiu 8,23% nas últimas 24 horas!Será que este é o começo da próxima grande alta?

#btc70k #strategy #Write2Earn‬
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