Content
@
0 reply
0 recast
0 reaction
androidsixteen
@androidsixteen.eth
“Embedded wallet” is a funny marketing term. It borrows legitimacy from embedded systems, which suggests that the wallet is part and parcel of the application In reality, it’s a “hosted” wallet - the host (aka the SaaS provider) can revoke access to the wallet as soon as their customer (the app) stops paying
4 replies
0 recast
10 reactions
Henri Stern Ꙫ
@henri
Oh interesting — i hadn’t thought about embedded systems, for us was about the relationship to the product experience, trying to make onchain actions a natural part of user interactions. We actually wrote a bit about it at the time (https://www.privy.io/blog/embedded-wallet-launch) but iirc term was from @gaby
1 reply
0 recast
1 reaction
Henri Stern Ꙫ
@henri
There are really cool ways providers can ensure users can always access wallets, outage or not, payment or not (in our case this is why we have a lot operating client side)
1 reply
0 recast
1 reaction
androidsixteen
@androidsixteen.eth
I appreciate that context! The word "embedded" has hardware connotations for me IMO an embedded wallet would be something that lives in an HSM within a product (ie. what @faust is building) With hosted wallets, even if you allow access, security once comprised can't be recovered (please correct me if I'm wrong here!)
1 reply
0 recast
1 reaction
Henri Stern Ꙫ
@henri
Man -- I need to spend more time in hw. I have a lot of thoughts on the custody models of TEEs and HSMs fwiw. On the "security once compromised can't be recovered" it really depends on the compromise (same as for TEE or other archs) -- generally i think of bad tx submitted vs key compromise as the 2 big threats.
1 reply
0 recast
0 reaction
Henri Stern Ꙫ
@henri
Noob question but where can I read more on @faust's work -- big fan :D
1 reply
0 recast
2 reactions
