Cách hoạt động của nợ xấu Aave: từ số dư còn lại sau thanh lý đến thâm hụt dự trữ

Cách mà nợ xấu Aave hoạt động thì đơn giản trong kết quả nhưng rối rắm trong thực thi: một cuộc thanh lý có thể bán tất cả tài sản thế chấp và vẫn để lại nợ chưa thanh toán. Trong Aave v3.3, phần nợ còn lại sẽ ngay lập tức được tinh chế bằng cách đốt các token nợ biến đổi còn lại của người vay và ghi nhận sự thiếu hụt như một khoản thâm hụt dự trữ.

Điểm chính

• Nợ xấu Aave là một trạng thái cụ thể sau khi thanh lý, nơi một tài khoản có tài sản thế chấp bằng không nhưng vẫn còn nợ.Aave v3.3 ngăn chặn các khoản nợ 'zombie' tích lũy bằng cách đốt các token nợ biến đổi còn lại của người vay và ghi nhận sự thiếu hụt như một khoản thâm hụt theo dự trữ.Các khoản thâm hụt dự trữ được theo dõi theo từng tài sản trong ReserveData và được công khai thông qua một getter Pool, làm cho các khoản lỗ có thể đo lường được thay vì trôi nổi một cách vô hình.Các thâm hụt có thể được giảm bớt bởi một thực thể Umbrella có quyền hạn đốt aTokens, và việc staking Umbrella được thiết kế để cắt giảm các kho tài sản cụ thể khi nợ xấu vượt qua ngưỡng.Nợ xấu trên Aave có nghĩa là gì (định nghĩa bằng tiếng Anh đơn giản)
• Cách mà nợ xấu Aave hoạt động bắt đầu với một định nghĩa chính xác, không phải là cảm giác. Trên Aave, nợ xấu không phải là 'một người vay rủi ro' hay 'một cuộc thanh lý đã sai'. Nó là một trạng thái kế toán cuối cùng sau một cuộc thanh lý nơi tài sản thế chấp của người vay đã được sử dụng hoàn toàn và một số nợ vẫn chưa được thanh toán. Tại thời điểm đó, giao thức đang giữ một khoản nợ không được bảo hiểm.
• Điều này quan trọng vì Aave là một giao thức cho vay 'thế chấp quá mức' theo thiết kế. Toàn bộ giả định là giá trị tài sản thế chấp nên đủ để trang trải nợ thông qua thanh lý defi khi một vị thế trở nên không lành mạnh.
• Nợ xấu là những gì còn lại khi cơ chế đó không thể đóng vòng hoàn toàn do khoảng cách giá, giới hạn thanh khoản hoặc tốc độ thanh lý.Tài liệu Aave v3 công nhận rõ ràng trường hợp biên khó chịu: một số kịch bản thanh lý có thể kết thúc với tài sản thế chấp bằng không và nợ còn lại, và nợ đó khó có khả năng được trả lại. Vấn đề thực tiễn không chỉ là mất mát. Đó là sự trôi dạt. Nếu hệ thống tiếp tục coi phần còn lại đó như nợ biến đổi bình thường, lãi suất sẽ tiếp tục tích lũy trên một IOU không có tài sản thế chấp đứng sau, làm phồng lên khoản nợ rõ ràng của giao thức theo thời gian. Đó là chế độ thất bại 'nợ xấu defi' mà các nhà giao dịch thực sự nên quan tâm.cách mà nợ xấu aave hoạt động
• Trong thực tế, cách mà nợ xấu aave hoạt động là một chuỗi đầu vào → quy trình → đầu ra.

Đầu vào: một người vay đăng ký tài sản thế chấp, vay một tài sản, và vị thế trở nên thiếu tài sản thế chấp khi giá di chuyển. Aave theo dõi điều này bằng một yếu tố sức khỏe. Khi yếu tố sức khỏe giảm xuống dưới ngưỡng thanh lý, các nhà thanh lý bên thứ ba có thể trả một phần nợ của người vay và nhận tài sản thế chấp với mức giảm giá thông qua khoản thưởng thanh lý.

Quy trình: thanh lý không phải là một sự kiện sạch sẽ đơn lẻ. Nó là một loạt các giao dịch trên chuỗi cạnh tranh với các cập nhật 'oracle', việc bao gồm khối, 'chi phí gas', và thanh khoản thị trường có sẵn để tìm nguồn tài sản trả nợ và bán tài sản thế chấp bị tịch thu. Aave v2 đã sử dụng một yếu tố đóng cố định giới hạn số nợ có thể được trả mỗi lần thanh lý.

Aave v3 đã giới thiệu một yếu tố đóng biến đổi cho phép lên đến 100% trả nợ trong các điều kiện khủng hoảng sâu hơn, điều này nhằm giảm thiểu 'bụi' còn lại trở nên không kinh tế để thanh lý.

Đầu ra: nếu các cuộc thanh lý trả hết nợ, hệ thống sẽ ổn. Nợ xấu xuất hiện khi các cuộc thanh lý tiêu thụ tất cả tài sản thế chấp và vẫn không thể trả hết nợ. Điều đó tạo ra trạng thái xác định: tài sản thế chấp bằng không, nợ vẫn không bằng không. Trước v3.3, phần còn lại đó có thể tiếp tục tích lũy lãi suất, biến một sự thiếu hụt một lần thành một vấn đề kế toán ngày càng lớn.

Trong v3.3, giao thức coi phần còn lại đó như một khoản lỗ cấp giao thức ngay sau khi thanh lý bằng cách đốt các token nợ biến đổi còn lại và ghi nhận một khoản thâm hụt dự trữ cho tài sản đó.Cách nợ xấu được tạo ra: cơ chế thanh lý và trường hợp 'tài sản thế chấp không đủ'Thanh lý thường được mô tả là 'yếu tố sức khỏe < 1, do đó nợ được trả lại.'

Quy trình thanh lý trong thế giới thực gần giống như một cuộc đấu giá bị hạn chế với các giới hạn cứng. Các nhà thanh lý chỉ hành động khi giao dịch có lợi nhuận sau chi phí gas và rủi ro thực hiện, và các quy tắc yếu tố đóng của giao thức giới hạn số tiền có thể được trả mỗi giao dịch.

Hướng dẫn của Bitget nắm bắt các cơ chế cốt lõi: thanh lý được kích hoạt khi yếu tố sức khỏe giảm xuống dưới ngưỡng, và các nhà thanh lý trả nợ để đổi lấy tài sản thế chấp với mức giảm giá. Nó cũng lưu ý sự khác biệt về yếu tố đóng giữa các phiên bản, với Aave v2 cho phép trả nợ lên đến 50% mỗi lần thanh lý và Aave v3 cho phép trả nợ lên đến 100% khi yếu tố sức khỏe xấu đi hơn nữa (một ngưỡng ví dụ khoảng 0.95 được trích dẫn).

Nợ xấu được tạo ra khi động cơ thanh lý đang thực hiện công việc của nó, nhưng thị trường di chuyển nhanh hơn động cơ có thể làm sạch rủi ro. Các khoảng cách giá có thể làm cho tài sản thế chấp có giá trị thấp hơn so với mô hình giữa các cập nhật oracle. Thanh khoản mỏng có thể làm cho việc tìm nguồn tài sản trả nợ hoặc bán tài sản thế chấp bị tịch thu mà không có 'trượt giá' trở nên tốn kém. Cơ chế yếu tố đóng có thể buộc thanh lý xảy ra theo từng phần, điều này là tốt trong các thị trường chậm và nguy hiểm trong các chuyển động không liên tục.

Tài liệu Aave v3.3 rõ ràng về trường hợp biên: thanh lý có thể dẫn đến tổng tài sản thế chấp bị thanh lý không đủ để trang trải việc trả nợ toàn bộ, để lại tài sản thế chấp bằng không và nợ còn lại. Đó là khoảnh khắc mà vấn đề của người vay trở thành một vấn đề kế toán của giao thức.

Quản lý nợ xấu Aave v3.3: đốt nợ còn lại của người vay, ghi nhận một khoản thâm hụt dự trữThay đổi chính của Aave v3.3 không phải là 'ngăn chặn nợ xấu.' Nó là 'ngăn chặn nợ xấu biến đổi.' Giao thức giới thiệu một bước xác minh sau thanh lý được thiết kế để giảm thiểu việc tạo ra các tài khoản nợ xấu mới sau thanh lý và ngăn chặn việc tích lũy lãi suất thêm trên các khoản nợ đó.Về mặt cơ học, giao thức kiểm tra tài khoản sau thanh lý và trả nợ.

Nếu tài khoản kết thúc với tài sản thế chấp bằng không và nợ không bằng không, nợ còn lại sẽ bị đốt và sự thiếu hụt kết quả sẽ được ghi nhận vào dự trữ liên quan như một khoản thâm hụt. Tài liệu mô tả việc dọn dẹp này như xảy ra về mặt khái niệm sau khi thanh lý thực tế, điều này là mô hình tư duy đúng cho các nhà giao dịch. Thanh lý là giao dịch. Việc dọn dẹp là sự hòa giải.

Đây là luận điểm v3.3 dưới dạng mã: nợ xấu không còn được phép ngồi trên một người dùng và tích lũy mãi mãi. Nó được tinh chế thành một khoản thâm hụt cấp dự trữ có thể được theo dõi theo từng tài sản. v3.3 giới thiệu việc theo dõi thâm hụt bên trong ReserveData bằng cách tái sử dụng kho lưu trữ stableBorrowRate đã bị loại bỏ, và công khai nó thông qua một getter Pool getReserveDeficit.

Điều đó làm cho lỗ hổng có thể chỉ định, từng dự trữ một, thay vì bị chôn vùi trong toán học lãi suất trôi dạt.Cũng có xử lý đặc biệt cho GHO. v3.3 chia thanh lý thành một việc đốt nợ biến đổi và một trình xử lý trả nợ aGHO mà giảm giá phí. Khi đốt nợ xấu trong GHO, giao thức đặt lại kho lưu trữ phí tích lũy trên vGHO và thực sự chấp nhận mất mát trên phí tích lũy cho phần nợ xấu để giữ cho kế toán nhất quán. Chi tiết đó quan trọng vì nó cho thấy ý định. Mục tiêu là dọn dẹp có định hướng, không để lại các yêu cầu phí cũ gắn liền với một tài khoản không còn có token nợ.cách mà mô-đun an toàn của aave hoạt độngMô-đun An toàn di sản được hiểu tốt nhất như một biện pháp hỗ trợ được điều chỉnh bởi chính phủ hơn là một động cơ bảo hiểm luôn hoạt động. Blockworks mô tả nó như một biện pháp hỗ trợ nơi các vị trí stkAAVE và AAVE-ETH có thể bị cắt giảm về lý thuyết, nhưng 'cắt giảm' chưa bao giờ xảy ra vì nó yêu cầu các cuộc bỏ phiếu của chính phủ và các động lực chính trị khiến việc kích hoạt trở nên không chắc chắn.Về mặt rủi ro thực tiễn, điều đó có nghĩa là giá trị của Mô-đun An toàn là độ tin cậy, không phải tự động hóa. Nó báo hiệu rằng một nhóm được định hướng bởi token chính phủ có thể tái cấp vốn cho các khoản lỗ, nhưng nó không đảm bảo việc hấp thụ tổn thất nhanh chóng, có định hướng trong một thị trường nhanh.

Đây là lý do tại sao kế toán nợ xấu của v3.3 quan trọng ngay cả khi một biện pháp hỗ trợ tồn tại. Nếu nợ xấu được phép tồn tại trên các tài khoản người dùng và tích lũy lãi suất, giao thức thậm chí không thể đo lường tổn thất một cách sạch sẽ, điều này làm cho bất kỳ quyết định hỗ trợ nào trở nên khó khăn hơn.

Bằng cách biến sự thiếu hụt thành một khoản thâm hụt dự trữ, Aave làm cho câu hỏi về Mô-đun An toàn trở nên cụ thể hơn: có bao nhiêu thâm hụt tồn tại, trên tài sản nào, và cơ chế nào được ủy quyền để trung hòa nó.

ai sẽ trả khi aave có nợ xấu

Khi khoản nợ xấu được công nhận trong v3.3, số tiền chưa thanh toán không còn được coi là "nợ của người vay" theo nghĩa kinh tế có ý nghĩa. Người vay không còn tài sản thế chấp, và giao thức đã đốt các token nợ biến đổi còn lại để ngăn chặn việc tích lũy lãi suất. Khoản lỗ được ghi nhận như một khoản thâm hụt trong quỹ dự trữ cụ thể.

Khung này trả lời ai sẽ trả tiền trong thực tế: quỹ dự trữ đang thiếu, và hệ thống cần tái cấp vốn để khôi phục sự hỗ trợ đầy đủ. v3.3 giới thiệu eliminateReserveDeficit, nơi một thực thể có quyền, Umbrella đã đăng ký trên PoolAddressesProvider, có thể đốt aTokens để giảm thâm hụt của quỹ dự trữ đó. Chức năng này bị giới hạn ở việc đốt tối đa số thâm hụt hiện có và xác thực rằng người gọi không có vị trí vay mở.

Đây không phải là một "quỹ bảo hiểm có thể bao phủ" mơ hồ. Đây là một hành động cụ thể trên chuỗi làm giảm một thâm hụt được theo dõi bằng cách phá hủy các yêu cầu trên quỹ dự trữ (aTokens). Hệ quả kinh tế là rõ ràng.

Ai đó nắm giữ tài sản bảo hiểm đang chịu thiệt hại để các nhà gửi tiền trong quỹ dự trữ đó được hoàn lại.Mô tả của Blockworks về việc staking Umbrella thêm một lớp hoạt động. Umbrella được trình bày như một mạng lưới an toàn tự động gắn liền với các tài sản cá nhân, với việc cắt giảm theo thời gian thực khi khoản nợ xấu trong tài sản đó vượt quá ngưỡng đã đặt trước, sau một bù đắp tổn thất đầu tiên có thể cấu hình được, được báo cáo là 100.000 đơn vị cho mỗi tài sản vào thời điểm đó. Đó là câu trả lời thực tiễn cho "ai sẽ trả" trong một hệ thống được thiết kế: những người staking trong kho tài sản bị ảnh hưởng, trên bù đắp, thay vì một quỹ tổng quát cần một cuộc bỏ phiếu quản trị.Aave đã từng có nợ xấu trước đây chưa

Có, và sự kiện CRV năm 2022 là minh họa rõ ràng nhất về lý do tại sao "chỉ cần thanh lý" không phải là một đảm bảo. Nghiên cứu trường hợp của EigenPhi mô tả một vị thế short CRV dẫn đến khoảng 2,456 triệu CRV chưa thanh toán sau các đợt thanh lý, có giá trị khoảng 1,6 triệu đô la theo giá CRV được trích dẫn.

Hoạt động thanh lý không phải là điều tầm thường. EigenPhi báo cáo 385 lần thanh lý bởi 21 địa chỉ duy nhất. Điểm quan trọng không phải là các nhà thanh lý vắng mặt. Điểm quan trọng là thông lượng thanh lý và thời gian oracle vẫn có thể để lại một khoản nợ dư khi thị trường di chuyển theo bước nhảy.

EigenPhi cũng lưu ý rằng có độ trễ giá oracle khoảng 10 phút so với Binance và mô tả hành vi thanh lý đến theo từng lô. Sự kết hợp đó chính xác là môi trường mà tài sản thế chấp có thể bị cạn kiệt trước khi nợ được hoàn trả đầy đủ. Định nghĩa nợ xấu của Aave v3.3 là "tài sản thế chấp cạn kiệt trước khi nợ được hoàn trả đầy đủ" không phải là lý thuyết. Đây là một trạng thái đã xảy ra dưới áp lực.

module Umbrella của aave là gì

Umbrella là thiết kế an toàn mới hơn của Aave cố gắng làm cho việc hấp thụ tổn thất trở nên tự động và cụ thể cho tài sản. Blockworks mô tả việc staking Umbrella như một mạng lưới an toàn tự động trên chuỗi gắn trực tiếp với các tài sản cá nhân, được thực hiện dưới dạng các kho độc lập.

Nếu xảy ra thiếu hụt, giao thức có thể đốt cùng một tài sản từ kho của mình sau một bù đắp tổn thất đầu tiên có thể cấu hình, được báo cáo là 100.000 đơn vị cho mỗi tài sản vào thời điểm đó.

Phần "cụ thể cho tài sản" là sự chuyển đổi thiết kế thực sự. Thay vì xã hội hóa rủi ro qua một quỹ hỗ trợ quản trị rộng lớn, Umbrella nhắm đến quỹ dự trữ thực sự có thâm hụt. Điều này phù hợp với việc theo dõi thâm hụt theo quỹ dự trữ của v3.3. Nếu giao thức có thể đo lường một thâm hụt trên USDC so với ETH so với GHO, một quỹ hỗ trợ cũng được phân đoạn theo tài sản sẽ hoạt động sạch hơn.

Umbrella cũng thay đổi chiều thời gian. Blockworks nhấn mạnh không có cuộc bỏ phiếu quản trị, không có đấu giá và không có độ trễ cho việc cắt giảm khi các ngưỡng bị vi phạm. Điều đó quan trọng vì nợ xấu thường phát sinh trong các thị trường nhanh. Một quỹ hỗ trợ chỉ kích hoạt sau một quy trình quản trị dài là không phù hợp về cấu trúc với vấn đề.

Aave có thể trở nên phá sản khôngAave có thể đối mặt với tình trạng phá sản ở cấp độ quỹ dự trữ khi các nghĩa vụ vượt quá tài sản cho một thị trường nhất định, điều này chính xác là những gì một thâm hụt quỹ dự trữ đại diện. Aave v3.3 không giả vờ khác đi. Nó chính thức hóa thâm hụt để có thể được theo dõi và có khả năng trung hòa.Điểm tinh tế chính là phạm vi.

v3.3 định nghĩa một tình huống nợ xấu một cách hẹp là một tài khoản không có tài sản thế chấp trong tiền tệ cơ sở và nợ còn lại trong tiền tệ cơ sở. Các tài khoản có bất kỳ tài sản thế chấp nào còn lại không được coi là nợ xấu vì chúng có thể trở thành quá thế chấp một lần nữa. Đó là một ranh giới thực tiễn.

Tình trạng phá sản liên quan đến các nghĩa vụ không được bảo đảm, không phải các vị trí tạm thời không khỏe mạnh.v3.3 cũng ghi lại các hạn chế quan trọng đối với bất kỳ ai mô hình hóa rủi ro đuôi. Nó không khắc phục các vị trí nợ xấu đã tồn tại và khuyến nghị dọn dẹp DAO thông qua repayOnBehalf. Việc loại bỏ thâm hụt giả định rằng Umbrella có các token để đốt, và các ràng buộc hoạt động như giới hạn và kế toán ảo có thể ảnh hưởng đến tốc độ mà tài sản bảo hiểm có thể được định vị. Điều đó có nghĩa là hệ thống có thể nhận ra và ngăn chặn việc tích lũy nợ zombie mới, nhưng việc tái cấp vốn vẫn phụ thuộc vào cấu hình quỹ hỗ trợ và bảo hiểm có sẵn.Những hiểu lầm phổ biến

Hiểu lầm đầu tiên là "nợ xấu có nghĩa là các lần thanh lý đã thất bại." Các lần thanh lý có thể thực hiện chính xác như thiết kế và vẫn kết thúc với tài sản thế chấp bằng không và nợ còn lại vì thiết kế bị hạn chế bởi các yếu tố gần gũi, kinh tế gas, nhịp cập nhật oracle và tính thanh khoản của thị trường thứ cấp. Nghiên cứu trường hợp CRV cho thấy hoạt động thanh lý mạnh mẽ và vẫn có một khoản chưa thanh toán dư.

Hiểu lầm thứ hai là "nợ xấu chỉ là khoản vay chưa thanh toán của người vay." Trên Aave v3.3, khi giao thức đốt các token nợ biến đổi còn lại của người vay, người vay không còn là nơi mà nghĩa vụ tồn tại. Khoản lỗ được ghi nhận như một thâm hụt quỹ dự trữ, theo tài sản, và câu hỏi trở thành làm thế nào để giảm thâm hụt đó thông qua các cơ chế như eliminateReserveDeficit và việc cắt giảm kho tài sản của Umbrella.

Hiểu lầm thứ ba là "Aave v3.3 loại bỏ tất cả nợ xấu." v3.3 ngăn chặn các tài khoản zombie mới sau thanh lý tích lũy lãi suất bằng cách đốt nợ còn lại và ghi nhận một thâm hụt, nhưng tài liệu rõ ràng tuyên bố rằng nó không giải quyết các vị trí nợ xấu đã tồn tại. Điều cần lưu ý là v3.3 cải thiện tính xác định và tính minh bạch, không phải các quy luật của việc chênh lệch thị trường.

Chủ đề này nằm trong cơ chế rộng hơn của defi, nơi quá thế chấp và thanh lý là các rào cản an toàn cốt lõi. Đối với những độc giả đang lập bản đồ rủi ro giao thức, bước tiếp theo hữu ích là quay lại hướng dẫn chính về defi và coi nợ xấu như một vấn đề thâm hụt quỹ dự trữ có thể đo lường, không phải là một câu chuyện đạo đức về những người vay liều lĩnh.

Nguồn

Aave DAO (tài liệu Aave v3.3)

Blockworks

EigenPhi

Bitget Academy

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop