Auto Top-Up Feature Redesign

[ygrishajev]

The Auto Top-Up feature redesign aims to provide users with granular control over their deployment funding mechanisms. Instead of the current one-size-fits-all approach where enabling auto top-up affects all deployments, users will have the flexibility to manage top-up settings on a per-deployment basis. This change addresses key user concerns about fund distribution control and prevents scenarios where high-cost deployments could unexpectedly drain wallet resources. The new system will allow users to strategically allocate their funds by choosing which specific deployments should receive automatic funding and for how long, while maintaining the simplicity of the master wallet grant mechanism. For managed wallet users, this introduces needed flexibility in controlling their deployment costs. The redesign also improves visibility into funding status through new notification systems, helping users better manage their deployment resources and prevent unexpected service interruptions.

Current Behavior

• Auto top-up works as a global setting for all deployments
• Users grant permission to master wallet for deposits
• Managed wallet users have this enabled by default with no opt-out
• All deployments are automatically topped up to maintain a 7-day runtime buffer
• No flexibility in adjusting the runtime buffer period per deployment

Issues Identified

1. Users want selective control over which deployments get auto top-up and for which expected runtime duration
2. High-cost deployments can drain wallet funds

Implementation Requirements

1. Database Changes

Create new table user_deployment:

• Fields:
  • user_id (FK)
  • address (VARCHAR)
  • deployment_id (FK)
  • auto_top_up_enabled (BOOLEAN)
  • target_runtime_duration (BIGINT) (milliseconds)

2. API Implementation

New REST endpoint: /v1/deployments

• Methods: GET, POST, UPDATE, DELETE
• Query parameter: userId, address
• Settings should be validated against on-chain data (balance, grant)
• Response should include all user-specific deployment settings

3. UI Changes

Settings Page

• Retain existing top-up grant form
• Add disclaimer about per-deployment settings

Deployment Details Page

• Add auto top-up widget
  • Should have a toggle
  • Should have a target_runtime_duration modifier
  • Show current auto top-up status

Deployment List Page

• Show auto top-up status indicator

4. Validation & Notifications

Client-side Validation

• Verify grant status before enabling
• Check wallet balance against deployment costs
• Validate duration settings

Warning System

Implement notifications for:

• Low balance warnings
• Grant expiration alerts
• Multiple deployment funding risks
• Display warning indicators on:
  • Deployment details page
  • Deployment list view

5. Top-Up Job Rework

Current Behavior Modification

• Replace global setting check (grants from on-chain) with per-deployment database records
• Job should only process deployments where:
  • auto_top_up_enabled = true
  • should use settings from db to calculate the amount

[anilmurty]

Couple questions:

1. target_runtime_duration modifier - to confirm, this would translate to a input field where the user can select the number of hours of run time desired
2. Warning System (notifications) - is this to the user or to us (people managing console)?

[baktun14]

This is great!

• deployment_id = dseq? Little detail but I think it should be dseq since they're in a separate db.
• The warning system could be done in a separate iteration and leverage the blockspy notification service
• target_runtime_duration yea same question, it means the total duration or until the next auto top up?

[ygrishajev]

@anilmurty

1. target_runtime_duration modifier: the point of the feature keeping the deployment alive. the issue we faced is that the expected runtime might be too long (7 days) and it'll eat all the funds. So this field is to set this period to a custom value, so users would control how much would it deposit. Reducing the time would increase the frequency of top un.
2. Warning System (notifications) - is this to the user or to us (people managing console)? - yea, I was thinking of just some toast notification when it's open

@baktun14

• deployment_id = dseq - yea
• all of it should go iteratively, I'll do my best to push in chunks

[anilmurty]

Decision after discussion during weekly sync

• Toggle + Hardcoded top up duration
• Default toggle: OFF (checkbox next to “add funds” as a placeholder for now - unless @aktdenis has a better idea)
• Default duration: 3 hours

[aktdenis]

@anilmurty @ygrishajev just to get on the same page, is this what you had in mind?

[ygrishajev]

@aktdenis yea, smth like this 👍

[aktdenis]

@ygrishajev sharing these from a while ago if you find them useful...

dialog

settings

[baktun14]

@aktdenis That's great, I think the auto top-up list won't be necessary as we'll just add it to an option in the deployment list.