我有小廣播扬舒，你要聽我說：小姐姐辛苦翻譯分享肺樟，心疼小姐姐的轉(zhuǎn)載總可以注明來路吧！烙丛！如遇幣豪們祭埂，文章下面有小姐姐的打賞地址面氓，收基于ERC-20的各種幣，一個(gè)都不嫌棄哦蛆橡！
? 二? LENDROID FROM FOUR USER JOURNEYS
A more comprehensive and effective understanding of the? protocol can be achieved when approached from the user journeys of four key actors.
2.1. THE LENDER
Analogous to the Maker from the 0x protocol [6], the lender broadcasts the loan-offer to all decentralized exchanges (off-chain action). Of the different types of accounts within the Lendroid Smart Contract system, the Funding Account is available to the lenders to deposit funds into and offer loans from. Each loan offer is a data packet called the offer object
containing the terms of the loan, offer parameters, and an associated ECDSA signature. The loan terms and parameters are concatenated and hashed to produce a 32 byte-long Keccak SHA3 signature called the offer-hash. The lender signs this offer-hash with their private key to produce the ECDSA signature. As discussed in section 1, it is imperative that the interests of the Lender - who contributes to the shared liquidity pool - are protected. This is enabled by empowering the Lender to de?ne key parameters within the offer object.
2.1.1. De?ning the Offer Object
Off chain, the Lender de?nes the offer object with a range of parameters [See Table 1], key among them
a. Loan Amount and Interest Rate: The Lender de?nes the offer amount (token offered and number of units of the token) and sets the interest to be calculated on a daily basis.
b. Loan Expiration Period: The validity of the loan from the time it is availed. On expiry, the loan is called in and, should the borrower so choose, rolled over with another loan.
c. Offer Expiration: The validity of the offer itself. Based on the demand for a token, a Lender might want to change his offer to re?ect a different interest rate or number of token units. Setting a prudent expiry time for the offer allows for this ?exibility, without having
go on-chain.
It is important to note that every loan also requires some LST for initialization. To lubricate the inherent processes, the lender deposits some LST meant for the Relayer at the end of the loan period. Some he deposits for the Wrangler in the event that it was he who identi?ed the Margin Account at liquidation level and helped close the loan. The LSTs required for these processes are locked in at the time of initiation. If there is not enough LST for these processes, the loan is not initialized.
2.1.2. Cancelling the Loan Offer
A loan offer is deemed invalid, and therefore is cancelled, in the following cases: a. If a loan offer is availed after its expiration period: In this case, the Loan Smart Contract recognizes that the offer cannot be availed anymore, and triggers an event indicating to all Relayers that the loan with the corresponding hash is invalid. It is in the Relayers’ best interests to not display expired loans in the ?rst place and, even if they do, they have the option to listen in on the Loan Offer Cancelled event from the Loan Smart Contract.
b. If a Lender decides to cancel an offer that has been left unavailed and un?lled: In this case, the lender can call the Loan Smart contract’s Cancel Loan function which further triggers the Loan Offer Cancelled event from the same Smart Contract, thus notifying all listening Relayers. Cancelling a loan offer is a fallback mechanism and costs gas. Therefore, it is in the best interests of the lender to set a suitable Expiration Period on the offer to avoid on-chain transactions.
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 2.2 THE RELAYER
The Relayer is the ?rst point of contact for both lender and trader on the Lendroid protocol. Off chain, this entity effectively takes up the liquidity related functions of an exchange in a wholly decentralized manner. The one signi?cant addition to the Lendroid Relayer over its 0x counterpart is the management of loan offers. Relayers provide an interface, and manage order books and offer books. They are key to creating the shared global lending pool.
2.2.1. Interface
As actors that operate almost entirely off-chain, the Relayer’s potential for creating a smooth, fast, user experience, is limitless. Available interfaces today offer an increasingly sophisticated dashboard, with periodic upgrades in granularity, of data native to the protocol, as well as relevant external information from the market, to help lenders and margin traders make more informed decisions. Loan offers are captured and offered as part of this interface. The richness of the information on display depends on the depth that a particular Relayer chooses to showcase. Without exception, every Relayer has complete access to the shared lending pool – the collective of loan offers recorded with not just one particular Relayer, but with the entire community of Relayers on the protocol. Relayers can also offer APIs to facilitate programmatic access? to offer books. With access to the entire lending pool, and with off-chain speed and ?exibility at their disposal, Relayers can maintain liquidity and create an interface that encourages patronage.
2.2.2. Bookkeeping
The same off-chain advantage in interface extends to the bookkeeping function of the Relayer as well. With computational power unbridled by on-chain lags and costs in gas, a Relayer can maintain Offer Books in a real-time, seamless manner. The Relayer is incentivized with a fee in the Lendroid Support Token (LST) for recording and relaying the loan offer. A fee is paid by the Lender and, when the loan is availed, by the borrower/margin trader as well. Attracting liquidity into the platform, the Relayer is paid only when a loan is availed, and closed properly. The Relayer is able to match and offer with an ask even if it originated with another Relayer. Despite the incentive, and the fact that the Relayer has access to the entire shared lending pool, the protocol remains trust independent because of two key 0x-inspired characteristics [6], written into the protocol itself.
a. Relayers cannot execute transactions on behalf of the Lender or the Margin Trader. They can only recommend an ideal offer.
b. A clear fee structure when a loan is availed. The Relayer? with whom the offer was recorded is paid by the Lender, and the same Relayer is paid by the Margin Trader once the loan is paid back.
2.2.3. A Global, Shared Liquidity Pool
Due to the inherent trust-independence of the protocol, access to loan offers is not limited to any one Relayer or a particular set of Relayers on Lendroid. As an extension, all the lenders and the Margin Traders on the platform contribute to liquidity in the ecosystem. As Figure 3 illustrates, a lender is free to engage with any Relayer on the protocol. Irrespective of who they record the loan offer with, it goes into the shared lending pool. When catering to the Margin Trader, a Relayer is free to recommend loan offers received from any Relayer. In the interest of providing a ‘sticky’ experience that could make him the Primary Relayer, it is in his best interest to connect the Lender or Margin Trader to the most ideal offer.
2.3 THE MARGIN TRADER
On Lendroid, the Margin Trader enjoys leveraged lending in a uniquely decentralized
environment. He deposits collateral, avails the loan offered by lenders and engages in margin trading/short selling. He opens a margin account, within which he is free to change positions or add collateral. He can withdraw his collateral or liquidate his Margin Account when there are no loans owed. Here’s how those actions play out, broadly.
2.3.1. Locking in Collateral
Lendroid is compatible with any ERC20-based token. This gives the Margin Trader a high level of ?exibility with respect to the nature of collateral he can deposit against a loan. A Margin Trader is free to deposit not just one kind of collateral in a token of his choice, but multiple kinds of ERC20-based tokens at the same time, in the same margin account. However, the support for a token has other considerations besides compatibility alone. In what is envisioned as a community-driven governance model, the protocol will add or remove support for a token based on the current volatility of the token. If the Margin Trader ?nds that the health of the margin account has dipped, he can add collateral at any time before the liquidation process is initiated on his account.
2.3.2. Availing a Loan
As illustrated in section 2.1, a Margin Trader can avail a loan through his Relayer. It is in the interfacer provider’s interest to connect him to the ideal offer. Offers are signed by the respective Lenders who made them are available with the Relayer. When a Margin Trader ?nds one that is suitable for his needs, he calls the availLoan function on the Loan Smart Contract, by including the offer object in the function call. Using the ecrecover function, the smart contract will then verify that the signature is valid and, based on the timestamp, that the offer has not expired. The Smart Contract also checks the Lender’s funding account to make sure there are suf?cient funds to carry out the offer. Once rati?ed, the funds are credited to the Trader’s Margin Account and debited from the Lender’s Funding Account.
2.3.3. The Margin Account
The Margin Trader stakes LST when opening a Margin Account. This stake is refundable, when the Trader closes trade positions and repays the loan. However, in case the account drops below the liquidation level, the deposit becomes a bounty for the Wranglers.
In the Margin Account, neither the collateral nor the positions can be withdrawn without honouring the terms of the loan. However, a Margin Trader is free to manipulate both elements at any time to maximize returns. He can top up collateral in a ?agging account, and calibrate his positions with the help of decentralized order book protocols.
In Figure 4a, there’s the Margin Account on the extreme right, which contains the capital he borrowed for the trade, and the possibility of creating trade positions out? of available funds.
In Figure 4b, we see that the Margin Trader has calibrated his trade positions. This intent is recorded on-chain, and executed using a decentralized order book protocol. Lendroid is capable of integrating with multiple order book protocols, including 0x, Kyber, Omega, and others. When positions need to be updated or rearranged, the Margin Trader can delegate the function to the most liquid order book protocol in the ecosystem.
In Figure 4c, we see that at the end of a trading session, the trade? positions? have? done? well? for? the? Margin? Trader? and a pro?t? has? been? accrued? ? over? ? and? ? above? the? borrowed capital.
2.3.4. Closing a Loan
The loan terms are speci?ed by the Lender right at the beginning, when the offer is made. There are three scenarios in which the loan is closed. The ?rst is the scenario described in Figure 4c. The Margin Trader has made a successful trade and is able to close the loan, repaying it without incident. Alternatively, the term of one or many loans might be close to expiry even when the Margin Trader is not ready to unwind his trade positions. Monitoring this can be delegated to incentivized actors called Wranglers, who will help replace or ‘roll-over’ an expiring loan with a fresh one. Though not built?into the protocol, this speci?c function is a logical extension of a Wrangler’s primary role – that of monitoring the margin account. In the third scenario, a Margin Account underperforms and warrants immediate action. A Wrangler has identi?ed the account. The Wrangler then repays the loan to the Lender himself, and also triggers an auction of the Margin Trader’s collateral and positions.? A fourth and less likely scenario is a Black Swan event, where a Margin Account has been left unattended by Wrangler and Margin Trader and, for enough time to cause damage, by the Lender himself. In such a case, the Lender can call in his loans and as a result will take over and choose to withdraw the collateral and trade positions as a compensation.
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 2.4 THE WRANGLER
The Wrangler is an entity conceptualized for the Lendroid ecosystem. One of two incentivized actors within the protocol, the Wrangler is intended to perform a computationally intensive role: that of monitoring the Margin Accounts. By monitoring and ‘Wrangling’ terminal accounts (at liquidation level), the Wrangler maintains the general health of the ecosystem, while also protecting the interests of the Lenders. However, the applications of such processing power spill beyond the requirements of the protocol, and can begin to enhance the experience of the other participants.
2.4.1. Margin Level Monitoring
Every on-chain event is broadcast on the protocol. It is this broadcast that the Wrangler tunes into. The Wrangler keeps tabs on each development: from the creation of a Margin Account, to every state change in position, adding of collateral, etc until the account? ? ? ? is liquidated. Whenever there is a change in the state of a Margin Account as a result of calling a function from the Lendroid Smart Contract system, the Account Smart Contract triggers an event notifying and specifying the function name and the corresponding Margin Account.
It is important to note that margin monitoring, recognized as an aspect of risk management, was hitherto performed by a centralized exchange to protect the Lender’s interests and the market integrity. Conventional exchanges would make what is known as a ‘margin call’ – an actual phone call to the trader, asking him to deposit additional funds – when the account dipped below a certain percentage of leverage [8]. Since the concept of a margin call is improbable on the blockchain ecosystem, the Wrangler’s role becomes all the more vital for the health of the market. This is why the Wrangler’s role, powered by computational capability, is incentivized in innovative ways. For instance, as seen in 2.3.4., a Wrangler can be delegated – for a fee by the Lender – to not just monitor the Account, but also help with rolling over an expiring loan with a fresh one.? The Wrangler picks up a bounty when he ‘wrangles’ an Account at liquidation level. He also stands to earn the right to the MarginTrader’s collateral or his trade positions, when he triggers an Auction.
2.4.2. Triggering an Auction
Having identi?ed what he deems a terminal Margin Account, the Wrangler already stands to win the bounty attached to it. However, there is more at stake. The Wrangler cannot withdraw the collateral or liquidate the positions any more than the Margin Trader can. He triggers an auction, a competitive process, which demands that the claim is veri?ed by the Lendroid Smart Contract system and also by other competing Wranglers via independent sources of market information. The actual auction process is described in a subsequent section.
-------------------------------------------------------------------------------------------
第二部分：Lendroid架構(gòu)流程中的四個(gè)主要角色
四大角色： 貸方舌界，中繼者，保證金交易者泰演，牧馬人（監(jiān)督員）
從四個(gè)關(guān)鍵角色的用戶體驗(yàn)中呻拌，可以實(shí)現(xiàn)對(duì)協(xié)議更全面和更有效的理解.
2.1? 貸方
類似于來自0x協(xié)議的做市商，貸方向所有分步的交易所廣播貸款（鏈下行為）粥血。在Lendroid智能合約系統(tǒng)中不同類型的賬戶中柏锄，資金賬戶是可供貸款人存入資金并提供貸款。每個(gè)貸款要約都是一個(gè)數(shù)據(jù)包复亏，叫做要約對(duì)象趾娃，包含貸款條件，要約參數(shù)和相關(guān)的ECDSA簽名（橢圓曲線數(shù)字簽名算法）缔御。 貸款條款和參數(shù)連接在一起并散列抬闷，產(chǎn)生32字節(jié)長的基于Keccak 的SHA3簽名，稱為offer-hash。 貸方用私鑰對(duì)這個(gè)offer進(jìn)行簽名笤成，生成ECDSA簽名评架。
正如第一部分所討論的那樣，貸款人的利益（對(duì)共同流動(dòng)資金池的貢獻(xiàn)）是受到保護(hù)的炕泳。 這是通過授權(quán)貸方在要約對(duì)象中定義關(guān)鍵參數(shù)來實(shí)現(xiàn)的纵诞。
（技術(shù)點(diǎn)：SHA3 （加密算法C語言測(cè)試代碼（基于Keccak算法））
2.1.1 定義鏈下要約對(duì)象
貸方用一系列參數(shù)定義offer對(duì)象[見表1]，其中的關(guān)鍵字
a.貸款金額和利率：貸方定義要約金額（提供的代幣和代幣單位數(shù)量）培遵，并設(shè)置每天計(jì)算的基本利息浙芙。
b,貸款到期期限：貸款從有效期起的有效期。 到期時(shí)籽腕，貸款被召回嗡呼，如果借款人愿意的話，可再借另外一筆貸款皇耗。
c.要約截止期：根據(jù)要約的有效性南窗。基于對(duì)代幣的需求郎楼，貸款人可能想要改變他的要約以反映不同的利率或代幣的單位數(shù)量万伤。無需在鏈上，為要約的靈活性設(shè)置謹(jǐn)慎的到期時(shí)間呜袁。
需要注意的是傅寡，每筆貸款都需要一些LST進(jìn)行初始化。為了運(yùn)行固有的過程北救，貸款人在貸款期結(jié)束時(shí)荐操，為中繼者存放一些LST。 一些LST是為牧馬人存入珍策，牧馬人負(fù)責(zé)識(shí)別保證金賬戶的清算水平并幫助關(guān)閉貸款托启，這些過程所需的LST在啟動(dòng)時(shí)被鎖定。 如果這些流程沒有足夠的LST攘宙，則貸款不會(huì)被初始化屯耸。
2.1.2 取消貸款要約
在下列情況下，貸款要約視為無效因此將被取消：
a.? 如果貸款要約在到期后有效：在這種情況下蹭劈，貸款智能合約確認(rèn)不能再使用該要約疗绣，并觸發(fā)一個(gè)事件向所有中繼者指示該貸款與相應(yīng)的散列無效。
b.? 在Relayer的最佳利益中铺韧，不顯示過期的貸款多矮，即使他們這樣做，他們也可以選擇從貸款智能合約中獲知貸款要約取消的事件。
2.1? 中繼者
中繼者是Lendroid協(xié)議上貸款人和交易者的第一個(gè)接觸點(diǎn)塔逃。在鏈下讯壶，該實(shí)體以完全散的方式有效地承擔(dān)了交易所的流動(dòng)性相關(guān)職能。與0x相比湾盗，Lendroid中繼程序的一個(gè)重要附加部分是貸款要約的管理伏蚊。中續(xù)者提供一個(gè)接口，并管理訂單和提供訂單簿格粪。它們是創(chuàng)建共享的全球貸款池的關(guān)鍵躏吊。
作為幾乎完全脫離鏈的運(yùn)行角色，中繼者創(chuàng)造出流暢匀借、快速颜阐、用戶體驗(yàn)的潛力是無限的。如今吓肋，可用的接口提供了一個(gè)日益復(fù)雜的按鈕（儀表板）凳怨，定期更新協(xié)議中的數(shù)據(jù)，以及來自市場(chǎng)的相關(guān)外部信息是鬼，以幫助放款人和保證金交易者做出更知情的決定肤舞。
2.2.1 接口
貸款要約被捕獲并作為此接口的一部分提供。顯示信息的豐富性取決于特定中繼者選擇展示的深度均蜜。無一例外李剖，每個(gè)中繼者都可以完全訪問共享的貸款池---貸款提供的集體記錄不僅由一個(gè)特定的轉(zhuǎn)接器記錄，而且與整個(gè)協(xié)議中繼者社區(qū)記錄在一起囤耳。 中繼者還可以提供API篙顺，以方便編程訪問。 有了進(jìn)入整個(gè)貸款池的機(jī)會(huì)充择，加上脫鏈的速度和靈活性德玫，中繼者可以保持流動(dòng)性，并創(chuàng)建一個(gè)鼓勵(lì)光顧的接口界面椎麦。
2.2.2.? 記賬
界面中同樣的鏈下優(yōu)勢(shì)也擴(kuò)展到了中續(xù)者的簿記功能宰僧。 計(jì)算能力不受鏈上滯后和費(fèi)用成本的影響。一個(gè)中繼者可以實(shí)時(shí)观挎，無縫的方式維護(hù)要約簿琴儿。
中繼者記錄和轉(zhuǎn)播貸款要約獲得LST的代幣作為交易費(fèi)用。 貸方支付一定的費(fèi)用嘁捷，并在貸款被利用時(shí)借款人/保證金交易者也支付費(fèi)用造成。吸引流動(dòng)性進(jìn)入平臺(tái)，中繼者只有在貸款被有效使用并且合理關(guān)閉是才被支付普气。
中繼者甚至可以匹配從另外一個(gè)中繼者發(fā)出的請(qǐng)求谜疤。通過詢問進(jìn)行匹配， 盡管有激勵(lì)機(jī)制，并且中繼者也可以訪問整個(gè)共享借出池夷磕，但協(xié)議仍然是信任獨(dú)立的履肃，因?yàn)閮蓚€(gè)秘匙的0x引發(fā)的特性寫入了協(xié)議本身。
a.中繼者不能代表貸款人或保證金交易者執(zhí)行交易坐桩。他們只能推薦一個(gè)理想的訂單尺棋。
b.當(dāng)貸款被利用時(shí)，有明確的收費(fèi)結(jié)構(gòu)绵跷。 記錄訂單的中繼者由貸款人支付膘螟，一旦償還貸款，同一個(gè)中繼者由保證金交易人支付碾局。
2.2.3. 全球共享的資金池
由于協(xié)議固有的信任獨(dú)立性荆残，獲得貸款的機(jī)會(huì)不限于任何一個(gè)中繼者或者一個(gè)特定的Lendroid中繼者。作為一個(gè)延伸净当，平臺(tái)上的所有貸款人和保證金交易者都對(duì)生態(tài)系統(tǒng)的流動(dòng)性做出了貢獻(xiàn)内斯。
如圖3所示，貸款人可以自由地與協(xié)議上的任何一個(gè)參與者進(jìn)行交流像啼。無論他們將貸款提供給誰俘闯，都會(huì)進(jìn)入共享的貸款池。迎合保證金交易者時(shí)忽冻，一位中繼者可以免費(fèi)推薦從任何一位中繼者處獲得的貸款真朗。 為了提供一個(gè)“粘性”的體驗(yàn)，可以使他成為主要的互動(dòng)者僧诚，將貸款人或保證金交易者撮合到最理想的報(bào)價(jià)遮婶，并符合他的最大利益。
2.3保證金交易者
在lendroin上湖笨，保證金交易者在獨(dú)特的分步式的環(huán)境中享受杠桿借貸蹭睡。他存放抵押品，利用貸款人提供的貸款赶么，從事保證金交易/賣空。他開設(shè)了一個(gè)保證金賬戶脊串，在這個(gè)賬戶中辫呻，他可以自由更換頭寸或添加抵押品。在沒有貸款欠款的情況下琼锋，他可以撤回抵押品或清算其保證金賬戶放闺。
2.3.1. Locking in Collateral 鎖定在抵押品
Lendroid兼容任何基于ERC20的令牌。 這使得保證金交易者在抵押貸款的抵押品性質(zhì)方面具有高度的靈活性缕坎。一個(gè)保證金交易者可以自由存取他所選擇的代幣中的一種抵押品怖侦，但可以同時(shí)在相同的保證金賬戶中存入多種基于ERC20的代幣。 但是，除了兼容性之外匾寝， 在所設(shè)想的社區(qū)驅(qū)動(dòng)治理模式中搬葬，對(duì)代幣的支持還有其他一些考慮因素。該協(xié)議將基于代幣的當(dāng)前波動(dòng)性來添加或移除對(duì)代幣的支持艳悔。如果保證金交易者發(fā)現(xiàn)保證金賬戶的健康狀況已經(jīng)下降急凰，他可以在清算過程開始之前的任何時(shí)候添加抵押品。
2.3.2.有效貸款
如第2.1節(jié)所述猜年，保證金交易者可以通過他的中繼者獲得貸款抡锈。接口提供商致力于匹配一個(gè)理想的訂單。 訂單由相關(guān)貸款人簽署乔外，讓他們可以被中繼者使用床三。
當(dāng)一個(gè)保證金交易者發(fā)現(xiàn)一個(gè)適合他的需求的要約時(shí)，他通過該函數(shù)調(diào)用中包含該提供對(duì)象來調(diào)用貸款智能合約上的有效貸款功能杨幼。使用ecrecover函數(shù)撇簿，智能合約將驗(yàn)證簽名是否有效，并根據(jù)時(shí)間戳 推汽，確定該要約尚未到期补疑。
智能合約還檢查貸方的資金賬戶，以確保有足夠的資金來執(zhí)行該要約歹撒。 一旦批準(zhǔn)莲组，資金將記入保證金交易者保證金賬戶，并從貸方資金賬戶中扣除暖夭。
2.3.3. 保證金賬戶
開立保證金賬戶時(shí)锹杈，保證金交易者持有LST。當(dāng)交易者關(guān)閉交易頭寸并償還貸款時(shí)迈着，該股權(quán)可退還竭望。但是，如果賬戶低于清算水平裕菠，存款成為了牧馬人的賞金咬清。 在保證金賬戶中，如果不履行貸款條款奴潘，抵押品和頭寸都不能被撤回旧烧。然而，保證金交易者可以隨時(shí)操縱這兩個(gè)要素画髓，以獲得最大的回報(bào)掘剪。他可以在標(biāo)記帳戶中加入抵押品，并在分散的要約簿協(xié)議的幫助下校準(zhǔn)其頭寸奈虾。
a.最高權(quán)限的保證金帳戶包含他為交易借入的資金，以及可用資金之外的可能創(chuàng)建交易的頭寸的匾鸥。
b.我們看到保證金交易者已經(jīng)校準(zhǔn)了他的交易頭寸蜡塌。 這個(gè)意圖被記錄在鏈上，并且使用分散的要約簿協(xié)議來執(zhí)行扫腺。Lendroid能夠集成多個(gè)要約簿協(xié)議岗照，包括0x，Kyber笆环，Omega等攒至。 當(dāng)頭寸需要更新或重新安排時(shí)，保證金交易者可以將該功能委托給生態(tài)系統(tǒng)中最具流動(dòng)行的要約簿協(xié)議躁劣。
c.我們看到在交易時(shí)段結(jié)束時(shí)迫吐，交易頭寸對(duì)于保證金交易者來說表現(xiàn)良好，除了借入資本之外账忘，還有一筆利潤志膀。
2.3.4. 關(guān)閉貸款
貸款條款在出價(jià)開始時(shí)由貸方指定。 貸款關(guān)閉有三種情況鳖擒。
首先是圖4c中描述的場(chǎng)景溉浙。
保證金交易者已經(jīng)成功交易，能夠結(jié)清貸款蒋荚，無償?shù)貎斶€戳稽。 另外，即使保證金交易者沒有準(zhǔn)備好解除其交易頭寸期升，一筆或多筆貸款的期限也可能即將到期惊奇。監(jiān)督這個(gè)的任務(wù)可以委派給被稱為牧馬人（監(jiān)督者）的激勵(lì)參與者，他們將幫助替換或“回滾”新到期的貸款播赁。雖然沒有納入?yún)f(xié)議颂郎，但這個(gè)特定功能是牧馬人主要角色的合理擴(kuò)展 - 監(jiān)控保證金賬戶。 在第三種情況下容为，保證金賬戶表現(xiàn)不佳并需要立即采取行動(dòng)乓序。牧馬人已經(jīng)確定了賬戶。 然后坎背，牧馬人自己向貸款人償還貸款竭缝，并觸發(fā)拍賣保證金交易者的抵押品和頭寸。
第四種可能性較小的情況是黑天鵝事件沼瘫，其中一個(gè)保證金賬戶在牧馬人監(jiān)督者）和保證金交易人員無人看管的情況下，并且有足夠的時(shí)間由貸方自己造成損害咙俩。在這種情況下耿戚，貸款人可以收回他的貸款湿故，因此將接管并選擇撤銷抵押品和交易頭寸作為補(bǔ)償。
2.4THE WRANGLER 牧馬人（監(jiān)督者）
是Lendroid生態(tài)系統(tǒng)概念化的實(shí)體膜蛔。 在協(xié)議中的兩個(gè)激勵(lì)角色之一坛猪，牧馬人（監(jiān)督者）執(zhí)行是一個(gè)計(jì)算密集型的角色：監(jiān)控保證金賬戶。牧馬人（監(jiān)督者）通過監(jiān)控和“終結(jié)”終端帳戶（在清算水平）維護(hù)生態(tài)系統(tǒng)的總體健康狀況皂股，同時(shí)保護(hù)貸款人的利益墅茉。然而，這種處理能力的應(yīng)用超出了協(xié)議的要求呜呐，并且他可以提升（增強(qiáng)）其他參與者的經(jīng)驗(yàn)就斤。
2.4.1. Margin LevelMonitoring 保證金水平監(jiān)測(cè)
在協(xié)議上的每個(gè)鏈上交易事件的廣播。 由牧馬人（監(jiān)督者）調(diào)入廣播蘑辑。 牧馬人（監(jiān)督者）密切關(guān)注每一個(gè)發(fā)展?fàn)顟B(tài)：從保證金賬戶的創(chuàng)建洋机，到每個(gè)頭寸的變化情況，洋魂，抵押品的增加等绷旗，直到賬戶被清算。
每當(dāng)由于從Lendroid智能合約系統(tǒng)調(diào)用一個(gè)功能函數(shù)而導(dǎo)致保證金賬戶狀態(tài)發(fā)生變化時(shí)副砍，賬戶智能合約會(huì)觸發(fā)一個(gè)事件通知和指定功能函數(shù)名稱和相應(yīng)的保證金賬戶衔肢。
為了準(zhǔn)確和發(fā)現(xiàn)的情況計(jì)算豁翎，牧馬人（監(jiān)督者）需要鏈上和鏈下數(shù)據(jù)角骤。重要的是要注意保證金監(jiān)控一直是被作為風(fēng)險(xiǎn)管理的一個(gè)方面，迄今為止由集中交易所進(jìn)行谨垃，以保護(hù)貸款人的利益和市場(chǎng)的完整性启搂。傳統(tǒng)的交易所會(huì)進(jìn)行所謂的“保證金追繳” -當(dāng)賬戶低于一定的杠桿比例時(shí)， 一個(gè)真正的電話打給交易者刘陶，要求他存入額外的金額胳赌，，由于追加保證金概念是不可能在區(qū)塊鏈生態(tài)系統(tǒng)中匙隔，牧馬人的角色對(duì)于市場(chǎng)的健康變得更加重要疑苫。這就是牧馬人（監(jiān)督者）以計(jì)算能力為動(dòng)力的角色以創(chuàng)新的方式獲得激勵(lì)的原因。
例如纷责，如2.3.4所示捍掺，牧馬人（監(jiān)督者）可以通過貸款人收取費(fèi)用 - 不僅監(jiān)控賬戶，而且還可以幫助處理要到期的貸款和新貸款再膳。牧馬人（監(jiān)督者）在“清算”帳戶時(shí)收取賞金挺勿。當(dāng)他觸發(fā)拍賣時(shí)，他也有權(quán)獲得保證金交易者的抵押品或其交易頭寸喂柒。
2.4.2. Triggering an Auction 觸發(fā)拍賣
牧馬人（監(jiān)督者）一旦確認(rèn)了某個(gè)保證金賬戶需要終止不瓶，則會(huì)贏得了該保證金賬戶附加的獎(jiǎng)金禾嫉。然而，在這種狀況下還存在一定的風(fēng)險(xiǎn)蚊丐。牧馬人（監(jiān)督者）不能獲得抵押的代幣或者對(duì)保證金賬戶的持倉進(jìn)行清算熙参， 只有保證金賬戶有權(quán)進(jìn)行操作。 因此監(jiān)督者需要啟動(dòng)一個(gè)競(jìng)爭(zhēng)拍賣拍賣過程麦备。該過程需得到Lendroid 智能合約系統(tǒng)確認(rèn)孽椰，以及其他監(jiān)督者的確認(rèn)，并通過獨(dú)立的市場(chǎng)信息來對(duì)索賠進(jìn)行審查凛篙。 詳細(xì)的拍賣過程將在后面的一節(jié)中描述黍匾。
（備注：此處翻譯語句不通暢，請(qǐng)大神幫忙修改）
白皮書地址：https://www.lendroid.com/
Lola
區(qū)塊鏈研習(xí)社精英群成員
2018.02.04 今日立春?
祝福一切重生的鞋诗，迭代的膀捷，歸零的，新紀(jì)元開始了削彬，我看到了你們與我一起全庸，都在路上.......
--------------------------------------------------------------------------------
