Tôi đã viết khá nhiều về vấn đề này trong quá khứ nên hôm nay tôi sẽ không dành một bài viết dài cho nó, nhưng khi nói đến stablecoin (bao gồm những loại cho ETH hoặc các tài sản tham chiếu khác), oracle được mã hóa cứng là dễ bị gãy. Chúng hoạt động cho đến khi chúng sụp đổ một cách thảm khốc.

Ngược lại, oracle trực tiếp cho phép giảm thiểu rủi ro theo thời gian thực, nhưng với chi phí là làm người dùng bị phạt vì những dương tính giả nếu thansuất thắt lại.

Cả hai đều là những lựa chọn thiết kế hợp pháp, nhưng cần phải tuân theo các quy trình ký quỹ khác nhau. Chỉ mã hóa cứng nếu bạn kiểm chứng tài sản cơ bản và tự tin vào khả năng của nó đáp ứng các khoản hoàn tiền như được thiết kế.

Cả nền tảng kỹ thuật và tài chính phải vững chắc, và gán mức phí rủi ro cho lãi suất hoặc cắt giảm LTV một cách thích hợp.

Oracle trực tiếp cho phép bạn tương đối bất khiêu khích về chất lượng tài sản (ngoài tính an toàn kỹ thuật của các hợp đồng thông minh) và tập trung vào tính sẵn có của thansuất.

Hãy cũng nhớ rằng các thiết lập oracle phức tạp hơn cũng có thể. Bản thân tôi đã ủng hộ stablecoin có mã hóa cứng khi thansuất n khả thi trong hợp đồng hoàn tiền và sau đó chuyển sang oracle giá thị trường vào thời điểm thansuất giảm xuống dưới n.

Cuối cùng, vấn đề này lại nêu bật "vấn đề di chuyển tín dụng" lâu nay, nơi DeFi dựa vào các nhà quản lý và cố vấn rủi ro để thủ công đánh dấu khi một tài sản chuyển từ xuất sắc sang tốt sang trung bình sang kém như tài sản thế chấp. Điều đó chậm quá kể cả trong các trường hợp như USR, ngay cả khi nó chính xác 100%.

DeFi tự động hóa, tăng tốc độ, và đơn giản hóa (ngay cả khi nó đôi khi có vẻ ngược lại) tài chính so với các lựa chọn thay thế truyền thống. Chúng tôi cuối cùng đang xây dựng những chiếc máy bán hàng tài chính, và điều quan trọng là thực sự khó để tạo ra một máy hoạt động như dự định dưới mọi điều kiện.

Nhưng có những cách rõ ràng để cải thiện cả thiết kế oracle và cách sử dụng oracle, và thật đáng tiếc khi thấy sự đổi mới chậm trên mặt trận đó.