Additional Account Constructors
It's fairly easy to pull the Cardano walletApi from the web. With that, you can get:
- Reward Address
- Change Address
- Utxos
- Used Addresses
- Collateral
- Masked Balance
You can then send that information to a back end service to create a transaction, send the hash to the front end to be signed, and then send the signature back to the back end and submit the transaction.
The way the Account object is setup, you either have to create a new wallet, or import a wallet using the words.
For security purposes, this would be way better than creating the tx on the front end.
@fisherstevenk
As you mentioned, currently an Account object can be generated from a mnemonic or a root private key. And from that, it derives address at a given derivation path or the default derivation path. The original goal of Account class was to provide a simple abstraction over address derivation and txn signing, so we somehow need private key for that. But that's only valid for accounts which are maintained in server based on use cases, definitely not for end user accounts.
But Account object is not required for transaction building. Also txn signing can be done directly through private key or secret key etc and there are apis available for that.
So as per my understanding, you requirement is as follows. Let me know if I misunderstood your requirement
Wallet api sends connected address (Browser) ----> Java Backend to build transaction -----> Wallet api sign transaction (Browser) -----> Java Backend post txn to network
The above flow can be easily done with existing apis. The exact flow is currently being used in different multisig mintings. So basically, wallet api sends user's address to the backend and then backend builds the transaction using sender as user's address. Built transaction is sent to browser for txn signing and then the signature is sent back to server.
Now, in the server you can re-assemble the transaction with the user's signature and additionally sign with your own account/secret key if required (usually required for multisig minting) and submit the transaction.
You can check the below link which follows the above steps (multisig minting). There are are two methods in this class. One to build the transaction and another one to assemble and submit.
https://github.com/bloxbean/bloxbean-playground/blob/master/src/main/java/com/bloxbean/playground/minter/MinterService.java#L68
If you want to see it in action, you can try this demo with a prepod account and Nami wallet https://playground.bloxbean.com/
Hope that helps.
I appreciate the reply, thank you. I looked through the examples. It still just seems to be a lot easier (as a user of your library) to simply allow access to those variables via the constructor. As you mentioned, you don't need the private key to make a tx.
I'm fairly new to your project, so there's that piece. I was just having a really hard time following the logic flow with all the different modules/projects.
Thanks @fisherstevenk
It still just seems to be a lot easier (as a user of your library) to simply allow access to those variables via the constructor.
Can you provide some sample code snippet how you want to access these variable or use in an ideal scenario ? Don't worry about the accuracy. I just want to confirm my understanding about your requirement is correct.
I was just having a really hard time following the logic flow with all the different modules/projects.
Agree. We need more step by step tutorials. I will try to add a tutorial with a simple use case to the doc site.