先重温一下三个基本原则:

1. 账号的单边性----密钥持有者可以证明账户是自己的，也可以假装不是（遗弃账号）；

2. 总体余额非负----相互绑定的账户总价值不能为负：其中可以存在负余额的账户，但总和必须为正。而不与其他账户绑定的单个账户，是不能出现负余额的。否则账号会被遗弃；

3. 账户的非经济价值----之所以存在无抵押的纯粹信用贷，依靠的是大量“非经济”账户。一定程度上说，这些无变现价值的账户，成为了一种特殊的抵押物，

第一个模式中，借款的安全性是依靠在账号内放置抵押物的方式完成的。

基于抵押的借款

这种模式的一个明显的限制是，只能用于有明确经济价值的资产，比如各种token。

第二种模式：抵押账户的非经济价值

如果能认可账户的非经济价值，那么就有理由相信，即使账户的显性资产低于负债，只要它有足够的隐形价值，就不会违约。这也可以减轻对传统抵押物的依赖，实现“信用借款”。

第二种模式

链上的账号有哪些可能的隐形价值呢? 大概可以有这么几类

1. 历史意义： 比如前N个区块的矿工账号（这甚至被认为是证明谁是中本聪的证据之一）；使用超过N年的账号（对标QQ号）；某些大型时间曾经使用的账号...因为区块链本身时间还比较早，这一块的价值才刚刚开始被大家认识。但是参考千年来对古董和收藏品的热情，相信会有越来越多的“历史意义”被挖掘出来；
2. 账号特性： 比如以特殊字符开头的账号。有些人为了地址更容易被人识别，很早就开始专门生成一些这样的账号（类似QQ的生日号）。这类东西由于稀缺性也好，POW也好，应该是有一定价值的；同时，随着技术的发展和升级，可能会对某些部分做升级，可能某些feature会变成“限量”----比如以太坊未来要取消个人账户跟合约账户的区别，这会不会导致个人账户成为限量版？
3. 外部权限： 以太坊的合约权限控制大部分都是按照账号来做的，也就是说，某些账号可能成为了其他项目/DAO的“owner”，“admin”，“abitrator”，“board member”，“contributor”。这给了这些账号一些普通账号不具备的权限----比如某机构的决策需要这个账号同意才能生效，更极端的例子，这个账号可以增发某token。这些权限显然有某种价值。

账号的隐形价值

以上只是目前能看到的一些例子，随着币圈的发展，应该还会有更多的隐形价值被创造出来，这些都使得了账号本身可以成为非常好的抵押物---即使它本身并不存在什么直接的显性资产。

为了完成这一点，我们可以一开始在定义账号的时候，就在里面预留一个“可抵押”接口---这种抵押并不是针对任何资产，而是针对账户本身：

• 没有抵押的情况下，账户可以像普通账户一样任意使用；
• 如果设置抵押，账户的操作就受到限制，需要抵押权人批准方可执行；
• 还款可以自动解除抵押；
• 到期不能还款，账号控制权转给抵押权人（有点类似典当）；

比如下面的合约就能实现这些简单功能（伪代码，别纠结语法）：

contract pledgable{ 
   address owner;//控制人
   address pledgee;//抵押权人
   uint debtAmt;//债权金额
   date deadline; // 到期时间，如果到此时还没有解除抵押，抵押权人获得账号控制权。
   string status;  //当前状态
     
   //这三个变量用来对外发送任意请求；
   address requestContract; 
   string requestFunc;
   bytes requestParam;
   
   modifier onlyOwner{//只有控制人能执行的函数
     require(msg.sender==owner);
     _;
   }
  modifier onlyOwner{//只有抵押权人能执行的函数
     require(msg.sender==pledgee);
     _;
   }

  function pledged(){ //新建
    owner = msg.sender;  
    status="unpledged";//尚未抵押
  }
  function setPledgee(address _pledgee, uint _debtAmt, date _deadline) onlyOwner{ //前一次抵押解除后
    //这个账户可以被再次抵押给不同的人；
     require(status=="unpledged");//只有解除当前抵押以后才能修改；
     pledgee=_pledgee;
     debtAmt=_debtAmt;
     deadline=_deadline;
  }
  function register() payable{//抵押权人支付一笔借款金额，这个账户被用作抵押；
    require(msg.sender=pledgee);//确认抵押权人；
    require(msg.value=debtAmt); //确认金额
    pledgee.transfer(debtAmt);//金额转给控制人账户（其实不一定这样做）
    status="pledged";    
  }

  function funcRequest(address _requestContract, string _requestFunc, bytes _requestParam) {//抵押权人请
    //求发送指令
    requestContract=_requestContract;
    requestFunc=_requestFunc; 
    requestParam=_requestParam;   
    if(status=="unledged") // 如果没有抵押，直接运行。否则等批准
      sendRequest();   
  }

  function approve() onlyPledgee{ //批准发送对外请求，只有抵押权人能做
    sendRequest();      
  }

  function sendRequest() internal{ //发送请求
    contract.func(param);//这只是个伪代码。实际的代码比较复杂，可以参考uport的实现
    requestContract=0;
    requestFunc="";
    requestParam=0;
  }
  function release() payable onlyPledger{ //抵押权人还款并解除抵押；
    require(debtAmt==msg.value); //确认还款金额
    pledgee.transfer(debtAmt); // 将这笔还款转给抵押权人
    pledgee=0;
    status="unpledged";// 改变状态   
  }

  function foreclose() onlyPledgee{ //到期未能赎回，账号归抵押权人所有；
    require(today > deadline); //确认已经到期； 
    owner = pledgee; // 账号变成抵押权人的了；
    status="unpledged"; //因为所有权已经转移，也就不存在抵押了。
  }
}

如果Alice有一个可抵押账号A，

在这一种模式是，我们实现了一个不依赖显性资产抵押的借贷模式。
账号的隐形资产成为了借贷的基础。

这种模式也有一定的局限性，最大的限制是要求一个账号拥有足够的隐形价值。

待续...
下一部分会讨论如何增加账号的隐形价值