Why is last channel's expiry different in Lightning Network Routes? Both in the Basic of Lightning Technology (BOLT) documents, and in the specification of lnd, there is a different treatment for the last channel in a route. In BOLT#2 it refers to a variable min_final_cltv_expiry:


  min_final_cltv_expiry is the minimum difference between HTLC CLTV timeout and the current
  block height, for the terminal case (C).


This value is 9, as opposed to 144 for cltv_expiry_delta.

This is most likely related with the output of a route when querying lnd, for example, suppose the route Alice -> Bob -> Carol -> Dave, routed from Alice:
the output is:

$&gt; lncli-alice queryroutes --dest=&lt;Carol_pubkey&gt; --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
  chan_id: &lt;id_chan_alice_bob&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 6
  expiry: 1443610
  amt_to_forward_msat: 6000
  fee_msat: 1
}
hops {
  chan_id: &lt;id_chan_bob_carol&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 5
  fee: 1
  expiry: 1443466
  amt_to_forward_msat: 5000
  fee_msat: 1000
}
hops {
  chan_id: &lt;id_chan_carol_dave&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 5
  expiry: 1443466
  amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001


Notice the last two hops have the same expiry value. Why is the last hop different with regard to the expiry?
After some searching through the BOLT documents and talking with the lnd slack community, I found an answer:


  B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
  neither charge itself a fee nor add its own cltv_expiry_delta, so it
  would use C's requested min_final_cltv_expiry of 9. Presumably it
  would also add a shadow route to give an extra CLTV of 42.
  Additionally, it could add extra CLTV deltas at other hops, as these
  values represent a minimum, but chooses not to do so here, for the
  sake of simplicity:


Also, although cltv_expiry_delta is default to 9 in BOLT, in lnd they use 144, but without checking for the final hop. That is, they do not add the final_cltv_expiry because they have already a big cltv_expiry (I presume). Olaoluwa said in the slack 
that they plan to reduce the value of cltv_expiry_delta to get closer to the default value listed in BOLT. However, if they do this, I hope they take care of adding the additional cltv_expiry_delta, as it will be important to add in this case. For an example of what I mean, check the above-linked link for BOLT #007