Toro_crypto
810 Beiträge
Toro_crypto
BNB Halter
Hochfrequenz-Trader
4.6 Jahre
202 Following
382 Follower
447 Like gegeben
Beiträge
Alle
Zitierungen
PINNED
Übersetzung ansehen
#dusk $DUSK @Dusk
Imagine a market in which the transaction cost, which will run to several million pounds, is one that must be approved by a committee.
And it wouldn‘t make any difference if it were another group being informed a long way before the decision was made.
But there‘s another problem.
How does this satisfy “if you chose who is to make the decision at random, how do you assure everyone is agreed on what the outcome is”.
That was precisely the uniqueness of it all when I dug more into Dusk‘s Succinct Attestation.
The protocol uses a balloting mechanism. In each balloting round the members that were selected randomly for provisioners make proposals on committees, vote, and ratify blocks. When a block is ratified, the network gets some kind of deterministic finality.
That creates an interesting distinction:
An unpredictable selection pressure does not entail an unpredictable outcome.
The first one, however, may make measures more uncertain.
And the second would be an issue.
An example of this is a firm clearing security, where the security has been extensively tokenised, fragmented and diluted.
It implies that network does produce eventually a value on which the participants will be able to trust.
And that, I believe, is the point where the consensus design becomes more than simply saying “Dusk uses Proof-of-Stake.”
The question isn‘t only:
But, if anyone, who is he that should be chosen.
It‘s also:
And so it follows that it is ready to enter into... where??
In the dynamics of a financial market, such unpredictability can undermine future participations.
Yet, the final decision has still to be deterministic toward settlement.
At the time when infrastructure of the blockchain itself is intersected by real assets of finance, random is not a synonymous word of uncertain.
What I would want to monitor over time would be scalability. Specifically, the scalability of the model as the level of institutional activity drawing upon the same end result increases.
Imagine a market in which the transaction cost, which will run to several million pounds, is one that must be approved by a committee.
And it wouldn‘t make any difference if it were another group being informed a long way before the decision was made.
But there‘s another problem.
How does this satisfy “if you chose who is to make the decision at random, how do you assure everyone is agreed on what the outcome is”.
That was precisely the uniqueness of it all when I dug more into Dusk‘s Succinct Attestation.
The protocol uses a balloting mechanism. In each balloting round the members that were selected randomly for provisioners make proposals on committees, vote, and ratify blocks. When a block is ratified, the network gets some kind of deterministic finality.
That creates an interesting distinction:
An unpredictable selection pressure does not entail an unpredictable outcome.
The first one, however, may make measures more uncertain.
And the second would be an issue.
An example of this is a firm clearing security, where the security has been extensively tokenised, fragmented and diluted.
It implies that network does produce eventually a value on which the participants will be able to trust.
And that, I believe, is the point where the consensus design becomes more than simply saying “Dusk uses Proof-of-Stake.”
The question isn‘t only:
But, if anyone, who is he that should be chosen.
It‘s also:
And so it follows that it is ready to enter into... where??
In the dynamics of a financial market, such unpredictability can undermine future participations.
Yet, the final decision has still to be deterministic toward settlement.
At the time when infrastructure of the blockchain itself is intersected by real assets of finance, random is not a synonymous word of uncertain.
What I would want to monitor over time would be scalability. Specifically, the scalability of the model as the level of institutional activity drawing upon the same end result increases.
PINNED
Verifiziert
Übersetzung ansehen
Smart contracts are programmable but it does not mean the whole financial processes are fully automated.
This led me to consider the simplest case: how this works with a tokenized security in which dividend payments must be made.
The reasons of that, first, it seems to be too simple;
Rules onchain; the contract adjudicates, then distributes.
But one detail matters:
Programmable ≠ autonomous.
How this is translated into logic:
Cannot necessarily be assumed to have knowledge that original corporate action was done properly, the necessary funds are present or if an off chain calculation was valid.
However, this difference may be further emphasized under a regulated market.
Dusk have defined the Confidential Security Contract scheme from financial flows such as payment of dividend and voting rather than taking security as a token.
And it is in this that I find the architecture fascinating.
The point is not to get more logic onchain.
The goal is to match that thinking with reality: the characteristics of the asset itself rules of ownership, eligibility, servicing, settlement and known disclosure (sometimes referred to as “the facts”).
In practice, an automated system can only ever be as good as the data and rules which underpin it.
So the interesting question for me isn‘t:
Can state-controlled assets be programmed?
We already knew this could.
The harder question is:
How much of the real financial process can be truly automated, and still without completely removing the human element, where it still exists in regulated markets?
I would want to observe that over time.
#dusk @Dusk $DUSK
This led me to consider the simplest case: how this works with a tokenized security in which dividend payments must be made.
The reasons of that, first, it seems to be too simple;
Rules onchain; the contract adjudicates, then distributes.
But one detail matters:
Programmable ≠ autonomous.
How this is translated into logic:
Cannot necessarily be assumed to have knowledge that original corporate action was done properly, the necessary funds are present or if an off chain calculation was valid.
However, this difference may be further emphasized under a regulated market.
Dusk have defined the Confidential Security Contract scheme from financial flows such as payment of dividend and voting rather than taking security as a token.
And it is in this that I find the architecture fascinating.
The point is not to get more logic onchain.
The goal is to match that thinking with reality: the characteristics of the asset itself rules of ownership, eligibility, servicing, settlement and known disclosure (sometimes referred to as “the facts”).
In practice, an automated system can only ever be as good as the data and rules which underpin it.
So the interesting question for me isn‘t:
Can state-controlled assets be programmed?
We already knew this could.
The harder question is:
How much of the real financial process can be truly automated, and still without completely removing the human element, where it still exists in regulated markets?
I would want to observe that over time.
#dusk @Dusk $DUSK
Übersetzung ansehen
I’ve been thinking about what “ownership” actually means in a real financial market.
Say you buy shares in a company.
The transaction clears, and the asset is officially in your name. On paper, it’s that simple.
But things get messy the moment reality hits.
A dividend gets announced. A shareholder vote comes up. Or a corporate action changes the asset entirely.
At that point, the question isn’t just: "Who stands to claim this?"
The real, operational question is: What does that title actually trigger inside the system?
Because locking down a record on a ledger is easy. Deploying the actual workflow behind it is a completely different beast.
Paperwork sounds straightforward, but execution has moving parts. The right investor needs to get paid. The right holder needs to vote. Every transfer has to clear strict eligibility rules. And all of this has to stay perfectly synced, day after day.
That’s where the bottleneck happens.
If ownership sits in one system, eligibility compliance in another, and corporate actions in a third, your records might be flawless, but the actual process still runs on brute-force reconciliation between siloed databases.
That’s why I find Dusk interesting.
Their approach to regulated assets isn't just about putting titles on a blockchain for the sake of it.
The real test is whether they can collapse ownership, eligibility, transfers, and corporate actions into a single, unified financial workflow.
A static ledger can only tell you who owns what.
A functional financial system needs to understand what that asset is actually allowed to do.
And that’s the part I’m watching: can legal ownership actually become operational ownership in practice?
#dusk @Dusk $DUSK
Say you buy shares in a company.
The transaction clears, and the asset is officially in your name. On paper, it’s that simple.
But things get messy the moment reality hits.
A dividend gets announced. A shareholder vote comes up. Or a corporate action changes the asset entirely.
At that point, the question isn’t just: "Who stands to claim this?"
The real, operational question is: What does that title actually trigger inside the system?
Because locking down a record on a ledger is easy. Deploying the actual workflow behind it is a completely different beast.
Paperwork sounds straightforward, but execution has moving parts. The right investor needs to get paid. The right holder needs to vote. Every transfer has to clear strict eligibility rules. And all of this has to stay perfectly synced, day after day.
That’s where the bottleneck happens.
If ownership sits in one system, eligibility compliance in another, and corporate actions in a third, your records might be flawless, but the actual process still runs on brute-force reconciliation between siloed databases.
That’s why I find Dusk interesting.
Their approach to regulated assets isn't just about putting titles on a blockchain for the sake of it.
The real test is whether they can collapse ownership, eligibility, transfers, and corporate actions into a single, unified financial workflow.
A static ledger can only tell you who owns what.
A functional financial system needs to understand what that asset is actually allowed to do.
And that’s the part I’m watching: can legal ownership actually become operational ownership in practice?
#dusk @Dusk $DUSK
Übersetzung ansehen
I was looking at Dusk again, and one distinction kept bothering me:
A working protocol ≠ a working market.
At first, it’s easy to look at a blockchain that can execute transactions, support financial applications, and handle the technical side of regulated assets and think:
“Okay, the infrastructure works.”
But that’s only one part of the question.
The more interesting question is what happens when the infrastructure meets an actual financial market.
Because a real market needs more than technology.
It needs issuers who can create assets.
Investors who can interact with them.
Rules that can be enforced in practice.
Transfers that follow those rules.
And activity that continues over time.
That distinction matters.
A protocol can prove that something is technically possible.
A market has to prove that people and institutions actually find it useful enough to keep using.
This is where I think Dusk becomes more interesting to watch.
Its architecture is clearly being designed around regulated financial use cases, but the harder question isn’t whether the technology can support them.
It’s whether real financial activity can eventually emerge around that infrastructure.
That’s the part I want to watch over time:
Does technical capability become recurring market activity?
Because a working protocol is evidence of engineering.
A working market is evidence of utility.
And those are not the same thing.
@Dusk #dusk $DUSK
A working protocol ≠ a working market.
At first, it’s easy to look at a blockchain that can execute transactions, support financial applications, and handle the technical side of regulated assets and think:
“Okay, the infrastructure works.”
But that’s only one part of the question.
The more interesting question is what happens when the infrastructure meets an actual financial market.
Because a real market needs more than technology.
It needs issuers who can create assets.
Investors who can interact with them.
Rules that can be enforced in practice.
Transfers that follow those rules.
And activity that continues over time.
That distinction matters.
A protocol can prove that something is technically possible.
A market has to prove that people and institutions actually find it useful enough to keep using.
This is where I think Dusk becomes more interesting to watch.
Its architecture is clearly being designed around regulated financial use cases, but the harder question isn’t whether the technology can support them.
It’s whether real financial activity can eventually emerge around that infrastructure.
That’s the part I want to watch over time:
Does technical capability become recurring market activity?
Because a working protocol is evidence of engineering.
A working market is evidence of utility.
And those are not the same thing.
@Dusk #dusk $DUSK
Übersetzung ansehen
A few days ago, I was looking at DuskEVM again and caught myself making an assumption I probably shouldn’t have.
If developers can use Solidity and familiar EVM tooling, then getting developers to build on Dusk should be much easier.
That part is true.
But easier to build on ≠ actually being built on.
And that distinction matters more than I first thought.
DuskEVM lowers the entry barrier for developers who already understand the EVM stack. They don’t have to start from an entirely unfamiliar development environment.
Hedger adds another interesting layer by bringing privacy-oriented functionality into that environment, while the broader Dusk architecture is aimed at things like tokenized assets, DeFi, lending and financial applications.
On paper, the ingredients are there.
But infrastructure readiness is only one part of the equation.
What I’d actually want to see is what happens after developers arrive.
How many contracts are deployed?
How many remain active after the initial test?
How many applications generate repeat transactions?
And more importantly, how much of that activity comes from real users rather than developers simply experimenting with the infrastructure?
That’s where I think the difference between developer access and developer adoption becomes important.
A testnet can prove that something works.
A developer can prove that something can be built.
But neither automatically proves that an ecosystem is forming.
That doesn’t make DuskEVM less interesting to me. If anything, it gives me a better metric to watch.
Instead of asking:
“Can developers build on Dusk?”
I’d rather ask:
“What are developers still building on Dusk six months later?”
Because infrastructure becomes much more convincing when the activity stops being a demo and starts becoming a habit.
And that’s the part of Dusk’s developer story I’m most curious to see.
@Dusk #dusk $DUSK
If developers can use Solidity and familiar EVM tooling, then getting developers to build on Dusk should be much easier.
That part is true.
But easier to build on ≠ actually being built on.
And that distinction matters more than I first thought.
DuskEVM lowers the entry barrier for developers who already understand the EVM stack. They don’t have to start from an entirely unfamiliar development environment.
Hedger adds another interesting layer by bringing privacy-oriented functionality into that environment, while the broader Dusk architecture is aimed at things like tokenized assets, DeFi, lending and financial applications.
On paper, the ingredients are there.
But infrastructure readiness is only one part of the equation.
What I’d actually want to see is what happens after developers arrive.
How many contracts are deployed?
How many remain active after the initial test?
How many applications generate repeat transactions?
And more importantly, how much of that activity comes from real users rather than developers simply experimenting with the infrastructure?
That’s where I think the difference between developer access and developer adoption becomes important.
A testnet can prove that something works.
A developer can prove that something can be built.
But neither automatically proves that an ecosystem is forming.
That doesn’t make DuskEVM less interesting to me. If anything, it gives me a better metric to watch.
Instead of asking:
“Can developers build on Dusk?”
I’d rather ask:
“What are developers still building on Dusk six months later?”
Because infrastructure becomes much more convincing when the activity stops being a demo and starts becoming a habit.
And that’s the part of Dusk’s developer story I’m most curious to see.
@Dusk #dusk $DUSK
Übersetzung ansehen
Cách đây 2 năm về trước, tôi từng là 1 quản lý cấp cao của một công ty phần mềm.
Tôi thường hay dùng thẻ của mình để vào khu vực làm việc, nhưng không thể mở cửa phòng server hay phòng lưu trữ hồ sơ.
Ban đầu tôi nghĩ đó đơn giản chỉ là một hệ thống kiểm soát quyền truy cập.
Nhưng sau này tôi nhận ra một điều thú vị:
Một hệ thống tốt không đợi đến lúc dữ liệu bị lộ mới bắt đầu bảo vệ nó.
Điều này khiến tôi nghĩ đến @Dusk .
Trong regulated finance, privacy cũng không nên là một lớp được thêm vào sau khi tài sản và giao dịch đã được đưa lên-chain.
Nó cần được tính đến ngay từ cách hệ thống xử lý tài sản, identity và transaction.
Đó là điều tôi thấy thú vị ở cách Dusk tiếp cận privacy.
Với Phoenix cho confidential transactions và Moonlight cho transparent account-based transactions, privacy không nhất thiết phải là một lựa chọn “bật hoặc tắt” cho toàn bộ hệ thống.
Các loại giao dịch khác nhau có thể cần những mức độ visibility khác nhau.
Và với zero-knowledge proofs, một bên có thể chứng minh rằng một điều kiện cần thiết đã được đáp ứng mà không nhất thiết phải tiết lộ toàn bộ dữ liệu phía sau.
Đối với regulated assets, điều này rất quan trọng.
Một hệ thống tài chính không chỉ cần hỏi:
“Dữ liệu này có được bảo mật không?”
Mà còn phải hỏi:
“Privacy đã được thiết kế vào infrastructure ngay từ đầu chưa?”
Đó là điểm khiến tôi thấy khái niệm privacy by design đáng chú ý hơn rất nhiều so với việc đơn giản thêm một lớp privacy vào blockchain.
Và có lẽ đây cũng là một phần lý do Dusk đang đi theo một hướng khá khác khi xây dựng infrastructure cho regulated finance.
#dusk $DUSK
Tôi thường hay dùng thẻ của mình để vào khu vực làm việc, nhưng không thể mở cửa phòng server hay phòng lưu trữ hồ sơ.
Ban đầu tôi nghĩ đó đơn giản chỉ là một hệ thống kiểm soát quyền truy cập.
Nhưng sau này tôi nhận ra một điều thú vị:
Một hệ thống tốt không đợi đến lúc dữ liệu bị lộ mới bắt đầu bảo vệ nó.
Điều này khiến tôi nghĩ đến @Dusk .
Trong regulated finance, privacy cũng không nên là một lớp được thêm vào sau khi tài sản và giao dịch đã được đưa lên-chain.
Nó cần được tính đến ngay từ cách hệ thống xử lý tài sản, identity và transaction.
Đó là điều tôi thấy thú vị ở cách Dusk tiếp cận privacy.
Với Phoenix cho confidential transactions và Moonlight cho transparent account-based transactions, privacy không nhất thiết phải là một lựa chọn “bật hoặc tắt” cho toàn bộ hệ thống.
Các loại giao dịch khác nhau có thể cần những mức độ visibility khác nhau.
Và với zero-knowledge proofs, một bên có thể chứng minh rằng một điều kiện cần thiết đã được đáp ứng mà không nhất thiết phải tiết lộ toàn bộ dữ liệu phía sau.
Đối với regulated assets, điều này rất quan trọng.
Một hệ thống tài chính không chỉ cần hỏi:
“Dữ liệu này có được bảo mật không?”
Mà còn phải hỏi:
“Privacy đã được thiết kế vào infrastructure ngay từ đầu chưa?”
Đó là điểm khiến tôi thấy khái niệm privacy by design đáng chú ý hơn rất nhiều so với việc đơn giản thêm một lớp privacy vào blockchain.
Và có lẽ đây cũng là một phần lý do Dusk đang đi theo một hướng khá khác khi xây dựng infrastructure cho regulated finance.
#dusk $DUSK
Übersetzung ansehen
Sau 4 ngày tìm hiểu TermMax, mình nhận ra mình đã nhìn nó sai ở một điểm.
Ban đầu, mình cố tìm một tính năng nổi bật nhất.
Fixed rate?
RWA?
Range Order?
Liquidation?
Nhưng càng tìm hiểu, mình càng thấy câu hỏi thú vị hơn không phải là:
“TermMax có gì?”
Mà là:
“Những thứ đó kết nối với nhau để tạo ra điều gì?”
Fixed-rate lending tạo ra khả năng dự đoán chi phí vốn.
Tokenized assets mở thêm nguồn collateral có thể sử dụng on-chain.
Range Order tạo ra một cách khác để liquidity tham gia vào việc hình thành rate.
Và Physical Delivery Liquidation đặt ra một framework khác cho cách xử lý rủi ro khi vị thế đi ngược kỳ vọng.
Nếu nhìn từng phần riêng lẻ, chúng chỉ giống những tính năng của một lending protocol.
Nhưng khi đặt cạnh nhau, mình bắt đầu thấy một câu chuyện khác:
Capital → Pricing → Liquidity → Collateral → Risk
Đó không còn chỉ là câu chuyện về một khoản vay.
Nó giống một nỗ lực xây dựng financial infrastructure có thể kết nối nhiều lớp của thị trường vốn on-chain.
Và đây cũng là điều mình thích nhất ở cách @TermMax tiếp cận vấn đề.
Họ không chỉ hỏi:
“Làm thế nào để người dùng vay?”
Mà dường như đang đặt những câu hỏi rộng hơn:
Làm thế nào để vốn có thể được định giá rõ ràng hơn?
Làm thế nào để tài sản tokenized có thêm utility?
Làm thế nào để liquidity được tổ chức quanh fixed-rate markets?
Và khi mọi thứ đi sai, hệ thống sẽ xử lý risk như thế nào?
Mình chưa nghĩ TermMax đã trả lời hoàn hảo tất cả những câu hỏi đó.
Nhưng sau 5 ngày tìm hiểu, mình nghĩ đó mới chính là lý do đáng để tiếp tục theo dõi.
Không phải vì TermMax có một feature nổi bật.
Mà vì các mảnh ghép bắt đầu trông giống một hệ thống.
#TermMax
Ban đầu, mình cố tìm một tính năng nổi bật nhất.
Fixed rate?
RWA?
Range Order?
Liquidation?
Nhưng càng tìm hiểu, mình càng thấy câu hỏi thú vị hơn không phải là:
“TermMax có gì?”
Mà là:
“Những thứ đó kết nối với nhau để tạo ra điều gì?”
Fixed-rate lending tạo ra khả năng dự đoán chi phí vốn.
Tokenized assets mở thêm nguồn collateral có thể sử dụng on-chain.
Range Order tạo ra một cách khác để liquidity tham gia vào việc hình thành rate.
Và Physical Delivery Liquidation đặt ra một framework khác cho cách xử lý rủi ro khi vị thế đi ngược kỳ vọng.
Nếu nhìn từng phần riêng lẻ, chúng chỉ giống những tính năng của một lending protocol.
Nhưng khi đặt cạnh nhau, mình bắt đầu thấy một câu chuyện khác:
Capital → Pricing → Liquidity → Collateral → Risk
Đó không còn chỉ là câu chuyện về một khoản vay.
Nó giống một nỗ lực xây dựng financial infrastructure có thể kết nối nhiều lớp của thị trường vốn on-chain.
Và đây cũng là điều mình thích nhất ở cách @TermMax tiếp cận vấn đề.
Họ không chỉ hỏi:
“Làm thế nào để người dùng vay?”
Mà dường như đang đặt những câu hỏi rộng hơn:
Làm thế nào để vốn có thể được định giá rõ ràng hơn?
Làm thế nào để tài sản tokenized có thêm utility?
Làm thế nào để liquidity được tổ chức quanh fixed-rate markets?
Và khi mọi thứ đi sai, hệ thống sẽ xử lý risk như thế nào?
Mình chưa nghĩ TermMax đã trả lời hoàn hảo tất cả những câu hỏi đó.
Nhưng sau 5 ngày tìm hiểu, mình nghĩ đó mới chính là lý do đáng để tiếp tục theo dõi.
Không phải vì TermMax có một feature nổi bật.
Mà vì các mảnh ghép bắt đầu trông giống một hệ thống.
#TermMax
Übersetzung ansehen
Hồi trước tôi từng nghĩ một hệ thống càng dễ audit thì càng phải công khai càng nhiều dữ liệu.
Nhưng càng tìm hiểu về tài chính, tôi càng thấy điều đó không hẳn đúng.
Hãy tưởng tượng một auditor cần kiểm tra một giao dịch tài sản:
Người tham gia có đủ điều kiện không?
Giao dịch có tuân thủ quy định không?
Tài sản có được chuyển đúng theo rule không?
Để trả lời những câu hỏi đó, họ cần evidence.
Nhưng điều đó không có nghĩa họ cần nhìn thấy toàn bộ số dư, lịch sử giao dịch hay thông tin riêng tư của tất cả participant.
Đó là lý do tôi thấy cách tiếp cận của @Dusk thú vị.
Với regulated assets, bài toán không đơn giản là:
“Dữ liệu có được công khai hay không?”
Mà là:
“Ai cần xác minh điều gì, và họ thực sự cần nhìn thấy bao nhiêu?”
Zero-knowledge proofs có thể giúp một bên chứng minh một điều kiện là đúng mà không cần tiết lộ toàn bộ dữ liệu phía sau.
Selective disclosure lại cho phép thông tin cần thiết được chia sẻ với đúng bên khi có lý do chính đáng.
Vì vậy, tôi nghĩ:
Auditability ≠ Full Transparency
Một hệ thống tài chính tốt không nhất thiết phải biến mọi dữ liệu thành public data để chứng minh nó đáng tin cậy.
Nó cần tạo ra đủ bằng chứng để được kiểm chứng, trong khi vẫn giữ lại phần dữ liệu không cần thiết phải lộ ra.
Đó có lẽ là một trong những điều quan trọng để privacy và compliance thực sự cùng tồn tại on-chain.
#dusk $DUSK
Nhưng càng tìm hiểu về tài chính, tôi càng thấy điều đó không hẳn đúng.
Hãy tưởng tượng một auditor cần kiểm tra một giao dịch tài sản:
Người tham gia có đủ điều kiện không?
Giao dịch có tuân thủ quy định không?
Tài sản có được chuyển đúng theo rule không?
Để trả lời những câu hỏi đó, họ cần evidence.
Nhưng điều đó không có nghĩa họ cần nhìn thấy toàn bộ số dư, lịch sử giao dịch hay thông tin riêng tư của tất cả participant.
Đó là lý do tôi thấy cách tiếp cận của @Dusk thú vị.
Với regulated assets, bài toán không đơn giản là:
“Dữ liệu có được công khai hay không?”
Mà là:
“Ai cần xác minh điều gì, và họ thực sự cần nhìn thấy bao nhiêu?”
Zero-knowledge proofs có thể giúp một bên chứng minh một điều kiện là đúng mà không cần tiết lộ toàn bộ dữ liệu phía sau.
Selective disclosure lại cho phép thông tin cần thiết được chia sẻ với đúng bên khi có lý do chính đáng.
Vì vậy, tôi nghĩ:
Auditability ≠ Full Transparency
Một hệ thống tài chính tốt không nhất thiết phải biến mọi dữ liệu thành public data để chứng minh nó đáng tin cậy.
Nó cần tạo ra đủ bằng chứng để được kiểm chứng, trong khi vẫn giữ lại phần dữ liệu không cần thiết phải lộ ra.
Đó có lẽ là một trong những điều quan trọng để privacy và compliance thực sự cùng tồn tại on-chain.
#dusk $DUSK
Übersetzung ansehen
Một điều mình nhận ra khi tìm hiểu TermMax:
Fixed-rate lending không chỉ cần người vay và người cho vay. Nó cần cả một thị trường để hình thành giá.
Ban đầu mình nghĩ lãi suất fixed đơn giản là một con số được giao thức đưa ra.
Nhưng nếu lãi suất có thể được khóa trong một khoảng thời gian cụ thể, thì lập tức xuất hiện một câu hỏi thú vị:
Ai quyết định mức rate đó là hợp lý?
Đây là lúc mình bắt đầu chú ý hơn đến Range Order của @TermMax .
Thay vì thanh khoản chỉ tập trung quanh một mức lãi suất duy nhất, Range Order cho phép liquidity được phân bổ theo các khoảng rate khác nhau.
Điều này khiến mình nhìn fixed-rate market theo một cách khác.
Lãi suất không chỉ là một con số để người vay nhìn vào.
Nó là một mức giá được thị trường khám phá và giao dịch.
Người cho vay có thể có mức yield mà họ muốn.
Người đi vay có mức borrowing cost mà họ chấp nhận.
Khoảng cách giữa hai bên chính là nơi market design trở nên quan trọng.
Và đây cũng là điểm mình thấy TermMax thú vị hơn một lending protocol thông thường.
Thay vì chỉ hỏi:
“Lãi suất hiện tại là bao nhiêu?”
Mình bắt đầu quan tâm hơn đến:
“Thị trường hình thành mức lãi suất đó như thế nào?”
Nếu fixed-rate lending muốn trở thành một lớp quan trọng của DeFi, việc tạo ra fixed rate có lẽ chưa đủ.
Nó còn cần một cơ chế đủ linh hoạt để price discovery và liquidity cùng tồn tại.
Đó là phần mình muốn tiếp tục đào sâu ở TermMax.
#TermMax
Fixed-rate lending không chỉ cần người vay và người cho vay. Nó cần cả một thị trường để hình thành giá.
Ban đầu mình nghĩ lãi suất fixed đơn giản là một con số được giao thức đưa ra.
Nhưng nếu lãi suất có thể được khóa trong một khoảng thời gian cụ thể, thì lập tức xuất hiện một câu hỏi thú vị:
Ai quyết định mức rate đó là hợp lý?
Đây là lúc mình bắt đầu chú ý hơn đến Range Order của @TermMax .
Thay vì thanh khoản chỉ tập trung quanh một mức lãi suất duy nhất, Range Order cho phép liquidity được phân bổ theo các khoảng rate khác nhau.
Điều này khiến mình nhìn fixed-rate market theo một cách khác.
Lãi suất không chỉ là một con số để người vay nhìn vào.
Nó là một mức giá được thị trường khám phá và giao dịch.
Người cho vay có thể có mức yield mà họ muốn.
Người đi vay có mức borrowing cost mà họ chấp nhận.
Khoảng cách giữa hai bên chính là nơi market design trở nên quan trọng.
Và đây cũng là điểm mình thấy TermMax thú vị hơn một lending protocol thông thường.
Thay vì chỉ hỏi:
“Lãi suất hiện tại là bao nhiêu?”
Mình bắt đầu quan tâm hơn đến:
“Thị trường hình thành mức lãi suất đó như thế nào?”
Nếu fixed-rate lending muốn trở thành một lớp quan trọng của DeFi, việc tạo ra fixed rate có lẽ chưa đủ.
Nó còn cần một cơ chế đủ linh hoạt để price discovery và liquidity cùng tồn tại.
Đó là phần mình muốn tiếp tục đào sâu ở TermMax.
#TermMax
Übersetzung ansehen
Kinh nghiệm nhiều không phải lúc nào cũng làm bạn an toàn hơn.
Đôi khi nó khiến bạn chủ quan hơn.
Hãy thử tưởng tượng một người đã giao dịch P2P hàng trăm lần.
Họ biết phải mở Order ở đâu.
Biết kiểm tra payment.
Biết khi nào không nên Release.
Những thao tác đó quen đến mức gần như thành phản xạ.
Và chính điều này mới đáng để suy nghĩ.
Khi làm một việc đủ nhiều lần, não bắt đầu tìm cách làm nó nhanh hơn.
Bạn không còn đọc từng chi tiết.
Bạn nhìn qua một vài thông tin quen thuộc, thấy mọi thứ giống như bình thường, rồi tiếp tục.
Trong phần lớn các Order, điều đó có thể không gây ra vấn đề gì.
Nhưng chỉ cần một Order có một chi tiết khác với thói quen, phản xạ cũ có thể khiến bạn bỏ qua nó.
Một payment method khác.
Một tài khoản thanh toán khác.
Hoặc đơn giản là một điều kiện trong Order không giống những lần trước.
Điều đáng sợ là người có kinh nghiệm không phải lúc nào cũng nhận ra mình đang chủ quan.
Vì họ không nghĩ:
“Mình đang bỏ qua bước kiểm tra.”
Họ nghĩ:
“Mình làm việc này quá nhiều rồi.”
Vì vậy, mình có một nguyên tắc khá đơn giản khi giao dịch P2P:
Kinh nghiệm nên giúp mình nhận ra điều bất thường nhanh hơn, chứ không phải giúp mình kiểm tra ít hơn.
Mỗi Order vẫn có những điều kiện riêng.
Mỗi payment vẫn cần được đối chiếu.
Và mỗi lần Release vẫn phải dựa trên thông tin của chính giao dịch đó.
Có thể điều khó nhất của việc giao dịch lâu năm không phải là học thêm một quy tắc.
Mà là nhận ra lúc nào kinh nghiệm đang giúp mình và lúc nào nó đã biến thành thói quen.
Biết quy trình là lợi thế.
Nhưng vẫn thực sự nhìn vào từng Order mới là sự an toàn.
@Binance Vietnam #BinanceP2PAnToan
Đôi khi nó khiến bạn chủ quan hơn.
Hãy thử tưởng tượng một người đã giao dịch P2P hàng trăm lần.
Họ biết phải mở Order ở đâu.
Biết kiểm tra payment.
Biết khi nào không nên Release.
Những thao tác đó quen đến mức gần như thành phản xạ.
Và chính điều này mới đáng để suy nghĩ.
Khi làm một việc đủ nhiều lần, não bắt đầu tìm cách làm nó nhanh hơn.
Bạn không còn đọc từng chi tiết.
Bạn nhìn qua một vài thông tin quen thuộc, thấy mọi thứ giống như bình thường, rồi tiếp tục.
Trong phần lớn các Order, điều đó có thể không gây ra vấn đề gì.
Nhưng chỉ cần một Order có một chi tiết khác với thói quen, phản xạ cũ có thể khiến bạn bỏ qua nó.
Một payment method khác.
Một tài khoản thanh toán khác.
Hoặc đơn giản là một điều kiện trong Order không giống những lần trước.
Điều đáng sợ là người có kinh nghiệm không phải lúc nào cũng nhận ra mình đang chủ quan.
Vì họ không nghĩ:
“Mình đang bỏ qua bước kiểm tra.”
Họ nghĩ:
“Mình làm việc này quá nhiều rồi.”
Vì vậy, mình có một nguyên tắc khá đơn giản khi giao dịch P2P:
Kinh nghiệm nên giúp mình nhận ra điều bất thường nhanh hơn, chứ không phải giúp mình kiểm tra ít hơn.
Mỗi Order vẫn có những điều kiện riêng.
Mỗi payment vẫn cần được đối chiếu.
Và mỗi lần Release vẫn phải dựa trên thông tin của chính giao dịch đó.
Có thể điều khó nhất của việc giao dịch lâu năm không phải là học thêm một quy tắc.
Mà là nhận ra lúc nào kinh nghiệm đang giúp mình và lúc nào nó đã biến thành thói quen.
Biết quy trình là lợi thế.
Nhưng vẫn thực sự nhìn vào từng Order mới là sự an toàn.
@Binance Vietnam #BinanceP2PAnToan
Übersetzung ansehen
Hồi còn đi làm, tôi từng sử dụng một hệ thống chấm công mà mỗi nhân viên chỉ có thể truy cập những chức năng phù hợp với vị trí của mình.
Lúc đầu tôi nghĩ đó chỉ là một cách để công ty kiểm soát quyền truy cập.
Nhưng sau này tôi nhận ra, một hệ thống tốt không phải là hệ thống cho phép hoặc từ chối tất cả mọi thứ.
Nó phải biết ai cần quyền gì, và cần quyền đó ở mức nào.
Điều này khiến tôi nghĩ đến @Dusk
Khi tài sản tài chính được đưa lên-chain, vấn đề cũng không chỉ là xác định ai đang sở hữu tài sản.
Hệ thống còn phải biết ai đủ điều kiện sở hữu, ai được phép nhận hoặc chuyển tài sản, và bên nào thực sự cần được xác minh thông tin đó.
Thay vì biến mọi dữ liệu thành thông tin mà tất cả participant đều có thể nhìn thấy, selective disclosure và zero-knowledge proofs có thể giúp một bên chứng minh điều cần thiết mà không phải tiết lộ toàn bộ dữ liệu phía sau.
Tôi nghĩ điều này đặc biệt quan trọng với regulated finance.
Một nhà đầu tư có thể cần chứng minh mình đủ điều kiện mua một tài sản.
Nhưng điều đó không có nghĩa mọi bên trong transaction cần biết toàn bộ danh tính, tài sản hay lịch sử tài chính của người đó.
Cùng một dữ liệu, nhưng không phải ai cũng cần cùng một mức độ truy cập.
Đó là điều tôi thấy thú vị khi tìm hiểu Dusk:
Một hệ thống tài chính tốt không phải là nơi mọi thứ đều được giấu kín.
Cũng không phải nơi mọi thứ đều được công khai.
Mà là nơi đúng người có thể xác minh đúng thông tin, vào đúng thời điểm, với lượng dữ liệu cần thiết.
Có lẽ đó mới là cách privacy và compliance có thể cùng tồn tại trên-chain.
#dusk $DUSK
Lúc đầu tôi nghĩ đó chỉ là một cách để công ty kiểm soát quyền truy cập.
Nhưng sau này tôi nhận ra, một hệ thống tốt không phải là hệ thống cho phép hoặc từ chối tất cả mọi thứ.
Nó phải biết ai cần quyền gì, và cần quyền đó ở mức nào.
Điều này khiến tôi nghĩ đến @Dusk
Khi tài sản tài chính được đưa lên-chain, vấn đề cũng không chỉ là xác định ai đang sở hữu tài sản.
Hệ thống còn phải biết ai đủ điều kiện sở hữu, ai được phép nhận hoặc chuyển tài sản, và bên nào thực sự cần được xác minh thông tin đó.
Thay vì biến mọi dữ liệu thành thông tin mà tất cả participant đều có thể nhìn thấy, selective disclosure và zero-knowledge proofs có thể giúp một bên chứng minh điều cần thiết mà không phải tiết lộ toàn bộ dữ liệu phía sau.
Tôi nghĩ điều này đặc biệt quan trọng với regulated finance.
Một nhà đầu tư có thể cần chứng minh mình đủ điều kiện mua một tài sản.
Nhưng điều đó không có nghĩa mọi bên trong transaction cần biết toàn bộ danh tính, tài sản hay lịch sử tài chính của người đó.
Cùng một dữ liệu, nhưng không phải ai cũng cần cùng một mức độ truy cập.
Đó là điều tôi thấy thú vị khi tìm hiểu Dusk:
Một hệ thống tài chính tốt không phải là nơi mọi thứ đều được giấu kín.
Cũng không phải nơi mọi thứ đều được công khai.
Mà là nơi đúng người có thể xác minh đúng thông tin, vào đúng thời điểm, với lượng dữ liệu cần thiết.
Có lẽ đó mới là cách privacy và compliance có thể cùng tồn tại trên-chain.
#dusk $DUSK
Übersetzung ansehen
Liquidation không chỉ là điểm kết thúc của một vị thế.
Đây là phần mình bắt đầu chú ý hơn khi tìm hiểu @TermMax .
Trong DeFi, khi một vị thế không còn đủ an toàn, liquidation thường được nhìn khá đơn giản:
Collateral giảm → vị thế bị thanh lý → người vay chịu thiệt hại.
Nhưng mình nghĩ câu hỏi thú vị hơn là:
Sau khi liquidation xảy ra, chuyện gì thực sự được xử lý?
Đó là lý do mình muốn tìm hiểu sâu hơn về cơ chế Physical Delivery Liquidation của TermMax.
Thay vì chỉ xem liquidation như một nút “đóng vị thế”, TermMax thiết kế cơ chế này xoay quanh việc xử lý thực tế mối quan hệ giữa collateral và debt.
Điều này khiến mình nhìn liquidation dưới một góc khác.
Một thị trường lending không chỉ cần cơ chế để mở vị thế.
Nó còn cần một cơ chế đủ rõ ràng cho thời điểm thị trường đi ngược lại kỳ vọng.
Đặc biệt khi có leverage, câu hỏi không còn đơn giản là:
“Bạn có thể kiếm được bao nhiêu?”
Mà còn là:
“Nếu mọi thứ diễn biến xấu, hệ thống sẽ xử lý vị thế đó như thế nào?”
Đây cũng là điểm mình thấy đáng nghiên cứu ở TermMax.
Fixed-rate giải quyết một phần vấn đề về chi phí vốn.
RWA mở thêm nguồn collateral.
Nhưng liquidation mechanism mới là nơi mình muốn hiểu rõ cách toàn bộ cấu trúc đó chịu được stress của thị trường.
Mình chưa nghĩ mình đã hiểu hết Physical Delivery Liquidation.
Và có lẽ đó mới là phần thú vị nhất.
Vì một giao thức tài chính đáng để nghiên cứu không chỉ nằm ở cách nó tạo ra lợi nhuận trong thị trường tốt.
Mà còn ở cách nó xử lý khi thị trường không đi theo kế hoạch.
#TermMax
Đây là phần mình bắt đầu chú ý hơn khi tìm hiểu @TermMax .
Trong DeFi, khi một vị thế không còn đủ an toàn, liquidation thường được nhìn khá đơn giản:
Collateral giảm → vị thế bị thanh lý → người vay chịu thiệt hại.
Nhưng mình nghĩ câu hỏi thú vị hơn là:
Sau khi liquidation xảy ra, chuyện gì thực sự được xử lý?
Đó là lý do mình muốn tìm hiểu sâu hơn về cơ chế Physical Delivery Liquidation của TermMax.
Thay vì chỉ xem liquidation như một nút “đóng vị thế”, TermMax thiết kế cơ chế này xoay quanh việc xử lý thực tế mối quan hệ giữa collateral và debt.
Điều này khiến mình nhìn liquidation dưới một góc khác.
Một thị trường lending không chỉ cần cơ chế để mở vị thế.
Nó còn cần một cơ chế đủ rõ ràng cho thời điểm thị trường đi ngược lại kỳ vọng.
Đặc biệt khi có leverage, câu hỏi không còn đơn giản là:
“Bạn có thể kiếm được bao nhiêu?”
Mà còn là:
“Nếu mọi thứ diễn biến xấu, hệ thống sẽ xử lý vị thế đó như thế nào?”
Đây cũng là điểm mình thấy đáng nghiên cứu ở TermMax.
Fixed-rate giải quyết một phần vấn đề về chi phí vốn.
RWA mở thêm nguồn collateral.
Nhưng liquidation mechanism mới là nơi mình muốn hiểu rõ cách toàn bộ cấu trúc đó chịu được stress của thị trường.
Mình chưa nghĩ mình đã hiểu hết Physical Delivery Liquidation.
Và có lẽ đó mới là phần thú vị nhất.
Vì một giao thức tài chính đáng để nghiên cứu không chỉ nằm ở cách nó tạo ra lợi nhuận trong thị trường tốt.
Mà còn ở cách nó xử lý khi thị trường không đi theo kế hoạch.
#TermMax
Übersetzung ansehen
Có một kiểu chủ quan trong P2P mà mình nghĩ nhiều anh em không để ý.
Nó không bắt đầu bằng một người mua đáng ngờ.
Mà bắt đầu bằng một giao dịch quá suôn sẻ.
Bạn vừa giao dịch với một người.
Thanh toán đúng số tiền.
Tên tài khoản khớp.
Không có vấn đề gì.
Order hoàn tất bình thường.
Một lúc sau, bạn mở thêm một Order khác với cùng người đó.
Và trong đầu tự nhiên xuất hiện:
“Người này vừa giao dịch với mình rồi, chắc lần này cũng ổn.”
Nghe rất hợp lý.
Nhưng chính suy nghĩ đó mới là thứ mình muốn cẩn thận.
Vì giao dịch trước và giao dịch hiện tại vẫn là hai Order khác nhau.
Mình vẫn phải kiểm tra lại:
🟢 Thông tin của Order hiện tại có đúng không?
🟢 Số tiền và phương thức thanh toán có khớp không?
🟢 Tài khoản thanh toán của giao dịch này có đúng với điều kiện hiện tại không?
Không phải vì người kia đã từng làm đúng thì lần này chắc chắn có vấn đề.
Mà vì lịch sử giao dịch tốt không phải là bằng chứng cho một giao dịch mới.
Đây cũng là lý do mình không muốn để sự quen thuộc thay thế cho việc kiểm tra.
Một người có thể hoàn thành 10 Order trước đó hoàn toàn bình thường.
Nhưng Order thứ 11 vẫn là một giao dịch mới.
Với mình, đây là một nguyên tắc khá đơn giản:
Đừng chuyển sự tin tưởng từ giao dịch cũ sang giao dịch mới.
Hãy chuyển dữ liệu của giao dịch mới vào bước kiểm tra.
P2P an toàn đôi khi không phải là nhận ra một người đáng ngờ.
Mà là nhận ra lúc nào mình đang quá yên tâm chỉ vì mọi thứ trước đó đã diễn ra tốt đẹp.
@Binance Vietnam #BinanceP2PAnToan $BNB
Nó không bắt đầu bằng một người mua đáng ngờ.
Mà bắt đầu bằng một giao dịch quá suôn sẻ.
Bạn vừa giao dịch với một người.
Thanh toán đúng số tiền.
Tên tài khoản khớp.
Không có vấn đề gì.
Order hoàn tất bình thường.
Một lúc sau, bạn mở thêm một Order khác với cùng người đó.
Và trong đầu tự nhiên xuất hiện:
“Người này vừa giao dịch với mình rồi, chắc lần này cũng ổn.”
Nghe rất hợp lý.
Nhưng chính suy nghĩ đó mới là thứ mình muốn cẩn thận.
Vì giao dịch trước và giao dịch hiện tại vẫn là hai Order khác nhau.
Mình vẫn phải kiểm tra lại:
🟢 Thông tin của Order hiện tại có đúng không?
🟢 Số tiền và phương thức thanh toán có khớp không?
🟢 Tài khoản thanh toán của giao dịch này có đúng với điều kiện hiện tại không?
Không phải vì người kia đã từng làm đúng thì lần này chắc chắn có vấn đề.
Mà vì lịch sử giao dịch tốt không phải là bằng chứng cho một giao dịch mới.
Đây cũng là lý do mình không muốn để sự quen thuộc thay thế cho việc kiểm tra.
Một người có thể hoàn thành 10 Order trước đó hoàn toàn bình thường.
Nhưng Order thứ 11 vẫn là một giao dịch mới.
Với mình, đây là một nguyên tắc khá đơn giản:
Đừng chuyển sự tin tưởng từ giao dịch cũ sang giao dịch mới.
Hãy chuyển dữ liệu của giao dịch mới vào bước kiểm tra.
P2P an toàn đôi khi không phải là nhận ra một người đáng ngờ.
Mà là nhận ra lúc nào mình đang quá yên tâm chỉ vì mọi thứ trước đó đã diễn ra tốt đẹp.
@Binance Vietnam #BinanceP2PAnToan $BNB
Übersetzung ansehen
Tôi từng nghĩ RWA về cơ bản chỉ là đưa một tài sản thật lên blockchain.
Sau khi tìm hiểu kỹ hơn về Dusk, tôi bắt đầu nghĩ rằng giả định đó quá đơn giản.
Một tài sản tài chính không chỉ có giá trị.
Ai được phép sở hữu?
Ai có thể nhận nó?
Khi nào nó được chuyển nhượng?
Điều gì xảy ra khi quyền sở hữu thay đổi?
Và ai được phép thực hiện những hành động đó?
Nếu những quy tắc này vẫn nằm ngoài blockchain, thì việc tạo ra một token có thực sự đưa tài sản vào on-chain không?
Đây là phần khiến tôi chú ý ở @Dusk
Dusk không chỉ tiếp cận RWA từ góc độ tokenization. Với native issuance, ý tưởng thú vị hơn là đưa nhiều hơn vòng đời và logic của tài sản trực tiếp vào hạ tầng on-chain.
Điều đó có nghĩa blockchain không chỉ ghi nhận rằng:
“Đây là token của một trái phiếu.”
Mà còn có thể trở thành nơi các điều kiện liên quan đến ownership, transfer và các hoạt động của tài sản được xử lý theo những rules đã được xác định.
Đặc biệt với regulated assets, đây có thể là khác biệt quan trọng.
Một trái phiếu không trở thành permissionless chỉ vì nó có token.
Các yêu cầu về eligibility, transfer restrictions và compliance vẫn đi cùng tài sản.
Vì vậy, câu hỏi tôi đang suy nghĩ không còn là:
“Làm thế nào để token hóa một tài sản?”
Mà là:
“Làm thế nào để tài sản mang theo các quy tắc của chính nó khi bước vào blockchain?”
Có lẽ đó mới là phần khó nhất của RWA.
Tokenization tạo ra một representation.
Nhưng nếu blockchain có thể hiểu và thực thi asset logic, chúng ta mới bắt đầu nói về một hệ thống tài chính on-chain thực sự.
Đó là phần Dusk tôi đang muốn tìm hiểu sâu hơn.
#dusk $DUSK
Sau khi tìm hiểu kỹ hơn về Dusk, tôi bắt đầu nghĩ rằng giả định đó quá đơn giản.
Một tài sản tài chính không chỉ có giá trị.
Ai được phép sở hữu?
Ai có thể nhận nó?
Khi nào nó được chuyển nhượng?
Điều gì xảy ra khi quyền sở hữu thay đổi?
Và ai được phép thực hiện những hành động đó?
Nếu những quy tắc này vẫn nằm ngoài blockchain, thì việc tạo ra một token có thực sự đưa tài sản vào on-chain không?
Đây là phần khiến tôi chú ý ở @Dusk
Dusk không chỉ tiếp cận RWA từ góc độ tokenization. Với native issuance, ý tưởng thú vị hơn là đưa nhiều hơn vòng đời và logic của tài sản trực tiếp vào hạ tầng on-chain.
Điều đó có nghĩa blockchain không chỉ ghi nhận rằng:
“Đây là token của một trái phiếu.”
Mà còn có thể trở thành nơi các điều kiện liên quan đến ownership, transfer và các hoạt động của tài sản được xử lý theo những rules đã được xác định.
Đặc biệt với regulated assets, đây có thể là khác biệt quan trọng.
Một trái phiếu không trở thành permissionless chỉ vì nó có token.
Các yêu cầu về eligibility, transfer restrictions và compliance vẫn đi cùng tài sản.
Vì vậy, câu hỏi tôi đang suy nghĩ không còn là:
“Làm thế nào để token hóa một tài sản?”
Mà là:
“Làm thế nào để tài sản mang theo các quy tắc của chính nó khi bước vào blockchain?”
Có lẽ đó mới là phần khó nhất của RWA.
Tokenization tạo ra một representation.
Nhưng nếu blockchain có thể hiểu và thực thi asset logic, chúng ta mới bắt đầu nói về một hệ thống tài chính on-chain thực sự.
Đó là phần Dusk tôi đang muốn tìm hiểu sâu hơn.
#dusk $DUSK
Übersetzung ansehen
Tokenizing a stock is not the finish line. It’s the starting line.
Mình nghĩ đây là phần thú vị nhất của câu chuyện RWA.
Khi một cổ phiếu được token hóa, nó đã có thể xuất hiện on-chain. Nhưng nếu nó chỉ được “đưa lên blockchain” rồi nằm đó, utility của nó vẫn khá hạn chế.
Câu hỏi quan trọng hơn là:
Sau khi được token hóa, tài sản đó có thể làm được gì?
Đây là lý do mình chú ý đến cách @TermMax tiếp cận RWA.
TermMax đang mở rộng để các chứng khoán được token hóa của Ondo Global Markets có thể trở thành tài sản thế chấp cho khoản vay fixed-rate trên BNB Chain.
Và điều này tạo ra một chuỗi khá thú vị:
Tokenized stock → Collateral → Liquidity → Predictable borrowing cost
Thay vì chỉ sở hữu một phiên bản on-chain của tài sản truyền thống, người dùng có thêm một cách để khai thác giá trị vốn của tài sản đó mà vẫn biết trước chi phí vay.
Điểm mình thấy đáng chú ý ở đây không phải đơn giản là “RWA + DeFi”.
Mà là:
Tokenization tạo ra representation.
Financial infrastructure tạo ra utility.
Nếu RWA muốn tiến xa hơn việc đưa tài sản truyền thống lên blockchain, chúng cần những lớp cơ sở hạ tầng giúp chúng thực sự tham gia vào các hoạt động tài chính on-chain.
Và fixed-rate lending là một trong những mảnh ghép đáng chú ý đó.
Đó cũng là lý do mình nghĩ TermMax đang đứng ở một giao điểm khá thú vị giữa RWA, fixed-income và Defi.
#termmax
Mình nghĩ đây là phần thú vị nhất của câu chuyện RWA.
Khi một cổ phiếu được token hóa, nó đã có thể xuất hiện on-chain. Nhưng nếu nó chỉ được “đưa lên blockchain” rồi nằm đó, utility của nó vẫn khá hạn chế.
Câu hỏi quan trọng hơn là:
Sau khi được token hóa, tài sản đó có thể làm được gì?
Đây là lý do mình chú ý đến cách @TermMax tiếp cận RWA.
TermMax đang mở rộng để các chứng khoán được token hóa của Ondo Global Markets có thể trở thành tài sản thế chấp cho khoản vay fixed-rate trên BNB Chain.
Và điều này tạo ra một chuỗi khá thú vị:
Tokenized stock → Collateral → Liquidity → Predictable borrowing cost
Thay vì chỉ sở hữu một phiên bản on-chain của tài sản truyền thống, người dùng có thêm một cách để khai thác giá trị vốn của tài sản đó mà vẫn biết trước chi phí vay.
Điểm mình thấy đáng chú ý ở đây không phải đơn giản là “RWA + DeFi”.
Mà là:
Tokenization tạo ra representation.
Financial infrastructure tạo ra utility.
Nếu RWA muốn tiến xa hơn việc đưa tài sản truyền thống lên blockchain, chúng cần những lớp cơ sở hạ tầng giúp chúng thực sự tham gia vào các hoạt động tài chính on-chain.
Và fixed-rate lending là một trong những mảnh ghép đáng chú ý đó.
Đó cũng là lý do mình nghĩ TermMax đang đứng ở một giao điểm khá thú vị giữa RWA, fixed-income và Defi.
#termmax
Übersetzung ansehen
Đang giao dịch bình thường mà đối phương tự nhiên đổi cách thanh toán?
Đây là kiểu tình huống mình nghĩ anh em P2P rất dễ chủ quan.
Order đã đặt.
Thông tin đã kiểm tra.
Hai bên đang giao dịch bình thường.
Xong đối phương nhắn:
“Tài khoản này đang lỗi, anh chuyển sang tài khoản khác giúp em nhé.”
Nghe thì khá hợp lý.
Nhưng vấn đề nằm ở chỗ: điều kiện giao dịch ban đầu đã thay đổi.
Và đây là lúc mình sẽ không vội làm tiếp chỉ vì trước đó mọi thứ vẫn ổn.
Một giao dịch đang bình thường không có nghĩa mọi thay đổi giữa chừng đều an toàn.
Mình sẽ dừng lại và kiểm tra lại:
🟢 Thông tin thanh toán có còn đúng với Order không?
🟢 Tên tài khoản nhận/chuyển có khớp với thông tin giao dịch không?
🟢 Đối phương có đang yêu cầu mình thực hiện một bước khác với điều kiện ban đầu không?
Nếu có thay đổi bất thường, đừng vì nghĩ:
“Nãy giờ vẫn giao dịch bình thường mà.”
mà bỏ qua.
Đặc biệt, đừng tự ý chuyển sang Zalo/Telegram hoặc thực hiện thanh toán theo một thông tin mới chỉ vì đối phương thúc giục.
Giữ giao dịch trong Order, giữ lịch sử chat và nếu có vấn đề thì dùng Appeal để Binance có đầy đủ thông tin đối chiếu.
Mình thấy P2P có một cái bẫy khá dễ gặp:
Cái nguy hiểm không phải lúc nào cũng xuất hiện ngay từ đầu.
Đôi khi giao dịch hoàn toàn bình thường…
cho đến khi một chi tiết nhỏ bị thay đổi.
Vì vậy:
Giao dịch đang bình thường ≠ có thể bỏ qua thay đổi giữa chừng.
Thấy thay đổi → dừng lại → kiểm tra lại → rồi mới quyết định.
Chậm vài giây để xác nhận vẫn tốt hơn nhanh vài giây rồi phải xử lý hậu quả.
#BinanceP2PAnToan @Binance Vietnam $BNB
Đây là kiểu tình huống mình nghĩ anh em P2P rất dễ chủ quan.
Order đã đặt.
Thông tin đã kiểm tra.
Hai bên đang giao dịch bình thường.
Xong đối phương nhắn:
“Tài khoản này đang lỗi, anh chuyển sang tài khoản khác giúp em nhé.”
Nghe thì khá hợp lý.
Nhưng vấn đề nằm ở chỗ: điều kiện giao dịch ban đầu đã thay đổi.
Và đây là lúc mình sẽ không vội làm tiếp chỉ vì trước đó mọi thứ vẫn ổn.
Một giao dịch đang bình thường không có nghĩa mọi thay đổi giữa chừng đều an toàn.
Mình sẽ dừng lại và kiểm tra lại:
🟢 Thông tin thanh toán có còn đúng với Order không?
🟢 Tên tài khoản nhận/chuyển có khớp với thông tin giao dịch không?
🟢 Đối phương có đang yêu cầu mình thực hiện một bước khác với điều kiện ban đầu không?
Nếu có thay đổi bất thường, đừng vì nghĩ:
“Nãy giờ vẫn giao dịch bình thường mà.”
mà bỏ qua.
Đặc biệt, đừng tự ý chuyển sang Zalo/Telegram hoặc thực hiện thanh toán theo một thông tin mới chỉ vì đối phương thúc giục.
Giữ giao dịch trong Order, giữ lịch sử chat và nếu có vấn đề thì dùng Appeal để Binance có đầy đủ thông tin đối chiếu.
Mình thấy P2P có một cái bẫy khá dễ gặp:
Cái nguy hiểm không phải lúc nào cũng xuất hiện ngay từ đầu.
Đôi khi giao dịch hoàn toàn bình thường…
cho đến khi một chi tiết nhỏ bị thay đổi.
Vì vậy:
Giao dịch đang bình thường ≠ có thể bỏ qua thay đổi giữa chừng.
Thấy thay đổi → dừng lại → kiểm tra lại → rồi mới quyết định.
Chậm vài giây để xác nhận vẫn tốt hơn nhanh vài giây rồi phải xử lý hậu quả.
#BinanceP2PAnToan @Binance Vietnam $BNB
Ein Freund von mir hatte mich einmal eine ziemlich einfache Frage gestellt:
„Wenn ich einen Anteil an einem Unternehmen besitze, warum kann ich ihn dann nicht an jeden verkaufen?“
Auf den ersten Blick scheint diese Frage durchaus sinnvoll.
Wenn ein Vermögenswert dein Eigentum ist, dann verkaufst du ihn an jemanden, den du willst.
Aber bei Anteilen an einem privaten Unternehmen ist das nicht so einfach.
Einige Anteile werden nur an zugelassene Investoren übertragen.
Dabei wurde mir etwas klar:
Eigentum bedeutet nicht immer gleich uneingeschränkte Übertragbarkeit.
Das brachte mich dazu, an @Dusk zu denken.
Ich fand es interessant, wie sie mit verwalteten Finanzanlagen umgehen.
Ein On-Chain-Vermögenswert muss nicht nur wissen, wer ihn besitzt. Das System muss auch wissen, wer berechtigt ist, ihn zu besitzen, wer berechtigt ist, ihn zu erhalten, und welche Transaktionen blockiert werden müssen.
Dusk kann Identity Credentials, Wallet-Bindung und Smart-Contract-Logik kombinieren, um Regeln für Eigentum und Übertragung anzuwenden. Gleichzeitig ermöglicht „Selective Disclosure“, dass eine bevollmächtigte Partei die notwendigen Informationen verifizieren kann, ohne zwangsläufig die gesamten Nutzerdaten sehen zu müssen.
Ich denke, das ist ein sehr wichtiger Punkt, wenn RWA beginnt, mit DeFi zu verbinden.
Eine Anleihe wird nicht deshalb permissionless, weil sie auf eine Blockchain gestellt wird.
Die Regeln, die zum Vermögenswert gehören, müssen mit ihm einhergehen.
Vielleicht wird die Zukunft so aussehen: Vermögenswerte haben weiterhin Regeln – aber diese Regeln werden direkt im On-Chain-Workflow durchgesetzt.
Für mich ist das der bemerkenswerte Fortschritt des regulierten Finanzwesens.
Nicht nur Eigentum on-chain stellen.
Sondern Eigentum, Berechtigung, Übertragungsbeschränkungen und Privatsphäre in ein einziges, verifizierbares System bringen.
#dusk $DUSK
„Wenn ich einen Anteil an einem Unternehmen besitze, warum kann ich ihn dann nicht an jeden verkaufen?“
Auf den ersten Blick scheint diese Frage durchaus sinnvoll.
Wenn ein Vermögenswert dein Eigentum ist, dann verkaufst du ihn an jemanden, den du willst.
Aber bei Anteilen an einem privaten Unternehmen ist das nicht so einfach.
Einige Anteile werden nur an zugelassene Investoren übertragen.
Dabei wurde mir etwas klar:
Eigentum bedeutet nicht immer gleich uneingeschränkte Übertragbarkeit.
Das brachte mich dazu, an @Dusk zu denken.
Ich fand es interessant, wie sie mit verwalteten Finanzanlagen umgehen.
Ein On-Chain-Vermögenswert muss nicht nur wissen, wer ihn besitzt. Das System muss auch wissen, wer berechtigt ist, ihn zu besitzen, wer berechtigt ist, ihn zu erhalten, und welche Transaktionen blockiert werden müssen.
Dusk kann Identity Credentials, Wallet-Bindung und Smart-Contract-Logik kombinieren, um Regeln für Eigentum und Übertragung anzuwenden. Gleichzeitig ermöglicht „Selective Disclosure“, dass eine bevollmächtigte Partei die notwendigen Informationen verifizieren kann, ohne zwangsläufig die gesamten Nutzerdaten sehen zu müssen.
Ich denke, das ist ein sehr wichtiger Punkt, wenn RWA beginnt, mit DeFi zu verbinden.
Eine Anleihe wird nicht deshalb permissionless, weil sie auf eine Blockchain gestellt wird.
Die Regeln, die zum Vermögenswert gehören, müssen mit ihm einhergehen.
Vielleicht wird die Zukunft so aussehen: Vermögenswerte haben weiterhin Regeln – aber diese Regeln werden direkt im On-Chain-Workflow durchgesetzt.
Für mich ist das der bemerkenswerte Fortschritt des regulierten Finanzwesens.
Nicht nur Eigentum on-chain stellen.
Sondern Eigentum, Berechtigung, Übertragungsbeschränkungen und Privatsphäre in ein einziges, verifizierbares System bringen.
#dusk $DUSK
Übersetzung ansehen
Minh là một freelancer vừa nhận được một hợp đồng lớn.
Khách hàng sẽ thanh toán sau 6 tháng, nhưng để bắt đầu dự án, Minh cần khoảng $10,000 để mua thiết bị và thuê thêm người.
Nếu lãi suất vay thay đổi liên tục, Minh không biết chính xác chi phí vốn của mình sẽ là bao nhiêu khi dự án kết thúc.
Đây chính là điều khiến mình chú ý đến @TermMax
Điểm cốt lõi của TermMax khá đơn giản: fixed-rate lending và fixed-term borrowing.
Thay vì hoàn toàn phụ thuộc vào lãi suất thả nổi, người vay có thể biết trước mức lãi suất và kỳ hạn của vị thế.
Với Minh, điều này tạo ra một khác biệt rất thực tế:
Không phải cố đoán lãi suất sẽ đi đâu trong 6 tháng tới.
Mà có thể lập kế hoạch chi phí vốn ngay từ khi bắt đầu.
Nhưng điều thú vị là TermMax không chỉ đơn giản đưa fixed rate vào DeFi.
Nó xây dựng cả một lớp hạ tầng xung quanh fixed-rate market:
FT và XT giúp cấu trúc các khoản nợ có kỳ hạn cố định.
Range Order cho phép thanh khoản được phân bổ theo các phạm vi lãi suất khác nhau, thay vì chỉ phụ thuộc vào một mức rate duy nhất.
Các cơ chế như Smart Unwind và Order Aggregator hướng tới việc cải thiện khả năng thoát vị thế và tối ưu nguồn thanh khoản.
Đó là lý do mình không nhìn TermMax đơn thuần như một lending protocol khác.
Điểm đáng chú ý hơn là cách nó đưa sự có thể dự đoán của fixed income vào DeFi.
Nhưng khi dòng vốn lớn hơn bước vào, một câu hỏi khác xuất hiện:
Chi phí vốn có thể dự đoán được không?
Nếu câu trả lời là có, fixed-rate lending không chỉ là một sản phẩm.
Nó có thể trở thành một primitive quan trọng cho thị trường tín dụng on-chain.
Và đó là lý do mình sẽ theo dõi TermMax kỹ hơn trong 5 ngày tới.
#TermMax
Khách hàng sẽ thanh toán sau 6 tháng, nhưng để bắt đầu dự án, Minh cần khoảng $10,000 để mua thiết bị và thuê thêm người.
Nếu lãi suất vay thay đổi liên tục, Minh không biết chính xác chi phí vốn của mình sẽ là bao nhiêu khi dự án kết thúc.
Đây chính là điều khiến mình chú ý đến @TermMax
Điểm cốt lõi của TermMax khá đơn giản: fixed-rate lending và fixed-term borrowing.
Thay vì hoàn toàn phụ thuộc vào lãi suất thả nổi, người vay có thể biết trước mức lãi suất và kỳ hạn của vị thế.
Với Minh, điều này tạo ra một khác biệt rất thực tế:
Không phải cố đoán lãi suất sẽ đi đâu trong 6 tháng tới.
Mà có thể lập kế hoạch chi phí vốn ngay từ khi bắt đầu.
Nhưng điều thú vị là TermMax không chỉ đơn giản đưa fixed rate vào DeFi.
Nó xây dựng cả một lớp hạ tầng xung quanh fixed-rate market:
FT và XT giúp cấu trúc các khoản nợ có kỳ hạn cố định.
Range Order cho phép thanh khoản được phân bổ theo các phạm vi lãi suất khác nhau, thay vì chỉ phụ thuộc vào một mức rate duy nhất.
Các cơ chế như Smart Unwind và Order Aggregator hướng tới việc cải thiện khả năng thoát vị thế và tối ưu nguồn thanh khoản.
Đó là lý do mình không nhìn TermMax đơn thuần như một lending protocol khác.
Điểm đáng chú ý hơn là cách nó đưa sự có thể dự đoán của fixed income vào DeFi.
Nhưng khi dòng vốn lớn hơn bước vào, một câu hỏi khác xuất hiện:
Chi phí vốn có thể dự đoán được không?
Nếu câu trả lời là có, fixed-rate lending không chỉ là một sản phẩm.
Nó có thể trở thành một primitive quan trọng cho thị trường tín dụng on-chain.
Và đó là lý do mình sẽ theo dõi TermMax kỹ hơn trong 5 ngày tới.
#TermMax
Es gibt einen Fehler im P2P, den ich für gefährlich halte, gerade weil er nicht mit einem gefälschten Geldbetrag beginnt.
Das Geld ist echt.
Aber du ordnest diesen Betrag der falschen Order zu.
Ich bin einmal in einer ähnlichen Situation gelandet, als ich zwei Zahlungen kurz hintereinander verarbeitet habe. Beide tauchten im Konto auf, und weil der eine gerade als erstes vor Augen war, war die erste Reaktion: „Das ist bestimmt die Zahlung zu meiner offenen Order.“
Aber als ich zurückblickte, merkte ich, dass ich mich auf etwas stütze, das extrem leicht zu verwechseln ist:
Das Gedächtnis.
Ich erinnere mich daran, welche Order ich gerade erstellt hatte, wie viel Geld und welcher Betrag eigentlich als erstes hätte ankommen sollen.
Das hat mich dazu gebracht, meine Art zu überdenken, wie ich eine Transaktion bei Binance P2P prüfe.
Wenn mehrere Orders oder mehrere Überweisungen in kurzer Zeit parallel laufen, frage ich nicht nur:
„Ist das Geld schon da?“
Ich frage auch:
„Welcher Order gehört genau dieser Geldbetrag?“
Ich gleichen die Order, an der ich gerade arbeite, mit dem tatsächlich erhaltenen Betrag, den Angaben des Absenders und den Details der Zahlung ab. Wenn ich die Verbindung zwischen dem Geldbetrag und der Order nicht eindeutig herstellen kann, spekuliere ich nicht einfach, nur weil der Betrag optisch passt.
Das ist auch der Grund, warum ich mich nicht darauf verlassen möchte, mehrere Orders nur nach Gedächtnis oder Gewohnheit zu bearbeiten. Wenn Daten direkt vor mir liegen, will ich sie mit der aktuellen Order abgleichen und nicht das, was ich gerade glaube getan zu haben.
Für mich ist das ein kleiner, aber sehr wichtiger Unterschied:
„Das Geld ist da“ bedeutet nur, dass ein Geldbetrag erschienen ist.
„Dieses Geld gehört zu dieser Order“ bestätigt erst, dass die Transaktion, mit der ich gerade arbeite, wirklich die richtige ist.
Manchmal liegt der Fehler nicht darin, das falsche Geld zu nehmen.
Sondern darin, das richtige Geld zu nehmen, aber es der falschen Transaktion zuzuordnen.
#BinanceP2PAnToan @Binance Vietnam $BNB
Das Geld ist echt.
Aber du ordnest diesen Betrag der falschen Order zu.
Ich bin einmal in einer ähnlichen Situation gelandet, als ich zwei Zahlungen kurz hintereinander verarbeitet habe. Beide tauchten im Konto auf, und weil der eine gerade als erstes vor Augen war, war die erste Reaktion: „Das ist bestimmt die Zahlung zu meiner offenen Order.“
Aber als ich zurückblickte, merkte ich, dass ich mich auf etwas stütze, das extrem leicht zu verwechseln ist:
Das Gedächtnis.
Ich erinnere mich daran, welche Order ich gerade erstellt hatte, wie viel Geld und welcher Betrag eigentlich als erstes hätte ankommen sollen.
Das hat mich dazu gebracht, meine Art zu überdenken, wie ich eine Transaktion bei Binance P2P prüfe.
Wenn mehrere Orders oder mehrere Überweisungen in kurzer Zeit parallel laufen, frage ich nicht nur:
„Ist das Geld schon da?“
Ich frage auch:
„Welcher Order gehört genau dieser Geldbetrag?“
Ich gleichen die Order, an der ich gerade arbeite, mit dem tatsächlich erhaltenen Betrag, den Angaben des Absenders und den Details der Zahlung ab. Wenn ich die Verbindung zwischen dem Geldbetrag und der Order nicht eindeutig herstellen kann, spekuliere ich nicht einfach, nur weil der Betrag optisch passt.
Das ist auch der Grund, warum ich mich nicht darauf verlassen möchte, mehrere Orders nur nach Gedächtnis oder Gewohnheit zu bearbeiten. Wenn Daten direkt vor mir liegen, will ich sie mit der aktuellen Order abgleichen und nicht das, was ich gerade glaube getan zu haben.
Für mich ist das ein kleiner, aber sehr wichtiger Unterschied:
„Das Geld ist da“ bedeutet nur, dass ein Geldbetrag erschienen ist.
„Dieses Geld gehört zu dieser Order“ bestätigt erst, dass die Transaktion, mit der ich gerade arbeite, wirklich die richtige ist.
Manchmal liegt der Fehler nicht darin, das falsche Geld zu nehmen.
Sondern darin, das richtige Geld zu nehmen, aber es der falschen Transaktion zuzuordnen.
#BinanceP2PAnToan @Binance Vietnam $BNB
Ich hatte früher gedacht, eine Firma mit ein paar Freunden zu gründen, sei recht einfach.
Jeder bringt einen Teil des Kapitals ein, man einigt sich auf die Eigentumsquoten, und dann beginnt man zu wirtschaften.
Aber als das Unternehmen wuchs, war die Frage nicht mehr nur: Wer bringt wie viel Geld ein?
Wer besitzt wie viel?
An wen werden Dividenden ausgeschüttet? Und wo werden diese Veränderungen festgehalten?
Da wurde mir eine Sache klar:
Die Ausgabe eines Vermögenswerts ist nur der Anfang.
Das brachte mich auf @Dusk
Als ich mir Dusk näher ansah, fand ich die Idee der „native issuance“ besonders spannend.
Tokenisierung wird häufig so verstanden, dass man einen Token erzeugt, der einen Vermögenswert repräsentiert. Aber bei „native issuance“ kann der eigentliche Vermögenswert selbst on-chain erstellt und verwaltet werden – sodass Prozesse wie Ausgabe, Übertragung, Services und Abwicklung um ein gemeinsames System herum gestaltet werden.
Das ist besonders wichtig für verwaltete Finanzanlagen.
Eine Anleihe oder eine Beteiligung endet nicht sofort mit der Ausgabe. Sie hat weiterhin Eigentumsrechte, Übertragungsbedingungen, Corporate Actions, Investor-Updates und Reporting, die über die Zeit hinweg abgebildet werden müssen.
Dusk verfolgt das Ziel, diese Workflows in dieselbe Infrastruktur zu bringen – statt dass Ownership, Transfer und Servicing auf mehrere unterschiedliche Systeme verteilt sind.
Das ist der Teil, der für mich besonders interessant ist.
Blockchain sollte nicht nur dabei helfen, einen Token zu erschaffen.
Kann ein Vermögenswert während seiner gesamten Laufzeit on-chain erzeugt, verwaltet und übertragen werden – während Privatsphäre, Compliance und Abwicklung weiterhin gewährleistet sind?
Für mich ist das die eigentliche tiefere Bedeutung, Finanzwesen on-chain zu bringen.
Nicht nur Vermögenswerte digitalisieren.
Sondern eine Infrastruktur bauen, in der die Lebenszyklus-Verwaltung eines Vermögenswerts von Anfang an geregelt werden kann.
#dusk $DUSK
Jeder bringt einen Teil des Kapitals ein, man einigt sich auf die Eigentumsquoten, und dann beginnt man zu wirtschaften.
Aber als das Unternehmen wuchs, war die Frage nicht mehr nur: Wer bringt wie viel Geld ein?
Wer besitzt wie viel?
An wen werden Dividenden ausgeschüttet? Und wo werden diese Veränderungen festgehalten?
Da wurde mir eine Sache klar:
Die Ausgabe eines Vermögenswerts ist nur der Anfang.
Das brachte mich auf @Dusk
Als ich mir Dusk näher ansah, fand ich die Idee der „native issuance“ besonders spannend.
Tokenisierung wird häufig so verstanden, dass man einen Token erzeugt, der einen Vermögenswert repräsentiert. Aber bei „native issuance“ kann der eigentliche Vermögenswert selbst on-chain erstellt und verwaltet werden – sodass Prozesse wie Ausgabe, Übertragung, Services und Abwicklung um ein gemeinsames System herum gestaltet werden.
Das ist besonders wichtig für verwaltete Finanzanlagen.
Eine Anleihe oder eine Beteiligung endet nicht sofort mit der Ausgabe. Sie hat weiterhin Eigentumsrechte, Übertragungsbedingungen, Corporate Actions, Investor-Updates und Reporting, die über die Zeit hinweg abgebildet werden müssen.
Dusk verfolgt das Ziel, diese Workflows in dieselbe Infrastruktur zu bringen – statt dass Ownership, Transfer und Servicing auf mehrere unterschiedliche Systeme verteilt sind.
Das ist der Teil, der für mich besonders interessant ist.
Blockchain sollte nicht nur dabei helfen, einen Token zu erschaffen.
Kann ein Vermögenswert während seiner gesamten Laufzeit on-chain erzeugt, verwaltet und übertragen werden – während Privatsphäre, Compliance und Abwicklung weiterhin gewährleistet sind?
Für mich ist das die eigentliche tiefere Bedeutung, Finanzwesen on-chain zu bringen.
Nicht nur Vermögenswerte digitalisieren.
Sondern eine Infrastruktur bauen, in der die Lebenszyklus-Verwaltung eines Vermögenswerts von Anfang an geregelt werden kann.
#dusk $DUSK
Anmelden und weiter Inhalte entdecken