feat: add wallet-signed proof of life pings - #1052
Merged
ONEONUORA merged 1 commit intoAug 23, 2026
Merged
Conversation
anonfedora
added a commit
to anonfedora/InheritX
that referenced
this pull request
Aug 23, 2026
…ate plan update call Rebased fix/beneficiary-allocation-validation-1031 onto upstream/master to pick up Fracverse#1049 (wire frontend plans to the live API) and Fracverse#1052 (wallet-signed pings), which landed after this branch was created. Fracverse#1049 changed EditPlanPage.handleSaved to persist the panel's callback value via plansAPI.updatePlan(planId, updated) a second time, passing the full Plan object as if it were an UpdatePlanRequest. That no longer type-checks now that UpdatePlanRequest is a proper DTO, and it was always redundant: EditInheritancePlanPanel already calls plansAPI.updatePlan itself and hands the backend-confirmed plan back via onSaved. The page now just syncs local state with that result.
ONEONUORA
pushed a commit
that referenced
this pull request
Aug 24, 2026
…alidation (#1053) * fix(frontend): map full beneficiary list and enforce bps allocation validation CreateInheritancePlanPanel and EditInheritancePlanPanel only transmitted beneficiaries[0]?.name to the backend, silently dropping every other beneficiary's wallet address, allocation, and fiat off-ramp config. Separately, plansAPI.createPlan/updatePlan sent a request shape (title, fee, net_amount, bank_account_number, two_fa_code, ...) that never matched the real backend's Plan/UpdatePlanRequest contract at all. - plans.ts / inheritance.ts: CreatePlanRequest/UpdatePlanRequest now mirror the backend's actual Plan/UpdatePlanRequest structs (owner, token, amount, beneficiaries: PlanBeneficiaryRequest[], grace_period, earn_yield, yield_rate_bps); added the missing updatePlan() to inheritance.ts. - New BeneficiaryAllocationRow component centralizes beneficiary row UI, strict basis-point validation (must total exactly 10,000 bps), Stellar StrKey address validation, duplicate-address detection, and fiat anchor/daily-limit encoding shared by both panels. - Both panels now build and submit the full beneficiary list, surface clear per-field and total-allocation error messages, and correctly round-trip the backend's PlanResponse back into the UI. - Updated MSW mocks/tests to match the corrected contract. Closes #1031 * fix(frontend): rebase onto upstream live-API integration, drop duplicate plan update call Rebased fix/beneficiary-allocation-validation-1031 onto upstream/master to pick up #1049 (wire frontend plans to the live API) and #1052 (wallet-signed pings), which landed after this branch was created. #1049 changed EditPlanPage.handleSaved to persist the panel's callback value via plansAPI.updatePlan(planId, updated) a second time, passing the full Plan object as if it were an UpdatePlanRequest. That no longer type-checks now that UpdatePlanRequest is a proper DTO, and it was always redundant: EditInheritancePlanPanel already calls plansAPI.updatePlan itself and hands the backend-confirmed plan back via onSaved. The page now just syncs local state with that result.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
frontend: Implement Interactive Proof-of-Life Ping Widget and Dynamic Inactivity Countdown
Summary
This PR implements the missing Proof-of-Life Ping workflow for asset owners and improves the inactivity timer so that it updates dynamically after a successful ping.
Previously,
InactivityTimerCard.tsxonly displayed inactivity countdown information without giving the asset owner a way to actively confirm that they are still present. This meant the frontend lacked the required interaction for resetting the inactivity period and preventing an inheritance plan from progressing toward a triggered or claimable state.With this update, asset owners can now submit a wallet-authorized proof-of-life ping directly from the dashboard. Once the ping succeeds, the latest activity timestamp is refreshed and the inactivity countdown is recalculated immediately.
What Was Implemented
Interactive Proof-of-Life Ping
Added a Send Proof-of-Life Ping action to the inactivity timer interface.
The asset owner can now initiate a proof-of-life confirmation directly from the dashboard instead of relying on a static inactivity timer.
The flow now:
WalletContext.pingflow where applicable.Wallet-Signed Authorization
The proof-of-life action is tied to the asset owner's connected wallet.
For Ed25519-based wallets, the frontend can sign the generated proof-of-life challenge before submitting it to:
POST /api/plans/pingWhere the Soroban-based implementation is being used, the flow can instead authorize or invoke the corresponding smart contract
pingoperation.This ensures that simply clicking the button is not enough to reset the inactivity timer. The proof-of-life action must first be authorized by the wallet associated with the inheritance plan.
Dynamic Inactivity Countdown
The inactivity timer has been updated so that it no longer behaves as static dashboard data.
After a successful proof-of-life ping:
The countdown continues to display the remaining inactivity period based on the latest valid proof-of-life timestamp.
Loading and Submission States
Added appropriate interaction states around the ping workflow.
The interface now handles:
The Send Ping action is disabled while an existing ping request is being processed to avoid duplicate requests.
Error Handling
Failure states are handled without incorrectly resetting the inactivity timer.
If any part of the flow fails, including:
the existing inactivity state remains unchanged.
The inactivity deadline is only refreshed after a confirmed successful proof-of-life submission.
Asset Owner Dashboard Integration
The proof-of-life workflow has also been integrated into the main Asset Owner Dashboard.
The dashboard now:
WalletContext.API Integration
Updated the inheritance API layer to support proof-of-life submission through:
POST /api/plans/pingThe request can include the relevant information required by the backend, such as:
The API helper also normalizes successful and failed responses so that the UI can provide appropriate feedback.
Affected Files
frontend/components/plans/InactivityTimerCard.tsxfrontend/app/asset-owner/page.tsxfrontend/app/lib/api/inheritance.tsPOST /api/plans/ping.User Flow
The completed user flow is now:
Asset Owner Dashboard
→ View current inactivity countdown
→ Click Send Proof-of-Life Ping
→ Wallet authorization/signature requested
→ Challenge signed by the asset owner's wallet
→ Proof submitted to the inheritance API / Soroban contract
→ Proof validated successfully
→ Latest activity timestamp updated
→ Inactivity deadline recalculated
→ Countdown refreshes automatically
→ Plan remains active and is prevented from progressing toward the inactivity trigger
Validation
The implementation was validated against the expected successful flow:
Result
The inheritance frontend now provides a complete interactive proof-of-life experience.
Asset owners are no longer limited to viewing a static inactivity countdown. They can actively prove that they are still present through their connected wallet, and a successful proof immediately resets and updates the inactivity countdown shown throughout the dashboard.
This provides the frontend interaction necessary to support the inheritance protocol's proof-of-life mechanism and helps prevent valid asset-owner plans from unintentionally entering the triggered or claimable state.
Closes #1033