IoListWallet (WIP)

I’ve tried to start a project that should result in a multi-platform multi-chain, eutxo coin controlling
TxBuilder, with extreme customizability. It could work on smaller screens like mobiles or the little chrome app window, and on bigger screens you can build everything you want from it, including showing all your accounts in TxBuilder, all visible at the same time as either separate windows, or custom-docked into each other. All this GUI level is pretty much complete at this point, but actual wallet implementation is 0% from a build perspective. There are already a lot of scripts written for that blockchain era, but the content windows are not yet prepared for that. There is very litle that i thing should be done to the GUI, before is possible to show and edit enythign blockchain-related. If anyone would be willing to help, I’m welcoming anyone. Also do you think it would make sense to open a treasury request for? I’m pretty broke at this point and desperate to earn anything to at least survive with my work, and I just can’t handle working on this for completely free for that much longer, no matter how much I’d love to.

The wallet is heavily based on its two main types of panel structures: IoBook, and IoList, two main types of panels; both support sweeping gestures as well. IoBooks can have swappable pages (horizontally), and IoLists allow a complete search and filter to be done at every level. They can also be nested into each other.

So I’m deciding to finally open my GitHub repo for this whole thing public:

Project introduction
Name: IoList Wallet
Description: Codename: IoLost Wallet .Multi-platfrom + Multi-chain + Both Automatic and manual complex TxBuilder, open-source, hoping fot it to be eventually free not dependent of anything. And powerful enough that it could be used by anyone and do its best for simple people and detailed tinkerers.
Website: GitHub - SkrFractals/IoListWallet: Searchable-List based GUI for UTxO/eUTxO blockchain wallets, full coin control · GitHub
GitHub: GitHub - SkrFractals/IoListWallet: Searchable-List based GUI for UTxO/eUTxO blockchain wallets, full coin control · GitHub

I’f love to get any level of funding for some volunteer work
Reason: This is mostly inspired by P2PWallet and Eternl. I wanted to make something as powerful as P2P or even more. And also let users to pick between simple automated things like how Eternl does things, or detailed tinkering like how P2P wallet TxBuilder is. In fact Eternl 2.0 is not much closer to my idea of what my wallet should be capable of. Except it will be free and open-source.
Project scope: Multi-Platform, Multi-Chain, UTxO, both customizable to extreme tinkerer detail all in one transaction, and easily automatic, that will do many of such things for you and just generate the ideal transaction.
Paid or voluntary:I wish

1 Like

This is an ambitious interface concept, particularly the separation between automated use and detailed UTxO control.

Since the wallet implementation itself is still at an early stage, I think a narrow working vertical slice would make the project easier for contributors and potential funders to evaluate. For example: one platform, one blockchain, secure key storage, address derivation, balance discovery, transaction construction, review, signing, and broadcasting.

It would also help to document the security model before expanding the GUI further:

  • Where and how keys will be stored
  • Which signing and derivation standards will be supported
  • How chain-specific transaction logic will be isolated
  • How simple and advanced transaction modes will avoid producing unintended transactions
  • What automated tests, external review, or auditing process is planned

A working Cardano proof of concept with clear milestones may be more credible for a funding request than trying to deliver the full multichain scope immediately. The interface could still preserve the larger vision while the underlying wallet functionality is developed incrementally.

1 Like

Yeah i wanted to finish having at least some fake vertical slice (an offline blockchain replica just to test and show how the wallet parts would be structured), and it technically is very close to have such a slice implemented, but i jsut ran out of time to finish that.

Where and how keys will be stored

as there are no wallets implemented yet, nowhere. But the user data (which would later include the keys) are encryptable (that feature is already present, so far it’s optional, becaue if the user was using a HW wallet, then there’s no need to have you data encrypted under an unnecessary password, that’s one of my petpeeves when wallets require me to set a spending password even though I am only usign HW wallets)

Which signing and derivation standards will be supported

I guess as many as I or any volunteer would implement. So far it’s only the GUI engine with some prepared UTXO processing scripts.

How chain-specific transaction logic will be isolated

There’s root structures liek Network/Address/Utxo etc, and each chain derived their own child from these like Network_Cardano, Address_Cardano etc, whcih would implement anything that is unique to that specific chain in its virtual overrides. Of course it would be better to start with justone chain impemented, but the engine is built to be capable of supporting more later.

How simple and advanced transaction modes will avoid producing unintended transactions

What kinds of unintended transactions? Both automatic and precise coin control TxBuildingshould work just like the other wallets. In both cases you specify yourself what the transaction will do. The automatic parts woudl mostly be the coin control, like selecting inputs. Which does not normally affect what the transaction will actionably do.

What automated tests, external review, or auditing process is planned

To early to plan for testing of fetures that are not even fulyl implemented yet.

1 Like

By “unintended transactions,” I mean side effects that may not be obvious to the user. Cardano input selection can affect native-asset change, minimum ADA, fees, collateral, and privacy by linking UTxOs.

Even in automatic mode, the builder should verify every asset and output while showing users a clear summary before signing. The offline replica is useful for demonstrating the interface, but ledger-compatible transaction tests should begin early.

Hardware-wallet users may not store private keys locally, but addresses, balances, and account metadata can still be privacy-sensitive. Hope that clarifies what I meant.

change

I’d make the automatic selections so that it would take the optimal inputs to minimize the change movements and inputs (for smallest fees). There could be multiple strategies the user could select based on what they want to minimize etc.

minimum ADA, fees

Transactions with outputs below minADA should not even be allowed. AFAIK if you force one like that it will just eat that little extra as a fee. Which I’d detect and warn the user about if they selected the inputs like that, and the automatic selector would avoid that.

collateral

AFAIK you select which utxo you want to use as collateral, and the wallet should not use that an a normal input anymore.

privacy by linking UTxOs

for cardano that’s simple, delegated UTxOs simply aren’t private no matter how you use them. If there wasn’t any other way but to use a private undelegated address, then it might give a warning, or let the user set up how they want the set to be used, whether never, always, or only when asked, and whether it would be allowed to add any more inputs after a private undelegated one was selected. Bitcoin utxos might be treated as all undelegated. If you have any more ideas how to improve options for this privacy…

Hardware-wallet users

Some yes, some not, that’s why I would not enforce the encryption for HW only users, but they still can do that if they want. Encryption will hide all their data from anyone who’s not logged in. Perhaps it could also warn the user that they do not have the profile encrypted when they add any wallet (and tell that HW wallets do not need to be encrypted but it’s recommended for privacy).

…anyway i guess it might also be nice if i uploaded my TODO lists and plans that i have in txt files, to the github. reading those could make it more clear what the wallet is aiming for and what should be thenext steps to finish it. And how I planned to implement many things.

Uploading the TODO lists would help contributors understand the intended architecture and priorities.

For privacy, I would treat UTxOs as different levels of linkability rather than simply private or non-private. Delegated base addresses sharing a stake credential are already linked, but undelegated addresses can also be clustered through multi-input transactions, address reuse, change patterns, and balance queries.

Useful coin-selection options could include avoiding unnecessary UTxO merging, using fresh change addresses, grouping UTxOs by account or linkability, and warning when a transaction joins previously separate groups. Showing that privacy impact in the advanced transaction preview would also help users make an informed choice.

I guess I could allow the user to write some descriptions like what they are associated with. And let them group them into separate privacy groups. Both could be visible in the coin control, and the automatic input selector would respect the groups as well. Does any other cardano wallet even do anything like that? Well, it doesn’t matter it would be a cool feature to have either way.
Or maybe a simpler solution: each newly used output undelegated address woudl assign itself to a new privacy group, and aundelegated cahnge addresses in transactions that have another undelegated addresses coul get assigned the same privacy group as that undelegated input.