Binance Square
EthanValeX
1.8k Paylaşımlar

EthanValeX

Sharing market insights, real-world DCA & futures strategies. No hype. No FOMO. Just discipline. Follow me.
U sahibi
U sahibi
Daimi treyder
6 il
122 İzlənilir
515 İzləyicilər
1.6K+ Bəyəndi
Postlar
·
--
Doğrulanıb
Keçən gecə nəhayət Babylon-un Trustless Bitcoin Vault testnetini sınamağa vaxt tapdım. Sənədləri oxumağı dayandırıb axınla (flow) bura-bura hərəkət etməyə başlayandan sonra, yerli Bitcoin ilə təmin edilmiş borclanmanın həqiqətən fərqli hiss olunub-olunmayacağını düşünürdüm. Axının özü təəccüblü dərəcədə sakit idi. Testnet BTC-ni mint etdim, onu bir vault-a kilidlədim, Aave v4 vasitəsilə borc aldım və Babylon-un göstərmək istədiyi şeyi gördüyümü zənn edib tab-ı bağladım. Heç bir wrapping yox idi, heç bir bridge yox idi — sadəcə yerli Bitcoin olduğu yerdə qalırdı. Sonra CreatorPad-i açdım. 34,650 nəfər artıq liderboard-da idi, 1,195,000 $BABY reward pool-dan pay uğrunda yarışırdılar və mən bu nömrəyə baxmağa borclanma axınını izlədiyimdən daha çox vaxt sərf etdim. İlk əvvəl bir az qəribə hiss etdim. TBV yerli Bitcoin ilə təmin edilmiş borclanma üzərində qurulub, amma onu ilk dəfə sınayanların çoxu çox güman Bitcoin sahibi olub likvidlik axtaranlar yox, daha çox creator-lar, maraqlı qurucular və point ovçularıdır. Bəlkə bu artıq aydındır. Bəlkə liderboard-a çox şey yükləyirəm. Yenə də elə bir hissi qıra bilmirdim: elə bil məhsulu testdən keçirmişdim, amma kampaniya tam başqa bir şeyi test edirdi. Əvvəllər düşünürdüm ki, incentive kampaniyaları əsasən istifadəçiləri cəlb etmək üçündür. Testnet ilə bir müddət vaxt keçirəndən sonra isə indi maraqlanıram: bəlkə onlar həm də stake-lər hələ aşağı ikən zəif nöqtələri üzə çıxarmaq üçündür. Testnet-dən götürəcəyim təsir bu deyildi. $LAB $BABY {future}(BABYUSDT) @babylonlabs_io #baby
Keçən gecə nəhayət Babylon-un Trustless Bitcoin Vault testnetini sınamağa vaxt tapdım. Sənədləri oxumağı dayandırıb axınla (flow) bura-bura hərəkət etməyə başlayandan sonra, yerli Bitcoin ilə təmin edilmiş borclanmanın həqiqətən fərqli hiss olunub-olunmayacağını düşünürdüm.
Axının özü təəccüblü dərəcədə sakit idi. Testnet BTC-ni mint etdim, onu bir vault-a kilidlədim, Aave v4 vasitəsilə borc aldım və Babylon-un göstərmək istədiyi şeyi gördüyümü zənn edib tab-ı bağladım. Heç bir wrapping yox idi, heç bir bridge yox idi — sadəcə yerli Bitcoin olduğu yerdə qalırdı.
Sonra CreatorPad-i açdım.
34,650 nəfər artıq liderboard-da idi, 1,195,000 $BABY reward pool-dan pay uğrunda yarışırdılar və mən bu nömrəyə baxmağa borclanma axınını izlədiyimdən daha çox vaxt sərf etdim.
İlk əvvəl bir az qəribə hiss etdim.
TBV yerli Bitcoin ilə təmin edilmiş borclanma üzərində qurulub, amma onu ilk dəfə sınayanların çoxu çox güman Bitcoin sahibi olub likvidlik axtaranlar yox, daha çox creator-lar, maraqlı qurucular və point ovçularıdır.
Bəlkə bu artıq aydındır. Bəlkə liderboard-a çox şey yükləyirəm.
Yenə də elə bir hissi qıra bilmirdim: elə bil məhsulu testdən keçirmişdim, amma kampaniya tam başqa bir şeyi test edirdi.
Əvvəllər düşünürdüm ki, incentive kampaniyaları əsasən istifadəçiləri cəlb etmək üçündür. Testnet ilə bir müddət vaxt keçirəndən sonra isə indi maraqlanıram: bəlkə onlar həm də stake-lər hələ aşağı ikən zəif nöqtələri üzə çıxarmaq üçündür.
Testnet-dən götürəcəyim təsir bu deyildi.
$LAB $BABY
@BabylonLabs_io #baby
Tərcüməyə bax
Long $KOMA {future}(KOMAUSDT) Entry 0.0237 - 0.0238 Stop Loss Dưới 0.0228. Take Profit TP1: 0.0248 TP2: 0.0263 TP3: 0.0285 nếu phá đỉnh thành công. R:R 1:2 đến 1:3
Long $KOMA
Entry
0.0237 - 0.0238
Stop Loss
Dưới 0.0228.
Take Profit
TP1: 0.0248
TP2: 0.0263
TP3: 0.0285 nếu phá đỉnh thành công.
R:R 1:2 đến 1:3
Doğrulanıb
Tərcüməyə bax
Went through Babylon's co-staking examples over coffee and kept landing on the same number. 20,000. Closed the tab to answer a few messages, came back, and every example still seemed to circle back to it. #baby @babylonlabs_io Whether the docs started with 0.1 BTC paired with 2,000 BABY, 0.5 BTC with 10,000 BABY, or 1 BTC with 20,000 BABY, they all pointed toward the same ratio. I was convinced I'd missed another rule until the final example paired 1 BTC with 40,000 BABY, yet the co-staking weight stayed exactly the same because the optimal ratio had already been reached. That was the point where I stopped looking for another formula and started wondering why the examples were designed that way in the first place. Most staking systems quietly encourage adding more capital because more usually means better rewards. Babylon does something subtler. Even though the additional co-staking rewards come from 2.35% annual inflation, the mechanism keeps leading participants back toward the same BTC-to-BABY ratio instead of rewarding whoever simply commits the largest BABY position. The more I looked at those examples, the less they felt like reward calculations and the more they felt like the protocol nudging two different communities toward the same equilibrium. Makes me wonder if 20,000 isn't really a reward ratio at all. It feels more like Babylon's way of coordinating Bitcoin holders and BABY holders without ever having to say that's what it's doing. $LAB $BABY {spot}(BABYUSDT)
Went through Babylon's co-staking examples over coffee and kept landing on the same number. 20,000. Closed the tab to answer a few messages, came back, and every example still seemed to circle back to it.
#baby @BabylonLabs_io
Whether the docs started with 0.1 BTC paired with 2,000 BABY, 0.5 BTC with 10,000 BABY, or 1 BTC with 20,000 BABY, they all pointed toward the same ratio. I was convinced I'd missed another rule until the final example paired 1 BTC with 40,000 BABY, yet the co-staking weight stayed exactly the same because the optimal ratio had already been reached. That was the point where I stopped looking for another formula and started wondering why the examples were designed that way in the first place.
Most staking systems quietly encourage adding more capital because more usually means better rewards. Babylon does something subtler. Even though the additional co-staking rewards come from 2.35% annual inflation, the mechanism keeps leading participants back toward the same BTC-to-BABY ratio instead of rewarding whoever simply commits the largest BABY position.
The more I looked at those examples, the less they felt like reward calculations and the more they felt like the protocol nudging two different communities toward the same equilibrium.
Makes me wonder if 20,000 isn't really a reward ratio at all. It feels more like Babylon's way of coordinating Bitcoin holders and BABY holders without ever having to say that's what it's doing.
$LAB $BABY
Bugün bir müddət Babylon-un “Trustless Bitcoin Vault” testnetində vaxt keçirdim, borclanma prosesinin məhz yadda saxlayacağım hissə olacağını yarı ümid edirdim. Elə olmadı. 0.10 testnet BTC mint etdim, 0.08 BTC-ni bir vault-a kilidlədim, Aave vasitəsilə 0.05 BTC borc aldım və bütün proses gözlədiyim kimi, demək olar ki, işləyirdi. Hətta 2.31 health factor-a da baxdım, təsdiq pəncərəsini bağladım və tamamlandığını düşündüm. Məndə qalan isə borclanma deyildi. O, vaultBTC-ni sonradan görmək və mən nə axtardığımı tam bilmədən belə ona instinktiv olaraq klik etməyim idi. Heç kim mənə “Send” düyməsinə klik etməyimi deməmişdi. Mən sadəcə növbəti addımın elə bu olacağını zənn etdim. Hansısa bir şeyi qaçırdığımı düşünərək bir az ətrafa baxdım, sonra sənədləri açdım. Sənədlər heç nəyi səhv başa düşmədiyimi təsdiqlədi. vaultBTC heç vaxt “yerindən tərpənməli” hissə kimi nəzərdə tutulmamışdı. İndi geriyə baxanda gülməlidir ki, heç vaxt özümə vaultBTC-nin ümumiyyətlə hərəkətə ehtiyacı olub-olmadığını soruşmamışam. Yeni bir token gördüm və dərhal onu göndərə biləcəyim növbəti yeri axtarmağa başladım. Məhsulda heç nə bu addımın növbəti addım olacağını göstərmirdi. Sadəcə bunun elə olacağını düşündüm. Bu anlayış, borclanma prosesinin özündən daha uzun müddət məndə qaldı. Mən həqiqətən vaultBTC-nin necə işlədiyini öyrənmirdim. Mən DeFi vərdişlərimin illərlə getdiyim bir fərziyyəni tamamilə fərqli bir yanaşmaya uyğunlaşdırıb nə qədər tez “proyeksiya etdiyimi” müşahidə edirdim. Düşünməyə vadar edir: kriptoda “intuitiv” saydığımız nə qədər şey, əslində, sadəcə kifayət qədər uzun müddət təkrarladığımız vərdişlərdir. $LAB @babylonlabs_io $BABY #baby
Bugün bir müddət Babylon-un “Trustless Bitcoin Vault” testnetində vaxt keçirdim, borclanma prosesinin məhz yadda saxlayacağım hissə olacağını yarı ümid edirdim.
Elə olmadı.
0.10 testnet BTC mint etdim, 0.08 BTC-ni bir vault-a kilidlədim, Aave vasitəsilə 0.05 BTC borc aldım və bütün proses gözlədiyim kimi, demək olar ki, işləyirdi. Hətta 2.31 health factor-a da baxdım, təsdiq pəncərəsini bağladım və tamamlandığını düşündüm.
Məndə qalan isə borclanma deyildi. O, vaultBTC-ni sonradan görmək və mən nə axtardığımı tam bilmədən belə ona instinktiv olaraq klik etməyim idi.
Heç kim mənə “Send” düyməsinə klik etməyimi deməmişdi. Mən sadəcə növbəti addımın elə bu olacağını zənn etdim.
Hansısa bir şeyi qaçırdığımı düşünərək bir az ətrafa baxdım, sonra sənədləri açdım. Sənədlər heç nəyi səhv başa düşmədiyimi təsdiqlədi. vaultBTC heç vaxt “yerindən tərpənməli” hissə kimi nəzərdə tutulmamışdı.
İndi geriyə baxanda gülməlidir ki, heç vaxt özümə vaultBTC-nin ümumiyyətlə hərəkətə ehtiyacı olub-olmadığını soruşmamışam. Yeni bir token gördüm və dərhal onu göndərə biləcəyim növbəti yeri axtarmağa başladım. Məhsulda heç nə bu addımın növbəti addım olacağını göstərmirdi. Sadəcə bunun elə olacağını düşündüm.
Bu anlayış, borclanma prosesinin özündən daha uzun müddət məndə qaldı. Mən həqiqətən vaultBTC-nin necə işlədiyini öyrənmirdim. Mən DeFi vərdişlərimin illərlə getdiyim bir fərziyyəni tamamilə fərqli bir yanaşmaya uyğunlaşdırıb nə qədər tez “proyeksiya etdiyimi” müşahidə edirdim.
Düşünməyə vadar edir: kriptoda “intuitiv” saydığımız nə qədər şey, əslində, sadəcə kifayət qədər uzun müddət təkrarladığımız vərdişlərdir.
$LAB @BabylonLabs_io $BABY #baby
Tərcüməyə bax
I reopened Babylon's Trustless Bitcoin Vaults (TBV) testnet today because I couldn't remember where my BTC was supposed to stop being... BTC. Sounds like a strange thing to forget, but the funny part was that I couldn't find that moment the second time either. I even clicked back because I thought I'd skipped a confirmation screen, then ran through the flow again a little more slowly. I never found it. I went back to the docs and opened the testnet again. After a while, I wasn't even sure what I thought I'd missed anymore. I just kept feeling that there had to be another step somewhere, even though I couldn't really explain what I expected to see. I'm still going back through the documentation, so there's every chance I'm looking at this the wrong way. Still, that was the part that stayed with me after I closed the tab. I kept waiting for something that never showed up, and maybe I've just gotten used to looking for that step whenever I try a new Bitcoin borrowing product. No strong conclusion yet. The borrowing itself wasn't what stayed with me. It was realizing how naturally I'd assumed Bitcoin had to become something else before it could do anything useful. Maybe I'd been carrying that assumption around for longer than I realized. Could just be me. Curious if anyone else who tried the TBV testnet walked away thinking about a completely different part of the experience than they expected. I'd love to compare notes. $LAB $BABY @babylonlabs_io #baby
I reopened Babylon's Trustless Bitcoin Vaults (TBV) testnet today because I couldn't remember where my BTC was supposed to stop being... BTC.
Sounds like a strange thing to forget, but the funny part was that I couldn't find that moment the second time either. I even clicked back because I thought I'd skipped a confirmation screen, then ran through the flow again a little more slowly.
I never found it.
I went back to the docs and opened the testnet again. After a while, I wasn't even sure what I thought I'd missed anymore. I just kept feeling that there had to be another step somewhere, even though I couldn't really explain what I expected to see.
I'm still going back through the documentation, so there's every chance I'm looking at this the wrong way.
Still, that was the part that stayed with me after I closed the tab. I kept waiting for something that never showed up, and maybe I've just gotten used to looking for that step whenever I try a new Bitcoin borrowing product.
No strong conclusion yet.
The borrowing itself wasn't what stayed with me.
It was realizing how naturally I'd assumed Bitcoin had to become something else before it could do anything useful.
Maybe I'd been carrying that assumption around for longer than I realized.
Could just be me.
Curious if anyone else who tried the TBV testnet walked away thinking about a completely different part of the experience than they expected. I'd love to compare notes.

$LAB $BABY @BabylonLabs_io #baby
Doğrulanıb
Tərcüməyə bax
The more I read about Bitcoin bridges, the less convinced I am that speed and fees are the most meaningful comparison. Those metrics matter, but only after Bitcoin has already been represented somewhere outside its native chain. The more I looked at Babylon's Trustless Bitcoin Vaults (TBV), the more it seemed that the earlier design choice is the one that deserves more attention. Most bridge-based systems begin by creating another representation of Bitcoin before it can be used as collateral. Once that representation becomes the foundation of the borrowing process, improving liquidity is largely about making that new asset more efficient to use. TBV takes a different path. Native BTC remains in self-custody while liquidity is sourced through Aave, so borrowing does not begin with wrapped Bitcoin becoming the collateral. It begins with proving that the original BTC can securely support borrowing without leaving Bitcoin. That also shifts where the system carries its assumptions. The collateral is no longer another representation of Bitcoin, so the verification layer becomes the part that has to consistently prove the model works. The dependency has not disappeared. It has simply moved. For me, that changes the comparison entirely. The more interesting question is no longer which design expands Bitcoin liquidity more efficiently. It is which design asks users to accept fewer new trust assumptions before their Bitcoin becomes productive. @babylonlabs_io $LAB $BABY #baby Which matters more for Bitcoin lending?
The more I read about Bitcoin bridges, the less convinced I am that speed and fees are the most meaningful comparison. Those metrics matter, but only after Bitcoin has already been represented somewhere outside its native chain. The more I looked at Babylon's Trustless Bitcoin Vaults (TBV), the more it seemed that the earlier design choice is the one that deserves more attention.
Most bridge-based systems begin by creating another representation of Bitcoin before it can be used as collateral. Once that representation becomes the foundation of the borrowing process, improving liquidity is largely about making that new asset more efficient to use.
TBV takes a different path. Native BTC remains in self-custody while liquidity is sourced through Aave, so borrowing does not begin with wrapped Bitcoin becoming the collateral. It begins with proving that the original BTC can securely support borrowing without leaving Bitcoin.
That also shifts where the system carries its assumptions. The collateral is no longer another representation of Bitcoin, so the verification layer becomes the part that has to consistently prove the model works. The dependency has not disappeared. It has simply moved.
For me, that changes the comparison entirely. The more interesting question is no longer which design expands Bitcoin liquidity more efficiently. It is which design asks users to accept fewer new trust assumptions before their Bitcoin becomes productive.
@BabylonLabs_io $LAB $BABY #baby
Which matters more for Bitcoin lending?
Faster bridges
0%
Native BTC stays on Bitcoin
100%
Better capital efficiency
0%
Fewer trust assumptions
0%
1 Səslər • Səsvermə bağlanıb
Bu gün yenidən Babylon-un TBV testnetinə qayıtdım. Heç bir problem ona görə yaranmadı. Sadəcə ilk dəfə nəyisə qaçırdığımı hissindən qurtara bilmədim. Ona görə axını yenidən yoxladım. Qəribə tərəfi odur ki, nəyi qaçırdığımı dəqiq anlaya bilmədim. Hətta bir dəfə də geriyə klik etdim, çünki başqa bir addımın haradasa gizləndiyinə əmin idim. Yox idi. Mənə bir az vaxt apardı ki, heç başqa bir ekran axtarmadığımı anlayım. Bəlkə də illərdir müəyyən Bitcoin DeFi axınlarına öyrəşmişəm. BTC-dən başlayırsan, sonra hansısa mərhələdə forma dəyişir, başqa yerə köçür, ya da maraqlı bir şey baş verməzdən əvvəl bir addım daha olur. Bir müddət sonra, bunun gözlədiyin şey olduğunu sezməyi dayandırırsan. Bu dəfə isə sadəcə... heç gəlməyən bir addımı gözləməyi davam etdim. Hələ də sənədləri oxuyuram, ona görə memarlığı tapdığımı zənn edib belə danışmaq istəmirəm. Hələlik güclü bir nəticə yoxdur. Sadəcə elə hiss olunur ki, testnetə bir axın gözləntisi ilə daxil oldum və çıxanda düşündüm: niyə ümumiyyətlə onu gözləyirdim? Sadəcə mənim halımdır. Əgər siz də TBV testnetini yoxlamısınızsa, qeydləri müqayisə etmək istərdim. Tabı bağladıqdan sonra beynində qalan kiçik bir hissənin olub-olmadığını düşünürəm. @babylonlabs_io $LAB $BABY #baby
Bu gün yenidən Babylon-un TBV testnetinə qayıtdım.
Heç bir problem ona görə yaranmadı.
Sadəcə ilk dəfə nəyisə qaçırdığımı hissindən qurtara bilmədim.
Ona görə axını yenidən yoxladım.
Qəribə tərəfi odur ki, nəyi qaçırdığımı dəqiq anlaya bilmədim. Hətta bir dəfə də geriyə klik etdim, çünki başqa bir addımın haradasa gizləndiyinə əmin idim.
Yox idi.
Mənə bir az vaxt apardı ki, heç başqa bir ekran axtarmadığımı anlayım.
Bəlkə də illərdir müəyyən Bitcoin DeFi axınlarına öyrəşmişəm. BTC-dən başlayırsan, sonra hansısa mərhələdə forma dəyişir, başqa yerə köçür, ya da maraqlı bir şey baş verməzdən əvvəl bir addım daha olur. Bir müddət sonra, bunun gözlədiyin şey olduğunu sezməyi dayandırırsan.
Bu dəfə isə sadəcə... heç gəlməyən bir addımı gözləməyi davam etdim.
Hələ də sənədləri oxuyuram, ona görə memarlığı tapdığımı zənn edib belə danışmaq istəmirəm.
Hələlik güclü bir nəticə yoxdur.
Sadəcə elə hiss olunur ki, testnetə bir axın gözləntisi ilə daxil oldum və çıxanda düşündüm: niyə ümumiyyətlə onu gözləyirdim?
Sadəcə mənim halımdır.
Əgər siz də TBV testnetini yoxlamısınızsa, qeydləri müqayisə etmək istərdim. Tabı bağladıqdan sonra beynində qalan kiçik bir hissənin olub-olmadığını düşünürəm.
@BabylonLabs_io $LAB $BABY #baby
Tərcüməyə bax
One sentence in Babylon's Trustless Bitcoin Vaults documentation kept bothering me. It never explains how Bitcoin can understand Ethereum. It explains why Bitcoin never needs to. That sounded like a limitation until I noticed the same idea appearing throughout the architecture. TBV isn't trying to give Bitcoin more context about another blockchain. It's deliberately removing context before anything reaches Bitcoin, preserving the assumption that Bitcoin should only judge what it already knows how to judge. Once I looked at the design through that lens, several pieces suddenly clicked together. Ethereum continues running the lending application because that's where the application belongs. Aave still relies on a restricted vaultBTC representation because its own contracts need collateral they can process. None of those decisions are pushed back to Bitcoin. By the time information returns to the Bitcoin side, the application has already disappeared, leaving only a cryptographic claim that Bitcoin can verify under the vault's predefined rules. That sequence feels more important than the borrowing flow itself. The architecture isn't asking Bitcoin to trust Ethereum. It isn't asking Bitcoin to understand Ethereum, either. It's asking Bitcoin to verify a proof while everything else stays on the chain that produced it. I started reading TBV expecting another approach to bringing Bitcoin into DeFi. Instead, I found a protocol that treats not adding new responsibilities to Bitcoin as the starting point rather than the compromise. Looking back, that single design choice explains almost every other decision in the architecture, from how collateral is represented on Ethereum to how native BTC remains governed on Bitcoin. @babylonlabs_io $BANK $BABY #baby
One sentence in Babylon's Trustless Bitcoin Vaults documentation kept bothering me.
It never explains how Bitcoin can understand Ethereum.
It explains why Bitcoin never needs to.
That sounded like a limitation until I noticed the same idea appearing throughout the architecture. TBV isn't trying to give Bitcoin more context about another blockchain. It's deliberately removing context before anything reaches Bitcoin, preserving the assumption that Bitcoin should only judge what it already knows how to judge.
Once I looked at the design through that lens, several pieces suddenly clicked together.
Ethereum continues running the lending application because that's where the application belongs. Aave still relies on a restricted vaultBTC representation because its own contracts need collateral they can process. None of those decisions are pushed back to Bitcoin. By the time information returns to the Bitcoin side, the application has already disappeared, leaving only a cryptographic claim that Bitcoin can verify under the vault's predefined rules.
That sequence feels more important than the borrowing flow itself.
The architecture isn't asking Bitcoin to trust Ethereum.
It isn't asking Bitcoin to understand Ethereum, either.
It's asking Bitcoin to verify a proof while everything else stays on the chain that produced it.
I started reading TBV expecting another approach to bringing Bitcoin into DeFi.
Instead, I found a protocol that treats not adding new responsibilities to Bitcoin as the starting point rather than the compromise. Looking back, that single design choice explains almost every other decision in the architecture, from how collateral is represented on Ethereum to how native BTC remains governed on Bitcoin.
@BabylonLabs_io $BANK $BABY #baby
Bu gün Babil’in testnet’ində bir kiçik hissəyə dayanmadan baxdım. Başlıq deyil. Borclanma məbləği də deyil. Sadəcə gözlədiyim hissə idi: orada BTC-nin bir anlıq “native BTC” olmadan çıxmasını gözləyirdim. Amma o an heç cür görünmədi. Bəlkə çox sadə səslənir, amma mənə fərqli gələn ilk şey bu oldu. Uzun müddətdir ki, Bitcoin DeFi sanki bir çevirmə mərhələsindən başlayır kimi hiss olunub. Sarın. Körpüləyin. Əl-ələ verin. Əvvəl ona nəsə edin, sonra isə başqa yerdə işləsin. Bu dəfə isə həmin mərhələ üçün gözlədim və elə mərkəzdə dayanan bir versiyasını tapa bilmədim. Bəlkə də testnet axınını çox şeyə yozuram. Çox güman eləyəm. Mən sadəcə sənədlərə və məhsul təcrübəsinə yenidən baxırdım, ona görə də hələ tam əlaqələndirmədiyim hissələr var. Amma yenə də işini bitirəndən sonra düşündüyümü dayandıra bilmədiyim hissə məhz bu oldu. Borclanmanın özündən danışmıram. Sadəcə borclanma axınının, Bitcoin-i hərəkət etdirməkdən daha çox, native BTC-nin native olaraq qalmasını, girov dəyərinin isə başqa yerdə istifadə edilə bilən hala gəlməsinə imkan verməsini önə çıxardığı hiss. Bu kiçik bir dəyişiklikdir, amma bütün sistemin necə hiss olunduğunu dəyişir. Böyük bir nəticəyə gəldiyimi düşünmürəm. Daha çox, daha sakit bir nəticə kimi. Bəlkə maraqlı sual Bitcoin-in DeFi-yə necə girdiyi deyil. Bəlkə də məsələ, birinci yerdə onun Bitcoin-dən çıxmalı olduğunu niyə güman etdiyimizdir. TBV-i sınayan başqa kiminsə eyni fikrə ilişib qalıb-qalmadığını maraqlandırıram. @babylonlabs_io $BABY #baby
Bu gün Babil’in testnet’ində bir kiçik hissəyə dayanmadan baxdım.
Başlıq deyil. Borclanma məbləği də deyil. Sadəcə gözlədiyim hissə idi: orada BTC-nin bir anlıq “native BTC” olmadan çıxmasını gözləyirdim.
Amma o an heç cür görünmədi.
Bəlkə çox sadə səslənir, amma mənə fərqli gələn ilk şey bu oldu.
Uzun müddətdir ki, Bitcoin DeFi sanki bir çevirmə mərhələsindən başlayır kimi hiss olunub. Sarın. Körpüləyin. Əl-ələ verin. Əvvəl ona nəsə edin, sonra isə başqa yerdə işləsin.
Bu dəfə isə həmin mərhələ üçün gözlədim və elə mərkəzdə dayanan bir versiyasını tapa bilmədim.
Bəlkə də testnet axınını çox şeyə yozuram. Çox güman eləyəm. Mən sadəcə sənədlərə və məhsul təcrübəsinə yenidən baxırdım, ona görə də hələ tam əlaqələndirmədiyim hissələr var.
Amma yenə də işini bitirəndən sonra düşündüyümü dayandıra bilmədiyim hissə məhz bu oldu.
Borclanmanın özündən danışmıram.
Sadəcə borclanma axınının, Bitcoin-i hərəkət etdirməkdən daha çox, native BTC-nin native olaraq qalmasını, girov dəyərinin isə başqa yerdə istifadə edilə bilən hala gəlməsinə imkan verməsini önə çıxardığı hiss.
Bu kiçik bir dəyişiklikdir, amma bütün sistemin necə hiss olunduğunu dəyişir.
Böyük bir nəticəyə gəldiyimi düşünmürəm. Daha çox, daha sakit bir nəticə kimi.
Bəlkə maraqlı sual Bitcoin-in DeFi-yə necə girdiyi deyil.
Bəlkə də məsələ, birinci yerdə onun Bitcoin-dən çıxmalı olduğunu niyə güman etdiyimizdir.
TBV-i sınayan başqa kiminsə eyni fikrə ilişib qalıb-qalmadığını maraqlandırıram.
@BabylonLabs_io $BABY #baby
Qismən doğrudur
Tərcüməyə bax
I used to think wrapping Bitcoin was simply the price of using it in DeFi. Every product I had tried followed roughly the same pattern. You moved your BTC first, and only then could you borrow, trade, or access liquidity. After seeing that flow enough times, I stopped asking whether it actually had to exist. That assumption stayed with me until I tried Babylon's Trustless Bitcoin Vaults (TBV) testnet. Halfway through the borrowing flow, I found myself waiting for the moment when my Bitcoin would become something else. I even restarted the process because I assumed I had missed a step. The second attempt looked exactly the same. That was when I realized the missing step was not missing at all. There was never supposed to be another version of my Bitcoin. That moment changed the way I looked at the product. The interesting part is not that TBV makes borrowing with native Bitcoin possible. The interesting part is the question it starts with. Instead of asking how Bitcoin can be moved into DeFi, it asks how DeFi can recognize the collateral value of native Bitcoin while the asset itself never leaves the Bitcoin network. At first, that sounds like a small architectural difference. The more I thought about it, the more it felt like a completely different way of approaching the problem. It shifts the focus away from transporting assets and toward proving collateral. It also makes you question whether wrapping Bitcoin was ever the destination, or simply the compromise the industry accepted because no better alternative existed. I finished the testnet with a different takeaway than I expected. Maybe Bitcoin DeFi does not need more efficient ways to move Bitcoin. Maybe it needs fewer reasons to move Bitcoin in the first place. $LAB @babylonlabs_io $BABY #baby
I used to think wrapping Bitcoin was simply the price of using it in DeFi. Every product I had tried followed roughly the same pattern. You moved your BTC first, and only then could you borrow, trade, or access liquidity. After seeing that flow enough times, I stopped asking whether it actually had to exist.
That assumption stayed with me until I tried Babylon's Trustless Bitcoin Vaults (TBV) testnet.
Halfway through the borrowing flow, I found myself waiting for the moment when my Bitcoin would become something else. I even restarted the process because I assumed I had missed a step. The second attempt looked exactly the same. That was when I realized the missing step was not missing at all. There was never supposed to be another version of my Bitcoin.
That moment changed the way I looked at the product.
The interesting part is not that TBV makes borrowing with native Bitcoin possible. The interesting part is the question it starts with. Instead of asking how Bitcoin can be moved into DeFi, it asks how DeFi can recognize the collateral value of native Bitcoin while the asset itself never leaves the Bitcoin network.
At first, that sounds like a small architectural difference. The more I thought about it, the more it felt like a completely different way of approaching the problem. It shifts the focus away from transporting assets and toward proving collateral. It also makes you question whether wrapping Bitcoin was ever the destination, or simply the compromise the industry accepted because no better alternative existed.
I finished the testnet with a different takeaway than I expected. Maybe Bitcoin DeFi does not need more efficient ways to move Bitcoin. Maybe it needs fewer reasons to move Bitcoin in the first place.
$LAB @BabylonLabs_io $BABY #baby
Doğrulanıb
Bu səhər Equity-də @grvt_io ’s Earn səhifəsini iki dəfə oxudum, çünki 3.5% APY kapitalla qazanılan gəlirin həm də margin kimi istifadə oluna bilməyəcəyini və Season 2 üçün TVL-ə sayılmayacağını düşünmüşdüm. Hətta səhvən iki fərqli balansı qarışdırıb-qarışdırmadığımı yoxlamaq üçün yenidən Season 2 səhifəsinə də qayıtdım. Qarışdırmamışdım. Dörd həftəlik dövr ərzində beş ticarəti tamamla, eyni Trading Account Equity isə gəliri aça, açıq mövqeləri dəstəkləyə və Season 2 mükafatları üçün istifadə olunan TVL snapshot-larında görünə bilər. TVL həftəlik pointlərin 5%-ni alır. Ticarət həcmi 50%-ni, açıq maraq isə əlavə 15%-ni alır; Season 2 isə GRVT-nin sabit bir-bilyon token tədarükünün 18%-ni təmsil edir. Bir balans üç işi görür. Amma onun TVL-i yalnız bir rəqəm bildirir. Mən dönüb durduğum hissə elə bu oldu. Kapital Grvt-də qalanda, 3.5% gəlir üçün oradadır? Yoxsa treyderi başqa bir mövqe üçün margin hazır vəziyyətdə saxlayır? Yoxsa balans gələcəkdə token paylanmasını yaxşılaşdıra biləcək başqa bir snapshot-u gözləyir? Buna dair hər dəfə bir-birinə əks gedərək düşündüm. Üç izahın heç biri balansı daha az real etmədi. Eyni kapital həm real gəlir yarada, həm də real ticarətləri dəstəkləyə bilər, halbuki mükafatlar onu orada saxlamaq qərarına təsir etməyə davam edir. Eyni işə salınma pəncərəsində Binance Wallet missiyaları vasitəsilə əlavə 1.5 milyon $GRVT daxil olduqda, iyulun 21-i daha təmiz testə çevrilir. TGE-dən sonra həm gəlir, həm də margin yararlılığı qalır, Season 2 gözləntisi isə getdikcə daha az önəmli olur. Sonra isə görəcəyik: Grvt-nin balansının nə qədər hissəsi gəlir gətirib—və nə qədər hissəsi sadəcə gözləyib. #grvt $LAB
Bu səhər Equity-də @grvt_io ’s Earn səhifəsini iki dəfə oxudum, çünki 3.5% APY kapitalla qazanılan gəlirin həm də margin kimi istifadə oluna bilməyəcəyini və Season 2 üçün TVL-ə sayılmayacağını düşünmüşdüm.
Hətta səhvən iki fərqli balansı qarışdırıb-qarışdırmadığımı yoxlamaq üçün yenidən Season 2 səhifəsinə də qayıtdım.
Qarışdırmamışdım.
Dörd həftəlik dövr ərzində beş ticarəti tamamla, eyni Trading Account Equity isə gəliri aça, açıq mövqeləri dəstəkləyə və Season 2 mükafatları üçün istifadə olunan TVL snapshot-larında görünə bilər.
TVL həftəlik pointlərin 5%-ni alır. Ticarət həcmi 50%-ni, açıq maraq isə əlavə 15%-ni alır; Season 2 isə GRVT-nin sabit bir-bilyon token tədarükünün 18%-ni təmsil edir.
Bir balans üç işi görür.
Amma onun TVL-i yalnız bir rəqəm bildirir.
Mən dönüb durduğum hissə elə bu oldu.
Kapital Grvt-də qalanda, 3.5% gəlir üçün oradadır?
Yoxsa treyderi başqa bir mövqe üçün margin hazır vəziyyətdə saxlayır?
Yoxsa balans gələcəkdə token paylanmasını yaxşılaşdıra biləcək başqa bir snapshot-u gözləyir?
Buna dair hər dəfə bir-birinə əks gedərək düşündüm. Üç izahın heç biri balansı daha az real etmədi.
Eyni kapital həm real gəlir yarada, həm də real ticarətləri dəstəkləyə bilər, halbuki mükafatlar onu orada saxlamaq qərarına təsir etməyə davam edir.
Eyni işə salınma pəncərəsində Binance Wallet missiyaları vasitəsilə əlavə 1.5 milyon $GRVT daxil olduqda, iyulun 21-i daha təmiz testə çevrilir.
TGE-dən sonra həm gəlir, həm də margin yararlılığı qalır, Season 2 gözləntisi isə getdikcə daha az önəmli olur.
Sonra isə görəcəyik: Grvt-nin balansının nə qədər hissəsi gəlir gətirib—və nə qədər hissəsi sadəcə gözləyib.
#grvt $LAB
Bir gün köhnə qara siyahı (blacklist) faylına baxırdım ki, narahat edən bir düşüncə gəldi: qayda olduğu kimi qala bilər, amma həmin qaydanın arxasındakı dünya bir gecədə dəyişə bilər. Dün siyahıda olmayan bir ad bu gün orada ola bilər. Siyasət məntiqi tərpənmir, amma onun oxuduğu reallıq artıq sürüşüb. Newton Protocol-un “Privacy Flows” sənədində məni ən çox diqqətə gətirən də elə bu oldu: ən yeni versiya. İlk baxışda versiyalaşdırma adi məlumat idarəçiliyi kimi görünürdü. Bir provayder sanksiya siyahısı, qara siyahı, risk cədvəli və ya uyğunluq (compliance) dataset-i dərc edir; publishData çağırıldığı hər dəfə yeni bir versiya yaradılır və operatorlar verilmiş bir klientə lazım olduqda ən son gizli məlumatı həll edirlər. Bu, məntiqli səslənir. Uyğunluq məlumatı zamana “donmamalıdır”. Əgər qara siyahı dəyişirsə, siyasət yeniliyi görməlidir; əgər risk cədvəli dəyişirsə, səlahiyyət vermə axını dünənki dünyanın mənzərəsini tətbiq etmək əvəzinə yeni reallığa reaksiya verməlidir. Amma nə qədər düşündüm, “ən yeni” sözünün təzəlikdən daha çox güc kimi hiss olunduğunu anladım. @NewtonProtocol -də verilmiş klientlər özlərini heç bir konkret explicit versiyaya “kilidləmirlər”. Onlar ən son məlumatı oxuyurlar; yəni eyni PolicyClient, eyni Rego məntiqi və eyni istifadəçi sabah fərqli qərar verə bilər, çünki siyasətin altındakı gizli dataset bu gün dəyişib. Bir istifadəçi cüzdanı dəyişdiyi üçün deyil, siyasətin arxasındakı dataset dəyişdiyi üçün rədd edilə bilər. Sərhəd budur. Provayder təkcə məlumat təqdim etmir. Provayder icra (enforcement) sərhədinin bir hissəsinə çevrilir, çünki onun ən yeni versiyası siyasətin nəyi gördüyünü müəyyənləşdirməyə kömək edir. Ən yeni-versiyaya giriş siyasəti real dünyaya yaxın saxlayır, amma eyni zamanda ən yeni datasetin istifadəçilər tam nəyi dəyişdiyini anlamadan əvvəl icranı yenidən formalaşdırmaq gücü verir. Bəlkə də ən yeni məlumat avtomatik olaraq ən təhlükəsiz məlumat deyil. Bəlkə də sadəcə qərarı müəyyənləşdirmək üçün hazırda icazə verilən məlumatdır. $LAB $NEWT #Newt
Bir gün köhnə qara siyahı (blacklist) faylına baxırdım ki, narahat edən bir düşüncə gəldi: qayda olduğu kimi qala bilər, amma həmin qaydanın arxasındakı dünya bir gecədə dəyişə bilər.
Dün siyahıda olmayan bir ad bu gün orada ola bilər. Siyasət məntiqi tərpənmir, amma onun oxuduğu reallıq artıq sürüşüb.
Newton Protocol-un “Privacy Flows” sənədində məni ən çox diqqətə gətirən də elə bu oldu:
ən yeni versiya.
İlk baxışda versiyalaşdırma adi məlumat idarəçiliyi kimi görünürdü. Bir provayder sanksiya siyahısı, qara siyahı, risk cədvəli və ya uyğunluq (compliance) dataset-i dərc edir; publishData çağırıldığı hər dəfə yeni bir versiya yaradılır və operatorlar verilmiş bir klientə lazım olduqda ən son gizli məlumatı həll edirlər.
Bu, məntiqli səslənir.
Uyğunluq məlumatı zamana “donmamalıdır”. Əgər qara siyahı dəyişirsə, siyasət yeniliyi görməlidir; əgər risk cədvəli dəyişirsə, səlahiyyət vermə axını dünənki dünyanın mənzərəsini tətbiq etmək əvəzinə yeni reallığa reaksiya verməlidir.
Amma nə qədər düşündüm, “ən yeni” sözünün təzəlikdən daha çox güc kimi hiss olunduğunu anladım.
@NewtonProtocol -də verilmiş klientlər özlərini heç bir konkret explicit versiyaya “kilidləmirlər”. Onlar ən son məlumatı oxuyurlar; yəni eyni PolicyClient, eyni Rego məntiqi və eyni istifadəçi sabah fərqli qərar verə bilər, çünki siyasətin altındakı gizli dataset bu gün dəyişib.
Bir istifadəçi cüzdanı dəyişdiyi üçün deyil, siyasətin arxasındakı dataset dəyişdiyi üçün rədd edilə bilər.
Sərhəd budur.
Provayder təkcə məlumat təqdim etmir. Provayder icra (enforcement) sərhədinin bir hissəsinə çevrilir, çünki onun ən yeni versiyası siyasətin nəyi gördüyünü müəyyənləşdirməyə kömək edir.
Ən yeni-versiyaya giriş siyasəti real dünyaya yaxın saxlayır, amma eyni zamanda ən yeni datasetin istifadəçilər tam nəyi dəyişdiyini anlamadan əvvəl icranı yenidən formalaşdırmaq gücü verir.
Bəlkə də ən yeni məlumat avtomatik olaraq ən təhlükəsiz məlumat deyil.
Bəlkə də sadəcə qərarı müəyyənləşdirmək üçün hazırda icazə verilən məlumatdır.
$LAB $NEWT #Newt
Qismən doğrudur
Məqalə
Đúng luật cũng vô nghĩa nếu cầm nhầm bằng chứngKết quả tuần trước, tôi cứ mắc ở một câu hỏi nhỏ về proof trong crypto. Trước khi hỏi proof có verify được không, làm sao biết đó vẫn là đúng proof ban đầu? Vài ngày sau, đọc phần zkTLS Twitter/X Example trong tài liệu của Newton Protocol, tôi dừng lại ở chi tiết proofCid. Ban đầu, tôi nghĩ CID chỉ là một địa chỉ lưu proof. Một zkTLS proof được tạo ra. Client lưu proof đó. Gateway trả về proofCid. Sau đó task dùng CID này để operators biết phải lấy proof nào khi chạy policy evaluation.

Đúng luật cũng vô nghĩa nếu cầm nhầm bằng chứng

Kết quả tuần trước, tôi cứ mắc ở một câu hỏi nhỏ về proof trong crypto.
Trước khi hỏi proof có verify được không, làm sao biết đó vẫn là đúng proof ban đầu?
Vài ngày sau, đọc phần zkTLS Twitter/X Example trong tài liệu của Newton Protocol, tôi dừng lại ở chi tiết proofCid.
Ban đầu, tôi nghĩ CID chỉ là một địa chỉ lưu proof.
Một zkTLS proof được tạo ra. Client lưu proof đó. Gateway trả về proofCid. Sau đó task dùng CID này để operators biết phải lấy proof nào khi chạy policy evaluation.
Bu gün səhər bir tabda @grvt_io -in artım göstəricilərini, başqa bir tabda isə 2-ci Mövsümün mexaniklərini açmışdım ki, eyni metriklər birdən-birə oxunması daha çətin oldu. 2-ci Mövsüm indi GRVT-nin sabit bir milyard tokenlik təchizatının 18%-ni təşkil edir. Onun xallarının 50%-i ticarət həcmi hesabına gəlir, 15%-i açıq faizdən (open interest), qalanını isə TVL, likvidlik, likvidasiya və referral fəaliyyəti formalaşdırır. İnsanlar Grvt-in 21 iyul TGE-sindən əvvəl real dartınma (traction) qurduğunu deyərkən də bu rəqəmlərə əsaslanırlar. Həmin aktivlik doğrudur. Sifarişlər icra olunub, marja (margin) yerləşdirilib, mövqelər açıq qalıb və platformaya kapital daxil olub. Amma bu aktivliyi yaradan stimul da realdır. Kampaniya həcmə görə mükafat verirsə, artan həcm eyni zamanda həm real məhsul istifadəsini, həm də token-motivli davranışı göstərə bilər. Açıq faiz və TVL üçün də eyni şey keçərlidir. Mən iki tab arasında davamlı keçid edirdim, çünki asan nəticələrdən heç biri doğru hiss edilmirdi. Artırımı süni adlandırmaq Season 2-nin yaratdığı real likvidliyi və ticarət aktivliyini gözdən qaçırır. Onu sübut olunmuş məhsul-market uyğunluğu (product-market fit) kimi qiymətləndirmək isə həmin eyni addımlara bağlı gələcək token bölgüsünü nəzərə almır. 2-ci Mövsüm stimulların kapitalı hərəkətə gətirə bildiyini göstərə bilər. Amma hələ ki, məhsulun bunu davamlı saxlaya bildiyini sübut edə bilmir. Ona görə də 21 iyul tokenin buraxılışından (launch) daha çox şey deməkdir. Nöqtələr maye tokenlərə çevrildikdən sonra, fəaliyyət ayları boyunca formalaşmış ortaq gözlənti zəifləməyə başlayır. Bəzi istifadəçilər qalacaq—icra (execution), gəlir (yield) və ya bazara çıxış faydalı olduğu üçün. Digərləri isə dərk edəcək ki, gəldikləri əsas məhsul mükafat idi. İnstentivlər (stimullar) sədaqəti göstərmədən öncə davranışı üzə çıxara bilər. TGE-dən sonra, növbəti ticarəti artıq airdrop bölgüsünü yaxşılaşdırmadıqda neçə istifadəçi yenə də Grvt-i seçəcək? #grvt
Bu gün səhər bir tabda @grvt_io -in artım göstəricilərini, başqa bir tabda isə 2-ci Mövsümün mexaniklərini açmışdım ki, eyni metriklər birdən-birə oxunması daha çətin oldu.
2-ci Mövsüm indi GRVT-nin sabit bir milyard tokenlik təchizatının 18%-ni təşkil edir. Onun xallarının 50%-i ticarət həcmi hesabına gəlir, 15%-i açıq faizdən (open interest), qalanını isə TVL, likvidlik, likvidasiya və referral fəaliyyəti formalaşdırır.
İnsanlar Grvt-in 21 iyul TGE-sindən əvvəl real dartınma (traction) qurduğunu deyərkən də bu rəqəmlərə əsaslanırlar.
Həmin aktivlik doğrudur. Sifarişlər icra olunub, marja (margin) yerləşdirilib, mövqelər açıq qalıb və platformaya kapital daxil olub.
Amma bu aktivliyi yaradan stimul da realdır.
Kampaniya həcmə görə mükafat verirsə, artan həcm eyni zamanda həm real məhsul istifadəsini, həm də token-motivli davranışı göstərə bilər. Açıq faiz və TVL üçün də eyni şey keçərlidir.
Mən iki tab arasında davamlı keçid edirdim, çünki asan nəticələrdən heç biri doğru hiss edilmirdi.
Artırımı süni adlandırmaq Season 2-nin yaratdığı real likvidliyi və ticarət aktivliyini gözdən qaçırır.
Onu sübut olunmuş məhsul-market uyğunluğu (product-market fit) kimi qiymətləndirmək isə həmin eyni addımlara bağlı gələcək token bölgüsünü nəzərə almır.
2-ci Mövsüm stimulların kapitalı hərəkətə gətirə bildiyini göstərə bilər.
Amma hələ ki, məhsulun bunu davamlı saxlaya bildiyini sübut edə bilmir.
Ona görə də 21 iyul tokenin buraxılışından (launch) daha çox şey deməkdir. Nöqtələr maye tokenlərə çevrildikdən sonra, fəaliyyət ayları boyunca formalaşmış ortaq gözlənti zəifləməyə başlayır.
Bəzi istifadəçilər qalacaq—icra (execution), gəlir (yield) və ya bazara çıxış faydalı olduğu üçün. Digərləri isə dərk edəcək ki, gəldikləri əsas məhsul mükafat idi.
İnstentivlər (stimullar) sədaqəti göstərmədən öncə davranışı üzə çıxara bilər.
TGE-dən sonra, növbəti ticarəti artıq airdrop bölgüsünü yaxşılaşdırmadıqda neçə istifadəçi yenə də Grvt-i seçəcək?
#grvt
Eyni ünvan həmişə eyni qayda demək deyil. Bu, məni dayandıran Nyutonun “smart contract” sənədlərindəki detal idi. setPolicyAddress(newPolicy) İlk baxışdan bu, səliqəli bir yeniləmə funksiyası kimi görünürdü. Protokol yeni policy kontraktı yerləşdirir, mövcud PolicyClient-i ona yönəldir və eyni client ünvanını saxlayır. Kifayət qədər sadədir. Amma həmin eyni ünvan önəmlidir. @NewtonProtocol -da PolicyClient sadəcə texniki göstərici deyil. Bu, istifadəçilərin qarşılıqlı əlaqədə olduğu obyektdir. Kimlik əlaqələrinin bağlana biləcəyi yerdir, razılığın yığıldığı yerdir və bir tətbiqin etibar qurmağa başladığı yerdir. Ona görə də Nyuton asanlıqla qarışdırıla bilən iki şeyi ayırır. PolicyClient identiklik üçün “anchor”dur. Policy isə onun arxasındakı qayda məntiqidir. Bu faydalıdır. Bu ayrım olmasaydı, hər bir policy yenilənməsi istifadəçiləri yeni identiklik yenidən bağlamağa məcbur edə, yeni ünvan ətrafında etibarı yenidən qurmağa, hətta tətbiq qaydalarını yaxşılaşdırdığı üçün yalnız yeni tətbiqetmə/məcburetmə marşrutuna köçürməyə məcbur edə bilərdi. Amma paradoks aydındır. Ünvan tərpənmir. Qayda isə tərpənir. Bir istifadəçi bir uyğunluq qaydası altında identikliyi bağlamış ola bilər. Daha sonra tətbiq eyni PolicyClient-in arxasındakı policy-ni yeniləyir. Ünvan yenə tanış görünür. Kimlik linki hələ də işləyir. İnteqrasiya təmiz qalır. Amma istifadəçi interfeysi dəyişməz kimi görünsə də, icazə sərhədi artıq istifadəçinin ilk dəfə güvəndiyi sərhəd olmaya bilər. Bu, dizaynı səhv etmir. Sadəcə olaraq yeniləmə şəffaflığının vacib olduğunu göstərir. Davamlılıq lazımsız pozulmanın qarşısını alanda yaxşıdır. Amma istifadəçilər tanış görünən ünvanın arxasında olan qaydanın nə vaxt dəyişdiyini görə bilməyəndə riskli olur. Məni geri qaytaran məhz bu hissədir. Sabiti saxlanan PolicyClient etibarı qoruyur, yoxsa qayda dəyişikliklərini daha asan nəzərdən qaçırdır? #Newt $LAB $NEWT
Eyni ünvan həmişə eyni qayda demək deyil.
Bu, məni dayandıran Nyutonun “smart contract” sənədlərindəki detal idi.
setPolicyAddress(newPolicy)
İlk baxışdan bu, səliqəli bir yeniləmə funksiyası kimi görünürdü. Protokol yeni policy kontraktı yerləşdirir, mövcud PolicyClient-i ona yönəldir və eyni client ünvanını saxlayır.
Kifayət qədər sadədir.
Amma həmin eyni ünvan önəmlidir.
@NewtonProtocol -da PolicyClient sadəcə texniki göstərici deyil. Bu, istifadəçilərin qarşılıqlı əlaqədə olduğu obyektdir. Kimlik əlaqələrinin bağlana biləcəyi yerdir, razılığın yığıldığı yerdir və bir tətbiqin etibar qurmağa başladığı yerdir.
Ona görə də Nyuton asanlıqla qarışdırıla bilən iki şeyi ayırır.
PolicyClient identiklik üçün “anchor”dur.
Policy isə onun arxasındakı qayda məntiqidir.
Bu faydalıdır.
Bu ayrım olmasaydı, hər bir policy yenilənməsi istifadəçiləri yeni identiklik yenidən bağlamağa məcbur edə, yeni ünvan ətrafında etibarı yenidən qurmağa, hətta tətbiq qaydalarını yaxşılaşdırdığı üçün yalnız yeni tətbiqetmə/məcburetmə marşrutuna köçürməyə məcbur edə bilərdi.
Amma paradoks aydındır.
Ünvan tərpənmir.
Qayda isə tərpənir.
Bir istifadəçi bir uyğunluq qaydası altında identikliyi bağlamış ola bilər. Daha sonra tətbiq eyni PolicyClient-in arxasındakı policy-ni yeniləyir. Ünvan yenə tanış görünür. Kimlik linki hələ də işləyir. İnteqrasiya təmiz qalır.
Amma istifadəçi interfeysi dəyişməz kimi görünsə də, icazə sərhədi artıq istifadəçinin ilk dəfə güvəndiyi sərhəd olmaya bilər.
Bu, dizaynı səhv etmir.
Sadəcə olaraq yeniləmə şəffaflığının vacib olduğunu göstərir.
Davamlılıq lazımsız pozulmanın qarşısını alanda yaxşıdır. Amma istifadəçilər tanış görünən ünvanın arxasında olan qaydanın nə vaxt dəyişdiyini görə bilməyəndə riskli olur.
Məni geri qaytaran məhz bu hissədir.
Sabiti saxlanan PolicyClient etibarı qoruyur, yoxsa qayda dəyişikliklərini daha asan nəzərdən qaçırdır?
#Newt $LAB $NEWT
Məqalə
Newton Protocol və Access ilə Ownership arasındakı sərhədBir dəfə bir app-ın dashboard-da köhnə bir neçə API key-i yenidən təmizləmişdim; əsasən siyahını xeyli vaxt idi ki, yoxlamırdım. Yazma (write) icazələrinə gələndə bir az donub qaldım: bu icazə həqiqətən API key-in içindədir, yoxsa API key-in təmsil etdiyi bir şeydədir? Bir neçə gün sonra Newton Protocol-un RPC API hissəsini oxuyanda, mən kiçik bir permission-da dayandım. RpcWrite Əvvəlcə mən yazma icazəsinin API key-in özündə olduğunu düşünürdüm. Bu, çox sistemlərdə olduqca tanış bir nümunədir: dashboard key-i verir, key read/write icazələrinə malik olur, doğru permission-u olan şəxs isə müvafiq endpoint-i çağırır. İlk baxışdan bu, yalnız Gateway-in normal access control-u kimi görünür.

Newton Protocol və Access ilə Ownership arasındakı sərhəd

Bir dəfə bir app-ın dashboard-da köhnə bir neçə API key-i yenidən təmizləmişdim; əsasən siyahını xeyli vaxt idi ki, yoxlamırdım. Yazma (write) icazələrinə gələndə bir az donub qaldım: bu icazə həqiqətən API key-in içindədir, yoxsa API key-in təmsil etdiyi bir şeydədir?
Bir neçə gün sonra Newton Protocol-un RPC API hissəsini oxuyanda, mən kiçik bir permission-da dayandım.
RpcWrite
Əvvəlcə mən yazma icazəsinin API key-in özündə olduğunu düşünürdüm. Bu, çox sistemlərdə olduqca tanış bir nümunədir: dashboard key-i verir, key read/write icazələrinə malik olur, doğru permission-u olan şəxs isə müvafiq endpoint-i çağırır. İlk baxışdan bu, yalnız Gateway-in normal access control-u kimi görünür.
Köhnə bir maliyyə tətbiqini açdım və KYC-nin hələ də “təsdiqlənmiş” kimi işarələndiyini gördüm. Bu söz gözlədiyimdən daha çox narahat etdi. Təsdiqlənmiş. Qəbul edilmiş. Keçid qapısından buraxılmış. Amma nə qədər düşünsəm, bir o qədər natamam hiss etdim. “Təsdiqlənmiş” şəxsiyyəti daimi bir möhür kimi göstərir. Sonra Newton Protocol-un “Identity Policy Reference” sənədini oxudum və bir neçə kiçik funksiyada dayandım: check_approved() not_expired() valid_for(min_days) issued_since(min_days) İlk baxışdan elə bildim ki, check_approved() əsas hissədir. İstifadəçi KYC-dən keçibsə, siyasət əməliyyatın davam etməsinə icazə verə bilər. Amma @NewtonProtocol -in dizaynının içində təsdiq yalnız dar bir sualı cavablandırır: bu şəxsiyyət müəyyən bir vaxtda qəbul edilibmi? Ən vacib sualı cavablandırmır: hazırda, icra anında bu şəxsiyyət hələ də etibarlıdırmı? Sərhəd budur. Onboarding deyil. İcra. İstifadəçi əvvəl təsdiqlənmiş ola bilər, amma etimadnamə hələ də çox köhnələ bilər, müddəti bitməsinə az qalıb, ya da indi icra edilən əməliyyat üçün artıq kifayət qədər etibarlılığa malik olmaya bilər. Əgər siyasət yalnız təsdiqi yoxlayırsa, icra, riskə yaradılan tələblər üçün artıq yetərli etibarlılığı qalmayan bir şəxsiyyət etimadnaməsinə əsaslana bilər. Məhz etibarlılıq üfüqü burada önəmlidir. Newton təkcə siyasətə “istifadəçi KYC-dən keçibmi?” sualını verməyə imkan vermir. O, siyasətin etimadnamənin bitib-bitmədiyini, nə qədər müddətə etibarlı qaldığını və nə vaxt verildiyini də soruşmasına imkan verir. Bu, şəxsiyyət haqqında düşüncəmi dəyişir. KYC bir dəfəlik qapı deyil. Ömrü olan bir şərtdir. Bu kompromis həqiqətən mövcuddur. Qaydanı çox sərt etsən, legitim istifadəçi etimadnaməsində az gün qaldığı üçün bloklana bilər. Çox boş atsən, sistem demək olar dəyərini itirməyə hazır olan şəxsiyyət məlumatına arxalana bilər. Dönə-dönə geri qayıtdığım hissə sadədir: onchain səlahiyyət yalnız şəxsiyyətin təsdiqlənib-təsdiqlənmədiyini soruşmamalıdır. O, bu təsdiqin hələ nə qədər etibar edilə biləcəyini soruşmalıdır. #Newt $NEWT
Köhnə bir maliyyə tətbiqini açdım və KYC-nin hələ də “təsdiqlənmiş” kimi işarələndiyini gördüm.
Bu söz gözlədiyimdən daha çox narahat etdi.
Təsdiqlənmiş.
Qəbul edilmiş.
Keçid qapısından buraxılmış.
Amma nə qədər düşünsəm, bir o qədər natamam hiss etdim.
“Təsdiqlənmiş” şəxsiyyəti daimi bir möhür kimi göstərir.
Sonra Newton Protocol-un “Identity Policy Reference” sənədini oxudum və bir neçə kiçik funksiyada dayandım:
check_approved()
not_expired()
valid_for(min_days)
issued_since(min_days)
İlk baxışdan elə bildim ki, check_approved() əsas hissədir. İstifadəçi KYC-dən keçibsə, siyasət əməliyyatın davam etməsinə icazə verə bilər.
Amma @NewtonProtocol -in dizaynının içində təsdiq yalnız dar bir sualı cavablandırır:
bu şəxsiyyət müəyyən bir vaxtda qəbul edilibmi?
Ən vacib sualı cavablandırmır:
hazırda, icra anında bu şəxsiyyət hələ də etibarlıdırmı?
Sərhəd budur.
Onboarding deyil.
İcra.
İstifadəçi əvvəl təsdiqlənmiş ola bilər, amma etimadnamə hələ də çox köhnələ bilər, müddəti bitməsinə az qalıb, ya da indi icra edilən əməliyyat üçün artıq kifayət qədər etibarlılığa malik olmaya bilər.
Əgər siyasət yalnız təsdiqi yoxlayırsa, icra, riskə yaradılan tələblər üçün artıq yetərli etibarlılığı qalmayan bir şəxsiyyət etimadnaməsinə əsaslana bilər.
Məhz etibarlılıq üfüqü burada önəmlidir.
Newton təkcə siyasətə “istifadəçi KYC-dən keçibmi?” sualını verməyə imkan vermir. O, siyasətin etimadnamənin bitib-bitmədiyini, nə qədər müddətə etibarlı qaldığını və nə vaxt verildiyini də soruşmasına imkan verir.
Bu, şəxsiyyət haqqında düşüncəmi dəyişir.
KYC bir dəfəlik qapı deyil.
Ömrü olan bir şərtdir.
Bu kompromis həqiqətən mövcuddur. Qaydanı çox sərt etsən, legitim istifadəçi etimadnaməsində az gün qaldığı üçün bloklana bilər. Çox boş atsən, sistem demək olar dəyərini itirməyə hazır olan şəxsiyyət məlumatına arxalana bilər.
Dönə-dönə geri qayıtdığım hissə sadədir:
onchain səlahiyyət yalnız şəxsiyyətin təsdiqlənib-təsdiqlənmədiyini soruşmamalıdır.
O, bu təsdiqin hələ nə qədər etibar edilə biləcəyini soruşmalıdır.
#Newt $NEWT
Məqalə
Şifrələnmiş Məlumat Həmişə Təhlükəsiz DeyilAşkar məxfilik riski şifrələnməmiş məlumatdır. Newton-un sənədləri məni daha sakit birinə baxmağa vadar etdi: şifrələnmiş məlumatların yanlış kontekstdə istifadə olunması. Privacy Layer-də bir kiçik detal məni dayandırdı: policy_client chain_id İlk baxışda onlar metadata kimi görünürdü. Şifrələnmiş məlumatın hansı tətbiqə aid olduğunu deməyin bir yolu. Hansı zəncir üçün yaradıldığını deməyin bir yolu. Normal uçot. Amma @NewtonProtocol -in dizaynının içində bu sahələr daha vacib iş görür. Onlar şifrəli mətni kontekstə bağlayır. Newton şifrələnmiş məlumatı, haraya aparılıb hər hansı bir policy ehtiyac duydusa orada təkrar istifadə edilə bilən sərbəst “blob” kimi qəbul etmir. Şifrələnmiş yük konkret bir PolicyClient-ə və konkret bir zəncirə bağlıdır. Əgər bu kontekst dəyişərsə, məlumat sanki heç nə olmamış kimi deşifrə olunmamalıdır.

Şifrələnmiş Məlumat Həmişə Təhlükəsiz Deyil

Aşkar məxfilik riski şifrələnməmiş məlumatdır.
Newton-un sənədləri məni daha sakit birinə baxmağa vadar etdi: şifrələnmiş məlumatların yanlış kontekstdə istifadə olunması.
Privacy Layer-də bir kiçik detal məni dayandırdı:
policy_client chain_id
İlk baxışda onlar metadata kimi görünürdü.
Şifrələnmiş məlumatın hansı tətbiqə aid olduğunu deməyin bir yolu. Hansı zəncir üçün yaradıldığını deməyin bir yolu. Normal uçot.
Amma @NewtonProtocol -in dizaynının içində bu sahələr daha vacib iş görür.
Onlar şifrəli mətni kontekstə bağlayır.
Newton şifrələnmiş məlumatı, haraya aparılıb hər hansı bir policy ehtiyac duydusa orada təkrar istifadə edilə bilən sərbəst “blob” kimi qəbul etmir. Şifrələnmiş yük konkret bir PolicyClient-ə və konkret bir zəncirə bağlıdır. Əgər bu kontekst dəyişərsə, məlumat sanki heç nə olmamış kimi deşifrə olunmamalıdır.
Doğrulanıb
Dün gecə @grvt_io -un arxitekturasındakı bir detal “hibird” sözünü demək olar ki, yanıltıcı hiss etdirdi: Uyğunlaşdırma mühərriki ticarət əmirlərinin qərarını verə bilər. Amma özü təkbaşına bunu yekun qərar edə bilməz. Əvvəlcə bunu sadə performans seçimi kimi qəbul etdim. Sifariş kitabları hər bir kotirovka, ləğv və uyğunlaşma üçün blokçeyn konsensisini gözləmək üçün çox tez hərəkət edir. Uyğunlaşdırmanı və icranı ofçeynə köçürmək Grvt-yə ticarət platformasına lazım olan sürəti verir. Amma ayrım əslində güc haqqındadır. Ofçeyn mühərriki əmrləri qəbul edə, onları ardıcıllaşdıra və hansı ticarətlərin baş verməli olduğunu təklif edə bilər. Sonra hesablaşma (settlement) həmin təklifi balanslara, girov (kollateral) dəyişikliklərinə, marja öhdəliklərinə və çıxarış (withdrawal) hüquqlarına çevirir. İkinci addımda icra artıq maliyyə vəziyyətinə çevrilir. Grvt qəyyumluğu (custody), hesablaşmanı, marja idarəçiliyini və çıxarış istəklərini onçeynlə yerləşdirir ki, sürətli qat öz rekordunu səssizcə son mülkiyyətə çevirə bilməsin. Mübadilə (trade-off) ondan ibarətdir ki, istifadəçilər yalnız onçeyn vəziyyətdən tam uyğunlaşdırma prosesini yenidən qura bilmirlər. Onlar yenə də operatorun əmrləri qəbul etməsinə, mühərrikin işlək qalmasına və ardıcıllıq qaydalarını tutarlı tətbiq etməsinə ümid edirlər. Etibarlı hesablaşma nəticədəki balans yeniləməsinin kodlaşdırılmış qaydalara uyğun getdiyini təsdiq edə bilər, lakin daha əvvəlki bir əmrin gecikdirilmədiyini, buraxılmadığını və ya başqa cür ardıcıllaşdırılmadığını sübut etmir. Beləliklə Grvt bütün ticarət yolunu etibarsız (trustless) etmir. Operator ixtiyarının geri qaytarılması ən çətin olduğu hissə ətrafında sərhəd çəkir. Gecikmiş əmrlə bağlı risk icra problemidir. Yenidən yazılmış balans isə qəyyumluq (custody) problemidir. Bu risklər eyni səlahiyyətin altında paylaşılmamalıdır. Hesabatları bağladıqdan sonra da geri döndüyüm əsas hissə məhz budur. Hibrid birjanın dərin dəyəri ofçeyndə nə qədər aktivlik yaratmasında deyil; sürətin birtərəfli (unitlateral) nəzarətə çevrilməsini harada dayandırmasındadır. Qəti həll olunmamış sual istifadəçilərin hesablaşma yolunu – təkcə sonra görünən vəziyyəti deyil, həm də yolun özünü – kifayət qədər yoxlayıb-yaşadığını görə bilməsidir. #grvt
Dün gecə @grvt_io -un arxitekturasındakı bir detal “hibird” sözünü demək olar ki, yanıltıcı hiss etdirdi:
Uyğunlaşdırma mühərriki ticarət əmirlərinin qərarını verə bilər.
Amma özü təkbaşına bunu yekun qərar edə bilməz.
Əvvəlcə bunu sadə performans seçimi kimi qəbul etdim. Sifariş kitabları hər bir kotirovka, ləğv və uyğunlaşma üçün blokçeyn konsensisini gözləmək üçün çox tez hərəkət edir. Uyğunlaşdırmanı və icranı ofçeynə köçürmək Grvt-yə ticarət platformasına lazım olan sürəti verir.
Amma ayrım əslində güc haqqındadır.
Ofçeyn mühərriki əmrləri qəbul edə, onları ardıcıllaşdıra və hansı ticarətlərin baş verməli olduğunu təklif edə bilər. Sonra hesablaşma (settlement) həmin təklifi balanslara, girov (kollateral) dəyişikliklərinə, marja öhdəliklərinə və çıxarış (withdrawal) hüquqlarına çevirir.
İkinci addımda icra artıq maliyyə vəziyyətinə çevrilir.
Grvt qəyyumluğu (custody), hesablaşmanı, marja idarəçiliyini və çıxarış istəklərini onçeynlə yerləşdirir ki, sürətli qat öz rekordunu səssizcə son mülkiyyətə çevirə bilməsin.
Mübadilə (trade-off) ondan ibarətdir ki, istifadəçilər yalnız onçeyn vəziyyətdən tam uyğunlaşdırma prosesini yenidən qura bilmirlər.
Onlar yenə də operatorun əmrləri qəbul etməsinə, mühərrikin işlək qalmasına və ardıcıllıq qaydalarını tutarlı tətbiq etməsinə ümid edirlər. Etibarlı hesablaşma nəticədəki balans yeniləməsinin kodlaşdırılmış qaydalara uyğun getdiyini təsdiq edə bilər, lakin daha əvvəlki bir əmrin gecikdirilmədiyini, buraxılmadığını və ya başqa cür ardıcıllaşdırılmadığını sübut etmir.
Beləliklə Grvt bütün ticarət yolunu etibarsız (trustless) etmir.
Operator ixtiyarının geri qaytarılması ən çətin olduğu hissə ətrafında sərhəd çəkir.
Gecikmiş əmrlə bağlı risk icra problemidir.
Yenidən yazılmış balans isə qəyyumluq (custody) problemidir.
Bu risklər eyni səlahiyyətin altında paylaşılmamalıdır.
Hesabatları bağladıqdan sonra da geri döndüyüm əsas hissə məhz budur.
Hibrid birjanın dərin dəyəri ofçeyndə nə qədər aktivlik yaratmasında deyil; sürətin birtərəfli (unitlateral) nəzarətə çevrilməsini harada dayandırmasındadır.
Qəti həll olunmamış sual istifadəçilərin hesablaşma yolunu – təkcə sonra görünən vəziyyəti deyil, həm də yolun özünü – kifayət qədər yoxlayıb-yaşadığını görə bilməsidir.
#grvt
Bir neçə gün əvvəl köhnə bir transaksiyanın calldata-sına yenidən baxdım və anladım ki, riskli hissə bəzən ilk dörd baytda yerləşə bilər. Funksiya selektoru. Bu ilk dörd bayt müqavilənin hansı funksiyaya çağırış aldığını göstərir. Əvvəlcə bu, adi Solidity “boru-kəmər” işləri kimi göründü. Bir müqavilə calldata qəbul edir, selektoru oxuyur və çağırışı doğru funksiyaya yönləndirir. Heç nə qeyri-adi deyil. Amma @NewtonProtocol -in səlahiyyət (authorization) modelinin daxilində bu kiçik detal önəmli olur. Müqavilə ünvanı tək bir əməliyyatı ifadə etmir. Eyni müqavilə deposit(), withdraw(), transfer(), setOperator() və ya upgradePolicy() kimi müxtəlif funksiyalar aça bilər. Kənardan bunların hamısı eyni ünvana işarə edir. Amma risk baxımından onlar tamamilə fərqli qapılardır. Düzgün müqavilə hər zaman düzgün əməliyyat demək deyil. Elə buradadır ki, Funksiya Selektoru İstifadəsi (Function Selector Binding) calldata yönləndirilməsindən daha çox şeyə çevrilir. Elə buradadır ki, geniş müqavilə icazəsi konkret bir əməliyyat icazəsinə çevrilir. Bir siyasət (policy) “müqavilə çağırışı”nı boş bir mənada təsdiq etməməlidir. Transaksiyanın hansı funksiyaya girdiyini bilməlidir. deposit() üçün yazılmış qayda təsadüfən withdraw() üçün icazəyə çevrilməməlidir. Normal transfer qaydası operatoru yeniləmək və ya konfiqurasiyanı dəyişmək icazəsi ilə qarışdırılmamalıdır. Bu dəqiqlik önəmlidir. Amma o, həm də bir ticarət (tradeoff) yaradır. Əməliyyat səviyyəsində icazələndirmə tərtibatçılardan daha açıq olmaq tələb edir. Qeyri-müəyyən siyasət yazmaq daha asan və təkrar istifadə etmək daha rahatdır, amma həm də daha geniş icazə səthi (permission surface) yaradır. Daha dəqiq siyasət daha çox diqqət tələb edir, lakin təsdiqin əhatə edə biləcəyi sahəni daraldır. Mənim daim geri qayıtdığım hissə budur. İstifadəçi doğru ola bilər. Müqavilə doğru ola bilər. Siyasət də doğru ola bilər. Amma icazə sərhədi çox genişdirsə, təsdiq yenə də nəzərdə tutulduğundan daha çox şeyə toxuna bilər. Onchain icazələndirmə təkcə istifadəçinin bir müqavilə ilə qarşılıqlı əlaqədə ola biləcəyini soruşmamalıdır. Həmin müqavilə daxilində hansı konkret qapını açmağa icazə verildiyini soruşmalıdır. $NEWT #Newt
Bir neçə gün əvvəl köhnə bir transaksiyanın calldata-sına yenidən baxdım və anladım ki, riskli hissə bəzən ilk dörd baytda yerləşə bilər.
Funksiya selektoru.
Bu ilk dörd bayt müqavilənin hansı funksiyaya çağırış aldığını göstərir.
Əvvəlcə bu, adi Solidity “boru-kəmər” işləri kimi göründü. Bir müqavilə calldata qəbul edir, selektoru oxuyur və çağırışı doğru funksiyaya yönləndirir. Heç nə qeyri-adi deyil.
Amma @NewtonProtocol -in səlahiyyət (authorization) modelinin daxilində bu kiçik detal önəmli olur.
Müqavilə ünvanı tək bir əməliyyatı ifadə etmir.
Eyni müqavilə deposit(), withdraw(), transfer(), setOperator() və ya upgradePolicy() kimi müxtəlif funksiyalar aça bilər. Kənardan bunların hamısı eyni ünvana işarə edir. Amma risk baxımından onlar tamamilə fərqli qapılardır.
Düzgün müqavilə hər zaman düzgün əməliyyat demək deyil.
Elə buradadır ki, Funksiya Selektoru İstifadəsi (Function Selector Binding) calldata yönləndirilməsindən daha çox şeyə çevrilir.
Elə buradadır ki, geniş müqavilə icazəsi konkret bir əməliyyat icazəsinə çevrilir.
Bir siyasət (policy) “müqavilə çağırışı”nı boş bir mənada təsdiq etməməlidir. Transaksiyanın hansı funksiyaya girdiyini bilməlidir. deposit() üçün yazılmış qayda təsadüfən withdraw() üçün icazəyə çevrilməməlidir. Normal transfer qaydası operatoru yeniləmək və ya konfiqurasiyanı dəyişmək icazəsi ilə qarışdırılmamalıdır.
Bu dəqiqlik önəmlidir.
Amma o, həm də bir ticarət (tradeoff) yaradır.
Əməliyyat səviyyəsində icazələndirmə tərtibatçılardan daha açıq olmaq tələb edir. Qeyri-müəyyən siyasət yazmaq daha asan və təkrar istifadə etmək daha rahatdır, amma həm də daha geniş icazə səthi (permission surface) yaradır. Daha dəqiq siyasət daha çox diqqət tələb edir, lakin təsdiqin əhatə edə biləcəyi sahəni daraldır.
Mənim daim geri qayıtdığım hissə budur.
İstifadəçi doğru ola bilər.
Müqavilə doğru ola bilər.
Siyasət də doğru ola bilər.
Amma icazə sərhədi çox genişdirsə, təsdiq yenə də nəzərdə tutulduğundan daha çox şeyə toxuna bilər.
Onchain icazələndirmə təkcə istifadəçinin bir müqavilə ilə qarşılıqlı əlaqədə ola biləcəyini soruşmamalıdır.
Həmin müqavilə daxilində hansı konkret qapını açmağa icazə verildiyini soruşmalıdır.
$NEWT #Newt
Daha çox kontent araşdırmaq üçün daxil olun
Binance Square-də qlobal kriptovalyuta istifadəçilərinə qoşulun
⚡️ Kriptovalyuta haqqında ən son və faydalı məlumatları əldə edin.
💬 Dünyanın ən böyük kriptovalyuta birjası tərəfindən etibar edilir.
👍 Doğrulanmış yaradıcılardan gələn real məlumatları kəşf edin.
E-poçt/Telefon nömrəsi
Saytın xəritəsi
Kuki seçimləri
Platformanın şərt və müddəaları