Point Time Locked Contracts (PTLC)

Development ╰ Funding | Submissions
1

Project Name: Point Time Locked Contracts (PTLC)

Description: A PTLC locks funds to a point on an elliptic curve instead of a hash. Whoever proves the secret behind the point before expiry is paid; after expiry the creator reclaims. It is how NoM swaps with Bitcoin by scriptless scripts: on Bitcoin only an ordinary Schnorr signature ever appears, and the two legs cannot be linked.

This proposal takes George’s 2023 contract (PR #13) and 0x3639’s hardening of it to a reviewed, mergeable pull request against dev: go-zenon #138, 31 commits, +5,034 lines, every contributor’s commits preserved.

Why it matters for Zenon: Bitcoin interoperability with no bridge and no custodian, which the official Phase 1 scope lists under Accessibility. The spork id (e59f1e97…) already exists on mainnet, created and never activated, so activation is one ActivateSpork once operators upgrade.

URL:

Team:

  • sol: port to dev, third point type, destination rules, review fixes, tests, lab
  • 0x3639: hardening branch (9 commits, 3,400 lines of tests), two review rounds on #138 (1, 2)
  • edgepillar: ptlc-research (offline BTC⇄ZNN swap study, Taproot claim/refund, nonce journal, the KingGorrin key-share leak reproduced), review on #13, review on #138
  • George: original design and contract. Already paid; nothing is requested for that work here.

What changed since George’s PR #13

PR #13 (George, 2023) PR #138 (now) By
Base master, 2023 dev @ c64ed62, own ptlcSporkBit; same mainnet spork id sol
Unlock on a bad witness one branch failed open fails closed 0x3639
Unlock message SHA3(id ‖ destination) SHA3-256("zenon-ptlc-unlock:v1" ‖ chainId ‖ contract ‖ pointType ‖ id ‖ destination): no replay across networks or contracts 0x3639
Stored entries, BIP-340 keys not checked checked on read, key validated at Create 0x3639
Point types Ed25519, BIP-340 + secp256k1 point (witness is the scalar t, Lightning’s shape) sol
Recipient any, chosen at unlock Create can fix a destination; required for scalar locks, where a revealed t could be front-run sol
Payable addresses any non-zero user-type only, checked at create, in storage, at send and at payout (32aa4e4, c239afa) sol, raised by 0x3639 and edgepillar
Witness size unbounded at send: a 1 MB send block for flat plasma 32 or 64 bytes, refused at send (b877caa) sol, raised by 0x3639
Ed25519 small-order lock keys accepted (anyone can unlock) refused (6e33447) sol, raised by 0x3639
Late contract receive untested pinned to the confirming momentum (45e1bbb) sol, raised by edgepillar
Tests unit + adversarial, fuzz, spork boundary, mock-chain swaps on key locks and point locks 0x3639, sol

Phases

Phase 1: Contract ready for merge (delivered)

  • :white_check_mark: PR #138 open against dev, trial merge clean
  • :white_check_mark: Every item from 0x3639’s and edgepillar’s reviews fixed; 0x3639’s re-review closes all six and verifies by execution
  • :white_check_mark: NoM⇄NoM and NoM⇄BTC (regtest) swaps run end to end, including refunds

Phase 2: Mainnet

  • PR #138 merged and shipped in a release
  • Dart SDK and CLI pull requests (branches exist, BIP-340 adaptor signatures tested against the official vectors)
  • ActivateSpork in the community spork window (opens ~2026-11-03), after operators upgrade
  • One NoM⇄BTC swap settled on both mainnets

Completion: the spork enforced on mainnet and the swap’s transactions linked here.

Funding

Total Requested Funding = 5,000 ZNN and 50,000 QSR

Phase Request sol 0x3639 edgepillar
1 (delivered) 3,000 ZNN / 30,000 QSR 1,800 / 18,000 600 / 6,000 600 / 6,000
2 2,000 ZNN / 20,000 QSR 1,200 / 12,000 400 / 4,000 400 / 4,000

Project Duration: Phase 1, 2026-10-07 to 2026-10-11. Phase 2 follows the merge and the spork window.

Budget: a maximum-size project, the same as the SDK and CLI updates and the professional documentation. The contract is the smaller half of the work; the reviews, fixes and tests are what make it safe to activate.

Other Information

Risks and dependencies:

  • Merge and release are the go-zenon maintainers’ call.
  • Activation needs the community spork key inside its window (PR #101).
  • Ed25519 signatures are checked with Go’s ed25519.Verify (cofactorless, not ZIP-215). A counterparty should verify with the same rule (mrstockholmz).
  • No wallet support yet: swaps run from the CLI or the console.

Previous proposals:

1 Like
2

I think PTLC is one of the more meaningful protocol improvements Zenon can make, especially when it comes to Bitcoin interoperability.

What makes this proposal particularly compelling is that we’re not funding an idea from scratch. George’s original work has been brought forward, hardened through multiple review rounds, integrated with the current dev branch, and exercised through actual contract and swap tests.

HTLCs remain useful, but PTLCs open up possibilities that hashlocks cannot provide in the same way. Adaptor signatures, Schnorr-compatible settlement, and the ability to avoid exposing a shared hash preimage across both chains are particularly valuable for Bitcoin interoperability. Doing this without introducing a custodian or bridge committee fits Zenon’s architecture very well.

I’ve been involved on the research and review side, and one thing I particularly appreciate is how the review findings have translated into concrete protocol improvements. Domain-separated signatures, bounded witnesses, small-order Ed25519 key rejection, fixed destinations, stricter recipient validation, and the delayed-receive/expiry tests are not cosmetic changes. They address real failure modes.

The distinction I would emphasize going forward is that a secure PTLC primitive is not automatically a secure atomic-swap protocol.

The client still has to enforce the correct funding sequence, adequate cross-chain timelock margins, nonce safety, counterparty verification, durable session state, and reliable recovery. Even a rejected unlock can expose its witness, which makes timing and transaction-state handling especially important.

For Phase 2, I would prioritize reproducible SDK/CLI test vectors, clearly documented swap safety requirements, operator upgrade readiness, and verifiable mainnet settlement. I’d rather see these foundations established properly than rush into broader wallet integration.

It’s also encouraging that the existing mainnet spork can provide an activation path once the implementation is merged, released, and sufficiently deployed. Of course, that decision should remain with the maintainers and the community spork process.

Credit to George for the original design, 0x3639 for the extensive hardening and verification work, and sol for bringing everything together into a practical, mergeable proposal.

As one of the listed contributors, my support should be understood in that context rather than as an independent security certification.

I support funding both phases. The remaining milestones are concrete and verifiable, and I believe PTLC can become an important foundation for trust-minimized interoperability between Zenon and Bitcoin.

1 Like