Skip to main content
A tokenised repurchase agreement (repo) is a two-part transaction where one party sells a tokenised bond to another and agrees to repurchase it at a later date, typically at a slightly higher price. It is one of the most common instruments in fixed-income markets. KeyStone handles repo as two linked DvP settlements - an opening leg and a closing leg. What happens between legs is not KeyStone’s concern.

​
KeyStone’s role in repo

KeyStone settles both legs of a repo. The period between legs - collateral management, yield strategies, rehypothecation - is the counterparties’ business.

​
What KeyStone does NOT do for repo

  • Lock collateral for the repo duration (that is lending - Aave Horizon does this)
  • Monitor collateral ratios (that is lending)
  • Handle margin calls (that is lending)
  • Enforce repayment (that is between the counterparties)
  • Liquidate on default (that is between the counterparties)

​
Lifecycle

​
How Aave Horizon composes

Aave Horizon is a pooled lending protocol for institutional RWA collateral. KeyStone is atomic settlement infrastructure. They are fundamentally different products that compose naturally:
  • KeyStone settles both legs of the repo (opening DvP and closing DvP)
  • Between legs, the lender optionally deposits the received bond into Aave Horizon to earn yield during the holding period
  • Collateral management (margin monitoring, haircuts, liquidation) is NOT KeyStone’s concern
  • Default enforcement follows the same model as TradFi repo: bilateral legal agreements govern

​
Trade types

Settlements carry an optional trade_type field:

​
Maturity handling

Maturity is derived from the opening settlement’s repo_terms: it falls tenor_days after the opening settlement is created. When the opening settlement finalizes and maturity arrives, KeyStone automatically creates the closing settlement; each closing payment leg derives its amount from tenor_days, rate_bps, and its own opening quantity, floored to an integer base unit (quantities are base units throughout). The closing runs under the opening’s pinned template config and pins the same template_version itself. A repo is one economic transaction with two legs separated in time, so editing the template between opening and maturity never changes the rules the close leg is derived or executed under. A closing is derived only while every party environment is active. Deactivating an environment closes it to new settlements, so a matured repo with a party in a deactivated environment is skipped by the maturity check (and refused by the manual trigger with 409 ENVIRONMENT_DEACTIVATED) until the environment is reactivated. Maturity does not expire: the closing is derived on the first check after reactivation. Manual trigger: Administrators can trigger maturity early via the admin API:

​
Leg reversal at closing

When the closing settlement is created, the legs from the opening settlement are reversed: The closing settlement goes through the full compliance and escrow flow independently. Compliance is re-screened because parties may have been sanctioned between opening and closing.

​
Default scenario

If the borrower does not show up for the closing leg:
  • KeyStone records the failed settlement
  • The lender already has the bond (from the opening DvP)
  • Legal recourse governs (bilateral agreement between institutions)
  • Legal agreements between the counterparties handle defaults
A repo is not a single settlement with two phases. It is two independent settlements linked by a parent-child relationship. Each settlement has its own events, its own escrow, and its own compliance checks.