# Contract-level Relative Timelocks (or, let's talk about ancestry proofs and singletons)

**URL:** <https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353>\
**Category:** Protocol Design\
**Created:** [January 2, 2025, 3:00pm UTC](https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353 "2025-01-02T15:00:14Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![ademan](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ademan/32/337_2.png) [@ademan](https://delvingbitcoin.org/u/ademan)\
**Post date:** [January 14, 2025, 2:38pm UTC](https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353/17 "2025-01-14T14:38:30Z")

</div>

> [@reardencode](#):
>
> I think settlement can be made immediate on the last allowed update in an @ademan channel

That’s right. For simplicity the last update follows the same format as the previous ones right now, but I think you could even “inline” the settlement transaction into the last update. For N=2 this looks a lot like Daric actually (probably not coincidentally).

I think this strategy gives you a `(N - 1) * shared_delay` at best, since every party still needs a chance to update in the worst case.

---

_[View the full topic](https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353)._