It seems to be a really bad idea to bring shady projects and known liars like Acala on board.

I think could be a great project but should be integrated with the wallets in the ecosystem. Before vote we should confirm if the projects in the ecosystem would use this feature.

Travel and accommodation costs for 9 conferences within 7 to 8 months of work sounds a bit excessive.
Can you walk us through the importance of these. As of now it seems like there will be more than 1 conference per month.

Dear @Interstellar ,

Thank you for your proposal. Our vote on this proposal is NAY.

The Medium Spender track requires a 50% quorum and simple majority according to our voting policy. This proposal has received one aye and six nay votes from ten members, with two members abstaining. Below is a summary of our members' comments:

The referendum faced overwhelming opposition, with members raising concerns about the lack of clear technical details, the large funding request without milestones, and the proposal’s potential redundancy with existing solutions like Nova Wallet and mufi. Critics emphasized the need for a phased approach with smaller milestones and questioned the necessity of certain budget items, such as travel costs for conferences. While one member expressed support for the team’s past contributions, others abstained, citing insufficient detail to fully evaluate feasibility and value. Overall, the proposal was deemed unclear and overambitious.

The full discussion, along with individual members' votes and comments, can be found in our internal voting.

Kind regards,
Permanence DAO

We appreciate the feedback and the opportunity to clarify our proposal.

While Nova Wallet has already simplified user onboarding by replacing seed phrases with (complex) passwords, it shifted the burden of secure storage and memorization from one form (seed phrases) to another (passwords). The upcoming Polkadot App goes a step further by eliminating both seed phrases and passwords. While this is a step into the right direction, it introduces centralized points of failure by relying on Google and Apple logins, undermining resilience and compromising decentralization.

Our value proposition focuses on creating an instant onboarding experience, similar to the Polkadot App, but without undermining resilience or compromising decentralization. Interstellar represents the first decentralized and truly resilient smart account infrastructure for Polkadot and beyond. This framework eliminates the need for traditional recovery methods such as seed phrases, passwords, centralized email/social/Google/Apple logins, or centralized passkeys—replacing them with a more resilient, decentralized, and user-friendly alternative (Decentralized Cloud Backups, NFC Backups Items, and/or Social Recovery) which can easily be integrated within existing wallets. Eliminating the need for complex passwords or centralized Google/Apple accounts.

Additionally, today's Polkadot wallets are exposing user private keys within the (mobile/desktop/browser) device's memory not only during wallet creation but also every time when a transaction is signed. With phishing attacks increasing exponentially, this represents a significant attack vector and huge risk for the whole Polkadot ecosystem.

Our proposed smart account infrastructure does not expose private keys. It does so while keeping the convenience of your daily smartphone device. Eliminating the need for hardware wallets.

Furthermore, this decentralized infrastructure enables sybil-resistance as a feature, unlocking completely novel ways to onboard newcomers into the ecosystem.

Other ecosystems like Ethereum, Solana,... are already increasingly incorporating smart account infrastructures. However, those infrastructures heavily rely on centralized points of failure like email/social/Apple/Google logins, centralized passkeys, centralized authentications, centralized malware detections, centralized transaction confirmations, and more. They also rely on a lot of standalone components like centralized MPC protocols or keystores which operate in separate execution environments.

Interstellar, in contrast, introduces decentralized backups, decentralized authentications, decentralized transaction confirmations, and more decentralized alternatives which are directly incorporated into the blockchain runtime, protected by Polkadot's economic security. This makes our proposed smart account features significantly more resilient and secure than any other existing framework and smart account infrastructure currently available across the whole Web3 ecosystem.

For cybersecurity and applied cryptography experts:

Included within our proposed common good decentralized smart account infrastructure is the first decentralized zero-trust authentication solution (backed by W3F) using Garbled Circuits for OTP and dynamic visual cryptography–based transaction confirmation screen on mobile. This ensures the protection of sensitive data—such as code, transaction messages, and random visual cryptographic shares—through computation privacy, even if the device is compromised. We reinforce this with on-chain decentralized mobile-secure-element/key attestation, enabling instant onboarding. Specifically, the secure element signs the OTP response (the user’s random keypad input) for transaction confirmation, making each interaction tamper-proof. By verifying every transaction in real time, our approach delivers end-to-end protection from device to blockchain and even aligns with PSD2 Strong Customer Authentication (SCA) requirements and beyond.

To combat phishing and malware, large enterprises and financial institutions often rely on MTD/EDR solutions that can cost over $100 annually per device, yet still leave significant security gaps. Our decentralized approach not only addresses these threats more effectively—especially when phishing and sophisticated threats are amplified by AI—but also does so at a fraction of the cost.

Early Access Partners include:

Acala
Apillon
Braille
Hydration
SubWallet
Xcavate
…

Sorry, but how did you decide on the list for early access?

M1 Evaluation

As a curator of this treasury grant I hereby provide my evaluation of milestone M1. I have reproduced the demo provided and read the documentation. In order to also probe the code for my evaluation, I was granted exclusive read access to the repositories for the app as well as for the enclave backend. My review is no security audit. With the time budget I had for this evaluation (8h) I focused on matching code to deliverables and to comment whatever caught my attention along the way.

M1 Definition in Proposal: here

M1 amount to unlock: 67'886 USD

Design Evaluation

The main section of the documentation which describes the design of the relevant components can be found here. I found the documentation to be complete enough and understandable. The design choices appear sound to me and the team answered my questions that went deeper than the documentation competently. In the following I'd like to point out a few aspects of the design:

Recovery NFC security. Interstellar uses NFC tags for account recovery, optionally with an N-of-M threshold.

• ✓ NFC UID not exposed, only its hash will be sent to the backend enclave.
• ✓ Hash can't be eavesdropped because registration call to enclave is encrypted. Hash could be exposed upon enclave breach, but not the UID itself.
• ✓ similar design for key files stored on a cloud
• ⚠ NFC UID have only 4-10 bytes. That's not enough entropy as UID is structured, not random, and hashes can be brute-forced. Maybe consider writing fresh randomness to the NFC tag or restrict support to more modern tags with more UID bytes or other more secure features?

TAVP seems to be a USP of the interstellar solution. And its security properties are very interesting.

• Design is quite complex. A sequence diagram may help the reader better understand the handshake
• With the time budget I had for this evaluation I could only scratch the surface of this very innovative security feature.
• ❓ garbled circuit: not the reviewer's expertise.
• ❓ is IPFS really necessary/best option to deliver the garbled circuit challenge to the client?
  • payload garbled circuit to be sent to client is around 35MB. Cannot be cached in sidechain enclave state.
  • IPFS looks like a decent solution if pinning is solved in a decentralized manner (consider crust?)

Interstellar's design does add a lot of flexibility for recovery options. While I sense good potential for hugely improved wallet UX, the UX design will be a challenge on its own (beyond the scope of this milestone).

Code Evaluation

I did not reproduce any builds. I only probed code in interesting places.

The TEE enclave is based on an outdated release of the Integritee SDK. I'd strongly suggest to upgrade for later milestons to benefit from improvements and security patches.

• The Interstellar pallets look as if they indeed contain the logic as documented
• The Interstellar pallets have been integrated into the Integritee SDK as intended such that these pallets are executed within a TEE.

The app code indeed contains the logic as documented as far as I could probe.

Relevant Questions

• is the client side proxy account created using a secure-element (SE)? (as explained in docs
  • uses StrongBox if available permissioned code link
  • ⚠ attestation challenge can be replayed because it is static! permissioned code link to be solved later.
  • ⚠ server attestation of account creation in StrongBox is mentioned in the docs as to be implemented in future milestones
  • ⚠ biometric unlock for the StrongBox isn't implemented yet, but explained in docs.
  • ❓ the use of StrongBox attestation implies that the device may not be rooted and is running verified boot. Some users like myself use GrapheneOS for security hardening, which breaks the certificate chain to Google root CA. As StrongBox is not (yet?) enforced, that should be fine.

Practical Evaluation

The instructions to run the demo are complete and well-understandable. I only experienced a few hiccups which are acceptable for M1.

Connect & Onboard​

• Launch the app
• Register a new mobile account
• Validate biometric & SE-based registration
• Check toasted messages
• ✓ Registering toast
• ✓ Registered toast
• Step 2: Test Transaction Validation​
• Trigger the Trusted Action Validation Protocol (TAVP) screen
• Send a test transaction to a contact
• Enter the one-time code (2-digit), or experiment with trial/feedback
• Check toasted messages whith Action Validation Screen
• ✓ Creating a demo transaction...
• ✓ Validating transaction... (toast)
• (? flickering, too fast after above maybe?) Transaction done (toast)
• ✓ pallet_tx_validation::pallet] [tx-validation] TxPass
• ❓ no event can be observed in PJS pointing to integritee-node, the L1 for this demo. This is an acceptable limitation of this demo within the scope of M1, but for future milestones it would be nice to actually use the interstellar wallet to sign an L1 extrinsic.

demo passed.

Backup & Recovery

After adding a backup item:

• ✓ A "SECURED" badge will appear below the item.
• ✓ The recovery threshold (e.g. 1/1 FOR BACKUP, 1/2, etc.) will update accordingly.
• You can tap the threshold badge to change the required number of items for a valid recovery (e.g 2/2).
• Settings -> root account: 66f334edd......b21a
• reset app
• claim recovery: wrong root key shown first time
• but log looks ok: pallet_token_recovery::pallet] extended_recovery_with_vouch : DONE
• claim recovery again: app crash
• after app crash and restart, the recovered root key is correct

above crash was not experienced at later tests for the happy flow. However, edge-cases can lead to a crash, like e.g. trying to recover with the wrong key file.

retry recovery with 2/3 files in cloud storage

• ✓ create 3 keys
• ✓ set threshold to 2
• ✓ reset app (new root key 3c96.....)
• attempt to restore with outdated single recovery file should fail
• app crashes every time, reproducibly, no traces onchain

attempt to restore with only one of the three backup files

1. ✓ vouch with file 2, enter two digits
2. ✓ claim fails with integritee_service-1 | [2025-07-08T13:39:43Z ERROR itp_stf_executor::executor] Stf execute failed: Dispatch("claim_nfc_recovery error: Module(ModuleError { index: 11, error: [12, 0, 0, 0], message: Some("Threshold") })")
   as expected

attempt to restore with 2/3 files

1. ✓ vouch with file3, enter digits, verify log extended_recovery_with_vouch : DONE
2. ✓ vouch with file2, enter digits, verify log extended_recovery_with_vouch : DONE
3. ✓ claim, enter digits, verify log claim_recovery_with_nfc : DONE
4. ✓ root account is 66f334.....

attempt to recover again (after successful recovery)

• app crashes every time

I guess recovery info gets purged after recovery by design? Log indicates that

Test with NFC tags

• no suitable test phone available with API31+, therefore the NFC feature couldn't be tested on a real device
• tested with manual entry of 8-char tag UID - as implemented fallback in the app. recovery (1/1) worked

Demo passed.

Conclusion

I'm impressed with the work of Interstellar and I'm very much looking forward to the next milestones. A lot of critical work has been done already and documentation as well as code look very promising. The demo is functional and highlights the deliverables very well. I suggest to all curators to approve the release of M1 funds.