This post is made out of 2 parts (Onboarding of new clients & complex transaction model) for which we need help with.
Topic 1: Onboarding of new clients (10,000+ accounts)
We would like to set up accounts for our users where we opt-in USDC asset and then trustlessly assign them out via Rekeying, so they can import the set up account to Pera Wallet via 25-word mnemonics.
1. Creating accounts:
Can we create 10K+ accounts at once or is there any manual action required for each account that would make this process cumbersome?
2. Opting-in assets:
To what degree can we opt-in USDC asset via atomic transfers? How many accounts could we group together per atomic transfer? Will we have to sign each transaction for the opt-in to USDC asset manually (from the receiver side)?
3. Distributing mnemonics:
To what degree can we trigger the rekeying of the set up accounts automatically for when a user requests to receive the mnemonics for a set up account? Or could we rekey the set up accounts right away and trustlessly assign them in a later point of time to the new owner?
4. Security of mnemonics:
Is there a way that we can send the mnemonics to our clients via our platform, without us having access to their mnemonics?
Topic 2: Complex transaction model
With upcoming stablecoin regulations we want to prevent any sort of transaction flow that results in practicing escrow (holding assets on behalf of users) - which is globally regulated by most financial authorities and requires a respective fiduciary license.
We have a few ideas in mind on potential transaction flows for our use case but are not certain about feasibility and technical limitations and therefore ask for your support on this matter.
- John drafts a monetary Request to Silvio Micali’s Twitter handle on our platform
e.g. “500 USDC @silviomicali if you sing Happy Birthday to me on Twitter”
- John posts the Request, which will expire in 7 days. The 500 USDC + commission fees are locked away during this timeframe.
- Silvio creates an account on our platform, verifies his Twitter account and receives access to the said Request
- Silvio can accept/reject the Request, or miss the Request if he’s too late on taking action.
- For any further steps post-accepting the Request, the platform will function as an arbiter.
John sends USDC to an account of which no one owns the keys to (including us). The outflow of USDC will be triggered by the status of the Request on our platform. When status is missed or rejected, then USDC flows back to John’s account. When status is accepted, then USDC flows to a ⅔ multisig account (John, Micali, Platform), which will be created once Silvio has provided his wallet address.
Questions to Transaction Flow:
1. Escrow Dilemma: Can an account be set up so that no one has access to its keys anymore? or could we define a set of irrevocable rules which take away the power from us, so that we technically can’t run away with the USDC as a consequence? This would solve the escrow problem, since the funds wouldn’t be in our custody anymore. Please note that once John has committed to send his Request, he shouldn’t be able to withdraw from it by obstructing the business transaction. Therefore it would be desired that we don’t require John’s signatures for future transactions other than potentially making him vote in the process of a dispute (⅔ majority approval).
2. Types of Accounts:
What type of account to lock John’s USDC away would best suit our needs as mentioned above? e.g. Stateless Smart Contract, Logic Signature, Contract Account, Delegated Account? Any other type of account we are not aware of?
Instead of creating many such accounts for every single Request, could we set it up so that every inflow gets coupled with a multisig account which will be defined via our platform in a later point of time?
4. Multisig Accounts
Can we set up ⅔ multisig accounts, with only 2 predetermined signatures and the 3rd signature being added on later?
Any suggestions on adapting the flow to circumvent the escrow problematic is highly welcome!