Consider equity settlement option and handle legacy entries without links #1

New issue

Open

opened 2026-01-02 18:42:16 +00:00 by padreug · 0 comments

padreug commented

2026-01-02 18:42:16 +00:00

Owner

Summary

Two related items to investigate regarding settlement flows and data cleanup.

1. Equity Settlement Option

Currently when Castle owes a user (liability), settlement options are:

Lightning payment
Manual cash/bank payment

Question: Does it make sense to add an option to settle liabilities to equity instead of paying out?

For example, if Castle owes a member 50 EUR, they could choose to convert that to equity in the project rather than receiving payment. This would:

Debit Liabilities:Payable:User-{id}
Credit Equity:MemberEquity:User-{id}

This could be useful for co-living/collective scenarios where members want to reinvest their balance into the project.

2. Legacy Entries Without Links

There are existing entries in the ledger that have postings to Liabilities:Payable accounts but were created before we implemented the ^exp-{id} and ^rcv-{id} link system.

These entries:

Cannot be matched by the get_unsettled_entries_bql query (which filters by link pattern)
Won't be linked when settlements are created
May cause confusion in balance tracking

Questions:

Should we backfill links for these legacy entries?
Or handle them as a one-time migration/cleanup?
How do we identify which are truly unsettled vs already settled?

Next Steps

Audit existing entries without proper links
Determine if equity settlement is a desired feature
Design migration strategy for legacy data if needed

## Summary Two related items to investigate regarding settlement flows and data cleanup. ### 1. Equity Settlement Option Currently when Castle owes a user (liability), settlement options are: - Lightning payment - Manual cash/bank payment **Question:** Does it make sense to add an option to settle liabilities to equity instead of paying out? For example, if Castle owes a member 50 EUR, they could choose to convert that to equity in the project rather than receiving payment. This would: - Debit `Liabilities:Payable:User-{id}` - Credit `Equity:MemberEquity:User-{id}` This could be useful for co-living/collective scenarios where members want to reinvest their balance into the project. ### 2. Legacy Entries Without Links There are existing entries in the ledger that have postings to `Liabilities:Payable` accounts but were created before we implemented the `^exp-{id}` and `^rcv-{id}` link system. These entries: - Cannot be matched by the `get_unsettled_entries_bql` query (which filters by link pattern) - Won't be linked when settlements are created - May cause confusion in balance tracking **Questions:** - Should we backfill links for these legacy entries? - Or handle them as a one-time migration/cleanup? - How do we identify which are truly unsettled vs already settled? ## Next Steps 1. Audit existing entries without proper links 2. Determine if equity settlement is a desired feature 3. Design migration strategy for legacy data if needed

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: aiolabs/castle#1

No description provided.

Rows
Columns