bc-bizdev
  • NEW!
    NEW!  Connect Ideas Across Notes
    Save time and share insights. With Paragraph Citation, you can quote others’ work with source info built in. If someone cites your note, you’ll see a card showing where it’s used—bringing notes closer together.
    Got it
        • Sharing URL Link copied
        • /edit
        • View mode
          • Edit mode
          • View mode
          • Book mode
          • Slide mode
          Edit mode View mode Book mode Slide mode
        • Customize slides
        • Note Permission
        • Read
          • Owners
          • Signed-in users
          • Everyone
          Owners Signed-in users Everyone
        • Write
          • Owners
          • Signed-in users
          • Everyone
          Owners Signed-in users Everyone
        • Engagement control Commenting, Suggest edit, Emoji Reply
      • Invite by email
        Invitee

        This note has no invitees

      • Publish Note

        Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note No publishing access yet

        Your note will be visible on your profile and discoverable by anyone.
        Your note is now live.
        This note is visible on your profile and discoverable online.
        Everyone on the web can find and read all notes of this public team.

        Your account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

        Your team account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

        Explore these features while you wait
        Complete general settings
        Bookmark and like published notes
        Write a few more notes
        Complete general settings
        Write a few more notes
        See published notes
        Unpublish note
        Please check the box to agree to the Community Guidelines.
        View profile
      • Commenting
        Permission
        Disabled Forbidden Owners Signed-in users Everyone
      • Enable
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Suggest edit
        Permission
        Disabled Forbidden Owners Signed-in users Everyone
      • Enable
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
      • Emoji Reply
      • Enable
      • Versions and GitHub Sync
      • Note settings
      • Note Insights New
      • Engagement control
      • Make a copy
      • Transfer ownership
      • Delete this note
      • Insert from template
      • Import from
        • Dropbox
        • Google Drive
        • Gist
        • Clipboard
      • Export to
        • Dropbox
        • Google Drive
        • Gist
      • Download
        • Markdown
        • HTML
        • Raw HTML
    Menu Note settings Note Insights Versions and GitHub Sync Sharing URL Help
    Menu
    Options
    Engagement control Make a copy Transfer ownership Delete this note
    Import from
    Dropbox Google Drive Gist Clipboard
    Export to
    Dropbox Google Drive Gist
    Download
    Markdown HTML Raw HTML
    Back
    Sharing URL Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Customize slides
    Note Permission
    Read
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Write
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Engagement control Commenting, Suggest edit, Emoji Reply
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note No publishing access yet

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.

    Your account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

    Your team account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

    Explore these features while you wait
    Complete general settings
    Bookmark and like published notes
    Write a few more notes
    Complete general settings
    Write a few more notes
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    Engagement control
    Commenting
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Suggest edit
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    Emoji Reply
    Enable
    Import from Dropbox Google Drive Gist Clipboard
       Owned this note    Owned this note      
    Published Linked with GitHub
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    --- robots: noindex, nofollow --- # SmartCustody for Ethereum with Account Abstraction ###### Tags: `article / updated 2025` This proposal offers a methodology for adopting Blockchain Commons' SmartCustody principles to improve the resilience, modularity, and security of Ethereum wallets through the use of **Account Abstraction (ERC-4337)** and other Ethereum-native features. ## Problem Statement Ethereum accounts are traditionally controlled by a single private key. They come in two types: * **EOAs (Externally Owned Accounts)** use key pairs: the address is derived from a public key, and the private key controls access. EOAs are still the most common. * **Contract Accounts** are controlled by smart contracts, which can include logic for authorization, recovery, and delegation. They are indistinguishable in address format from EOAs. The traditional model presents critical security challenges: * A **Single Point of Failure** (loss of the private key). * A **Single Point of Compromise** (if the key is stolen, all assets and access are lost). * Lack of separation between roles: signing into apps, holding NFTs, executing contract logic, and controlling assets often share a single key. These are textbook examples of **Ambient Authority**: where access permissions are overly broad and undifferentiated. While Ethereum has introduced *Account Abstraction* (AA) to move beyond these limitations, most wallets and dApps have not yet embraced meaningful separation of keys or proof purposes. This proposal defines a framework for **partitioned authority and recoverable key management**, enabling modular design, permissioned roles, and robust recovery for Ethereum wallets. It also recognizes the value of **pragmatic interoperability with legacy Ethereum wallets**, proposing an initial survey to identify existing capabilities and adoption blockers. ## Account Abstraction: Enabling Secure Partitioning **ERC-4337** enables users to operate smart contract wallets with customizable logic for verification and execution. This is a foundational shift: * It supports **multiple signers** with different roles. * It allows programmable recovery, rotation, and revocation. * It moves Ethereum away from rigid EOA dependency. SmartCustody builds on these foundations by proposing a structured framework of **Proof Purposes**: 1. **Single Sign-On** (Web3 login auth) 2. **Asset Holding** (ETH & ERC-20 transfers) 3. **NFT Management** (ERC-721/1155 operations) 4. **Smart Contract Control** (deployment and execution) 5. **Social or Emergency Recovery** (optional) Each purpose should be assigned to a distinct key pair or signer slot, with smart contract logic validating their scope. > This creates enforceable separation, better resilience, and more predictable failure modes. ## Wallet Design Modern Ethereum wallets must: * Support **multi-signer ERC-4337 wallets**. * Maintain metadata for each key (e.g., proof purpose, creation date, shard index). * Integrate **key derivation hierarchies**, using `xpub`/`xprv` principles. * Allow **airgapped** seed/key provisioning using QR-encoded Uniform Resources. * Support **offline signing** and **minimal online attack surface**. Where possible, wallets should: * Never store the master seed directly. * Allow provisioning of key material via QR codes using **Blockchain Commons' Uniform Resources**. * Support **SSKR** (Sharded Secret Key Reconstruction) for seed protection. ## WalletConnect Design WalletConnect already separates the app interface from signing logic. This is a perfect channel to: * Introduce **xpub-derived keys** per dApp or per session. * Use **proof-purpose scoped authorization**, enforced by AA wallet logic. * Interface with **recovery flows** managed via CSR (Collaborative Seed Recovery). We propose: * Support for **WalletConnect + ERC-4337 bundler relaying**. * Key registration via airgapped scanning (SeedTool + WalletConnect). * Compatibility testing with WalletConnect 3 for Ethereum-native multi-account UX. ## Development Path We propose the following staged roadmap: 1. **Conduct Ethereum Wallet Survey** * Evaluate legacy and current Ethereum wallets for interoperability potential * Record supported features, signing models, and recovery methods * Identify opportunities for backward-compatible proof purpose integration * Host at least two developer-focused meetings to present findings and collect feedback, following the model of our successful FROST coordination process 2. **Define Proof Purpose Templates** * For SSO, NFTs, Assets, Contracts * Draft JSON/YAML schema with clear role definitions and usage boundaries 3. **Develop a prototype ERC-4337 SmartCustody wallet** * Polygon as testbed * Uses purpose-specific key slots 4. **Enhance SeedTool** * Integrate WalletConnect 2 * Provision xpub/xprv with proof-purpose metadata 5. **Enable NFT support** * Test ERC-721/1155 with purpose-restricted signer slots 6. **Collaborate on WalletConnect 3 integration** * Multi-session, multi-proof-purpose compatibility 7. **Integrate Smart Recovery** * CSR servers store SSKR Envelopes for lost-device recovery * Build WalletConnect-compatible recovery UX ## SmartCustody Recovery Stack **Blockchain Commons tools for Ethereum AA wallets:** * **SSKR**: Secure, resilient sharding of seed material * **Envelope**: Cryptographic document container supporting encryption, elision, and multi-asset bundles * **CSR**: Server-based collaborative seed recovery using encrypted shards * **GSTP**: Secure transport protocol over insecure channels (e.g., QR, BLE) ## Potential Challenges 1. **Backwards Compatibility** * May need a fallback signer (0th child) for legacy contract interaction. 2. **ERC-721/1155 UX** * Require support for separate payment vs. holder addresses. 3. **Key Derivation Standards** * BIP32/BIP44 + SLIP44 support on Ethereum is limited; hardened paths must be used cautiously. 4. **Non-Ethereum Curve Support** * BIP32 methods are incompatible with ed25519; possible limitation for L2s or cross-chain wallets. ## Future Development Ethereum's smart account ecosystem is growing rapidly. With SmartCustody: * Developers gain templates and libraries for safer key management. * Users get structured recovery paths and protection from ambient authority. * Wallet developers get tools for enforceable modular security. **Our next steps:** * Extend Wallet Interchange Format to Ethereum * Publish Proof Purpose schemas * Offer open-source SmartCustody wallet templates * Host Ethereum-focused Silicon Salons for AA wallet builders and signer ecosystem stakeholders ## Conclusion SmartCustody brings years of Bitcoin resilience research to Ethereum's new account paradigm. Through proof-purpose partitioning, enforceable modular authority, robust seed recovery, and coordinated developer adoption, we can help the Ethereum ecosystem build wallets that are resilient, interoperable, and secure by design. ==== # 📚 Key Readings on ERC-4337 Smart Account Adoption & Retention (2024–2025) Below is a curated list of recent reports and analyses that examine the adoption, usage patterns, and infrastructure maturity of ERC-4337 smart accounts. These resources are critical for understanding the systemic challenges Ethereum faces with account abstraction—and for positioning Blockchain Commons’ work within that context. ### 1. Safe & BundleBear – _“Onchain Retention for Smart Accounts”_ (March 2024) https://safe.global/blog/onchain-retention-for-smart-accounts An in-depth analysis showing that ERC-4337 smart accounts suffer from very low retention. Accounts older than five weeks often drop to just 1% weekly activity. Average smart accounts execute only five user operations. Highlights the urgent need for better onboarding and user recovery flows. ### 2. 2077 Research – _“ERC-4337 Two Years After Launch: Expansion and Challenges of Account Abstraction”_ (March 2025) https://www.eblockmedia.com/news/articleView.html?idxno=15617 A comprehensive two-year review of ERC-4337 adoption. Reports 24+ million smart accounts created but low average usage per account. The report flags interoperability issues and the lack of standardized tooling for recovery, backup, and signer management. ### 3. Publish0x – _“ERC-4337 in 2024 Review”_ (January 2025) https://www.publish0x.com/etherspot/erc-4337-in-2024-review-openzk-s-l2-launch-arcana-s-chain-ab-xevwyzp BundleBear’s year-end summary: over 103 million user operations in 2024, but only 4.3 million accounts performed more than one operation. Reinforces the pattern of high churn and low re-engagement for smart account wallets. ### 4. The BlockBeats – _“200 Million Gasless Transactions in One Month, Is Account Abstraction a Success?”_ (April 2025) https://www.theblockbeats.info/en/news/57418 Highlights a surge in gasless transactions via paymasters, hitting 200 million in a month. Despite the volume, user retention remains low. The article questions whether account abstraction’s usability gains translate into long-term ecosystem engagement. ### 5. Bitcoinke – _“State of Wallets 2025”_ (May 2025) https://bitcoinke.io/2025/05/state-of-wallets-2025/ Covers the growing presence of ERC-4337 wallets, which have begun to outpace EOAs monthly. However, it flags that many smart accounts are created for incentives and are quickly abandoned. Points to a pressing need for meaningful recovery and user value post-onboarding. ### 6. Alchemy – _“Smart Accounts Adoption Accelerated in Q4 2023”_ (January 2024) https://www.alchemy.com/blog/smart-accounts-adoption-accelerated-in-q4-2023 Reports nearly one million new ERC-4337 smart accounts created in Q4 2023. Still, the average account sees only five user operations, reinforcing the theme of shallow usage. Highlights bundler challenges and incomplete tooling. ### 7. Cointelegraph – _“New Figures Show Hardly Anyone Is Using ERC-4337 Smart Accounts”_ (November 2023) https://cointelegraph.com/news/hardly-anyone-using-ethereum-smart-accounts A critical early overview of ERC-4337’s rollout. Notes the heavy dominance of EOAs, slow dApp support, and lack of compelling recovery UX as primary blockers to smart account growth. ### 8. Crypto Pulpit – _“The Slow Adoption of ERC-4337 Accounts”_ (November 2023) https://cryptopulpit.com/the-slow-adoption-of-erc-4337-accounts/ Emphasizes low activity across ERC-4337 accounts, bundler profitability concerns, and gaps in recovery models. Useful for understanding the developer-side friction. ### 9. Gelato – _“Gelato’s Guide to Account Abstraction: from ERC-4337 to EIP-7702”_ (April 2025) https://www.gelato.network/blog/gelato-s-guide-to-account-abstraction-from-erc-4337-to-eip-7702 Analyzes the shortcomings of ERC-4337 and introduces EIP-7702 as a potential improvement path. Frames 4337 as a valuable stepping stone but limited by complexity and dApp incompatibility. ### 10. Codezeros – _“Web3 Wallet Development in 2025: Why You Should Consider Account Abstraction”_ (March 2025) https://www.codezeros.com/web3-wallet-development-in-2025-why-you-should-consider-account-abstraction Optimistic outlook on the future of AA wallets. Projects ERC-4337’s successor technologies (like EIP-7702) as catalysts for smart account dominance by 2027. Suggests the need for better UX and recovery tooling now to prepare for broader adoption. === ## Exploratory Brief: Addressing ERC-4337’s Retention Crisis with Resilient Recovery & Signer Infrastructure **From**: Christopher Allen, Principal Architect, Blockchain Commons **To**: Ethereum Foundation / Wallet & Account Abstraction Teams **Date**: July 2025 **Funding Goal**: Pilot collaboration to address critical gaps in Ethereum smart account lifecycle—retention, signer provisioning, and recovery—with open, modular tooling --- ## Introduction ERC-4337 was launched to unlock powerful new wallet capabilities—gas abstraction, programmable permissions, and smart recovery—but after two years, the ecosystem is facing a quiet crisis: 📉 **Retention is dangerously low.** Recent studies show that: - Fewer than **7% of ERC-4337 smart accounts** remain active after five weeks (Safe & BundleBear, 2024–2025) - Most accounts execute only **five user operations**, often during initial dApp onboarding - Airdrop-driven wallet creation results in high churn and **abandoned signer state** This suggests a growing divide between **ERC-4337’s theoretical capabilities** and **real-world wallet lifecycle UX**—particularly around secure provisioning, role management, and recovery. **Blockchain Commons**, a *not-for-profit public benefit organization*, has spent the past five years designing open-source tools and specifications for **resilient key management, signer metadata, and interoperable recovery**—primarily in UTXO-based ecosystems like Bitcoin and Zcash. We now propose to bring that experience into the Ethereum smart account context—*not as a retrofit*, but as a collaborative investigation into the failures ERC-4337 data has surfaced. --- ## What We’re Responding To > “Account abstraction lowers the entry barrier—but doesn’t solve for re-engagement, safety, or long-term control.” > — _ERC-4337 Year 2 Review, 2077 Research_ The problem isn’t just technical. It’s lifecycle-level: - 🔐 **Weak signer provisioning**: Smart accounts are often generated on the fly, with little or no structured metadata, backup instructions, or trust modeling. - 🚫 **No standard recovery format**: Social recovery is theoretically supported, but toolchains for shard distribution, metadata protection, or threshold recovery are largely unimplemented. - 🔄 **No structured signer metadata**: dApps don’t record how or why a smart account was created, and wallets rarely encode roles or scopes for key material. - 💥 **Lifecycle fragmentation**: Most accounts are created, used once, and forgotten—making continuity, reactivation, and recovery extremely difficult. These are the same failure modes we've solved in other contexts—with production-tested formats for **proof-purpose separation**, **airgapped provisioning**, and **multi-party recovery**. --- ## What We Propose to Explore We’re not proposing a new wallet. Instead, we offer a focused collaboration to test and adapt modular tools that may help resolve known lifecycle gaps in Ethereum smart accounts. We propose to explore the following areas with Ethereum-native developers: ### 1. **Signer Metadata with Envelope** Can [Envelope](https://github.com/BlockchainCommons/Envelope)—our structured cryptographic container—help encode: - Signer roles (e.g., login, NFT control, gas delegation)? - Backup instructions? - Derivation paths and audit trails? This would support portable signer context without dictating smart account architecture. ### 2. **Recovery UX with SSKR and CSR** Could [SSKR](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-sskr.md) (Sharded Secret Key Reconstruction) and CSR (Collaborative Seed Recovery) offer: - Threshold-based shard distribution with dApp-controlled UX? - Optional use of decentralized storage (CSR servers)? - A path to Ethereum-native social recovery that avoids trusted custodians? ### 3. **Provisioning via Uniform Resources (UR)** Could [URs](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-ur.md) (animated QRs) support: - Offline signer provisioning via WalletConnect or QR flows? - Shard delivery, xpub transfer, or metadata migration in airgapped flows? - Integration into mobile dApp onboarding? UR is already used in 13+ Bitcoin and Zcash wallets for PSBT signing and seed import/export. ### 4. **Proof Purpose Mapping** Can we test **role-scoped key separation** (proof purposes) within ERC-4337 wallets? - Separate keys for login auth, asset control, smart contract deployment - Better modularity and recovery semantics - UX guardrails against ambient authority This mirrors best practices we’ve deployed in UTXO wallets—and could serve as a foundation for Ethereum-native lifecycle discipline. --- ## Phase 1 Proposal (3–6 Months) ### 🧪 Pilot Collaborations With 1–2 Ethereum wallet teams (e.g., Safe, Zerodev, Biconomy), we’ll prototype: - Envelope-signed signer metadata records - SSKR backup flows for smart account signer material - WalletConnect-compatible UR flows for secure signer provisioning ### 📊 Smart Account Recovery Audit A short report analyzing how Ethereum wallets handle: - Key backup and recovery - Role metadata and signer scope - Failure modes (e.g., deleted app, lost device, stale signer) This will include interviews with wallet developers and user-facing teams. ### 🧑‍🤝‍🧑 Ethereum Silicon Salon We’ll convene a working group to discuss: - Recovery UX fragmentation - Open tooling opportunities - Minimum viable standards for signer metadata, recovery hints, and cross-wallet restoration Blockchain Commons has previously coordinated open standards salons for FROST and cryptographic hardware. ### 📂 Open Source Deliverables - Reference Envelope schemas for signer metadata and backup scope - WalletConnect-compatible UR provisioning stubs - SSKR + CSR demo integrations - Interchange-format draft for smart account signer data - Public findings on ERC-4337 retention and recovery gaps --- ## Why Blockchain Commons? We are not offering a wallet. We’re offering **battle-tested, audited tooling** for decentralized signer safety: | Capability | Our Tool | Production Usage | |----------------------------|-----------------------------------|------------------------------| | Threshold recovery | SSKR | Foundation Devices, SeedTool | | Metadata encoding | Envelope | Zcash Wallet Interchange | | Offline provisioning | UR / QR stack | 13+ wallets across UTXO | | Shard storage (optional) | CSR | In pilot (Zcash) | We’re a **not-for-profit benefit organization**, operating transparently, independently, and focused on public-good tooling for resilient, user-controlled security. All of our tools are open source and MIT-licensed. We’ve convened successful **cross-vendor cryptographic coordination** efforts, and we are well-positioned to support Ethereum’s smart account evolution—not by replacing what's working, but by helping fix what’s silently failing. --- ## Funding Request We are requesting Ethereum Foundation support to: - Fund core engineering for adapting Envelope, SSKR, and UR to Ethereum-specific flows - Facilitate developer pilots and collaborative workshops - Deliver documentation and schemas for Ethereum-native recovery standards - Publish a public-good report mapping signer lifecycle design gaps We’re open to co-creating milestones, co-authoring public outputs, and aligning this work with broader Ethereum security and UX initiatives. --- ## Closing Thought ERC-4337 has proven that modular wallets *can* work. What remains unsolved is how to make them **resilient, recoverable, and user-owned** across their full lifecycle. That’s where we specialize. We welcome the opportunity to collaborate—through code, conversation, and co-design. **Christopher Allen** Principal Architect, Blockchain Commons 📧 christophera@lifewithalacrity.com 🌐 https://www.blockchaincommons.com 📂 https://developer.blockchaincommons.com

    Import from clipboard

    Paste your markdown or webpage here...

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lose their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a template

    Upgrade

    Delete template

    Do you really want to delete this template?
    Turn this template into a regular note and keep its content, versions, and comments.

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password
    or
    Sign in via Google Sign in via Facebook Sign in via X(Twitter) Sign in via GitHub Sign in via Dropbox Sign in with Wallet
    Wallet ( )
    Connect another wallet

    New to HackMD? Sign up

    By signing in, you agree to our terms of service.

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Help & Tutorial

    How to use Book mode

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    Feedback

    Discord

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions and GitHub Sync
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    Compare
      Choose a version
      No search result
      Version not found
    Sign in to link this note to GitHub
    Learn more
    This note is not linked with GitHub
     

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub
        • Please sign in to GitHub and install the HackMD app on your GitHub repo.
        • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
        Learn more  Sign in to GitHub

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Include title and tags
        Available push count

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully