Time-delayed delegation tx rotation planning

[Marco]

Delayed rotations

Although f2lb initiative is great the periodic delegation rotation is
annoying and eventually it is a little "obstacle" for new supporters
more than spo members.

F2LB has a good ROS as a whole and could be very interesting for
plenty of ADA holders that want also to help with decentralization.

The F2LB main supporter, said:

I wish a Cardano wallet could set time-delayed delegations,
so I sign once and have it rotate through 4 or more pools
for the next 3 months. I've seen a Catalyst proposal to create
a smart contract that could do what F2LB does, but the problem
is that it will be a long time before I would trust any
smart contract to handle my retirement fund, LOL.

This issue is to design exactly that feature in the f2lb.bardels.me
website exposing a simple UI/UX like a "web page wizard" where anyone
can sign multiple tx that will be submitted in a sequential and
delayed way.

Design details

Cardano eUTxO allow this because the tx ID is/will be the hash of a tx
body and the outputs of tx will be the TX ID that generated plus an
integer index, this imply that is possible to have full control over
the UTxO that will be created in future and so be able to create TX
that will spend those (not yet existing UTxOs) to pay fees.

Taking advantage of this deterministic aspect of cardano implies that
we in advance have to define which UTxOs (also not yet exisnging) will
be used to pay the fee for the future delegation txs. Having
well-defined the UTxO for the first transaction we can "guess/define"
what will be the UTxO for the next tx and for each rotation we will
diminish the amount of ADA of the fee portion. For sake of semplicity
make sense re-use always the same address to pass the "fee payer UTxO"
across the delayed rotations.

This design assume (can work only) if the "designated" UTxO that
generate the list of "fee payer UTxOs", as any of the utxos in the
list, won't be spent by some other TXs. In that case the rotation
delegation tx will fail and so all the successive planned delayed
rotation will fail too.

With this approach is possible to "plan" future tx in a totally
non-custodial way without the needings of a smart contract.

The web site can prepare in advance N txs for future rotations and the
user can sign them one-by-one, the signed txs have to be stored on the
website server and submit during the right epoch according to the F2LB
queue.

In case the queue order, for the prepared/stored delayed rotations
signed txs, changes automatically the stored signed txs have to be
invalidated and potentially the signer user should be notified.

Bakend workflow and UX/UI

After a use connect the wallet to the website it can be recognized as
member, supporter or visitor. In any case the stake address of the
connected wallet can be considered as unique identifier of the
wallet/user. At that point a page for "delayed rotation plan" is made
available to the "authenticated" user.

Setup wizard

The web page should consist in a simple wizard with 2 steps:

1. configure general preferences, like: details about notifications,
   eventually tx submission timing configuration, and number of
   desired planning rotations.

2. present the "prepared" delegation txs with their own details and
   status, like:

   • stake address / stake public key hash
   • ticker / pool to delegate to
   • address and utxo used to pay fee with amounts
   • tx id (tx body hash)
   • signed/unsigned
   • submitted/pending/failed

   Also for each planned TXs should be possible:

   • to delete them, causing deletion of all the subsequent ones.
   • re-sign them, causing deletion and resign for all the the
     subsequent ones.
   • download as json (as it is stored on the backend) and/or
     just the CBOR HEX.
   • view parsed CBOR of stored signed tx

Backend workflow

On the backend-side we already have several timers to refresh the
Google sreadsheet or the caches through koios or again to push some
light information like the slot in epoch, generally these timers have
a variable frequency from 1 hour, 3 minutes, 1 minute and so on.

On the backend-side when a "delayed rotation plan" is submitted the
information from the "wizard" are stored on filesystem, especially
with this layout:

• <stake address> (dir)
• <stake address> / notify.json (file, preference from step 1)
• <stake address> / <tx id>.json (file, containing details and status,
  including cborHex of signed tx)

When a wallet is connected to the website this "delayed rotation plan"
fs tree is walked for the specific stake address and exising files are
parsed/cached, so that if the connected wallet user jump on the page
will see previously planned and stored txs and details.

On regular basis, the backend have to perform 2 main actions:

1. ideally on epoch transition (lets say at 100th slot in epoch), the
   backend will parse the fs tree and look for notify.json , and
   according to the preference of the user can send email/discord
   message to re-call the planned rotation for the starting epoch.

2. ideally after 2 days or so (lets say at 150000th slot in epoch),
   the backend will parse the fs tree and identify the signed tx to be
   submitted for each staake address/user that planned a delayed
   rotation. When everything planned is loaded start to submit signed
   tx and notify the corresponding signer user on the outcome, and
   update the status in the tx-related json file in fs tree.

The stored "delayed rotation transaction" json should contains
imformation such as:

• epoch to be submitted
• time to be submitted (close to TTL)
• stake address for the signer
• pool / ticker of the deletagion target
• user notification-related information/details
• status: signed,submitted, pending ...
• cbor hex of the signed tx, ready to be submitted
• ???