{"id":14017,"date":"2026-07-02T14:20:53","date_gmt":"2026-07-02T06:20:53","guid":{"rendered":"https:\/\/custody.chainup.com\/blog\/\/"},"modified":"2026-07-02T14:20:53","modified_gmt":"2026-07-02T06:20:53","slug":"multisig-public-keys-cryptographic-institutional-asset-governance","status":"publish","type":"post","link":"https:\/\/test.keysecure.io\/zh\/blog\/multisig-public-keys-cryptographic-institutional-asset-governance\/","title":{"rendered":"Multisig and Public Keys: Cryptographic Institutional Asset Governance"},"content":{"rendered":"

In digital asset governance, establishing authorized decision-making frameworks without relying on a single trusted entity remains a core architectural challenge. Multisignature (multisig) technology, a distributed authorization mechanism built on public key cryptography, offers a robust solution. By eliminating reliance on centralized intermediaries and avoiding additional trust assumptions, multisig leverages mathematical relationships to transition asset control from a single point of failure to a distributed consensus.<\/span><\/p>\n

This analysis explores the technical mechanics of multisig, its relationship with public key infrastructure, deployment strategies across various operational frameworks, and its structural distinctions from both traditional signing methods and multi-party computation (MPC).<\/span><\/p>\n

Public Key Cryptography: The Foundation of Multisig<\/b><\/h2>\n

The Asymmetric Mechanics of Key Pairs<\/b><\/h3>\n

Understanding multisig requires a foundational look at public key cryptography. This architecture relies on mathematically linked key pairs: a private key, which must remain confidential, and a public key, which is shared publicly. While a public key is derived from its corresponding private key, deriving the private key from the public key is computationally infeasible. This asymmetry forms the basis of digital signature security.<\/span><\/p>\n

In a blockchain framework, the public key serves a dual purpose:<\/span><\/p>\n

    \n
  • Identifier Generation:<\/b> It is hashed to create on-chain addresses that act as routing identifiers for asset transfers.<\/span><\/li>\n
  • Signature Verification:<\/b> It serves as the mathematical reference point to verify on-chain actions. Any transaction executed by a private key can be validated by the corresponding public key, confirming that the action was authorized by the keyholder.<\/span><\/li>\n<\/ul>\n

    Single-Signature Execution Flow<\/b><\/h3>\n

    The standard single-signature (singlesig) transaction execution follows a linear path:<\/span><\/p>\n

      \n
    1. The initiator signs the transaction payload using their private key.<\/span><\/li>\n
    2. The signed transaction is broadcast to the network mempool.<\/span><\/li>\n
    3. Network validators verify the signature’s validity against the initiator\u2019s public key.<\/span><\/li>\n
    4. Once verified, the transaction is bundled into a block and executed.<\/span><\/li>\n<\/ol>\n

      While efficient, this model operates on binary authorization logic: the private key holder exercises absolute control over the assets. If the key is compromised or lost, access is permanently severed. This single-point-of-failure vulnerability makes singlesig unsuitable for enterprise, institutional, or decentralized autonomous organization (DAO) treasury management.<\/span><\/p>\n

      Public Keys as Cryptographic Anchors for Identity<\/b><\/h3>\n

      In a multisig architecture, a public key functions as more than a single identity marker. A multisig address is associated with a structured set of public keys governed by a predefined threshold condition.<\/span><\/p>\n

      When validating a transaction, nodes verify that the payload contains the required number of distinct, valid signatures from the designated public key set. The public key collection essentially serves as a cryptographic anchor for group identity\u2014shifting the locus of control from an individual to a mathematically defined collective.<\/span><\/p>\n

      Multisig Architecture and Structural Variations<\/b><\/h2>\n

      Defining the Threshold Mechanism<\/b><\/h3>\n

      Multisig requires multiple independent private keys to sign a single transaction payload. The transaction is only recognized as valid by the underlying blockchain network once the number of valid signatures reaches a predefined threshold. This is expressed through an m-of-n variable configuration, where n represents the total number of authorized public keys, and m$represents the minimum number of signatures required to execute a transaction.<\/span><\/p>\n

      For example, in a 3-of-5 multisig configuration, five distinct private keys hold signing authority, but any combination of three signatures is sufficient to authorize a transaction. This framework prevents unilateral asset movement by a single party while maintaining operational continuity if certain keyholders are unavailable.<\/span><\/p>\n

      Technical Implementation Pathways<\/b><\/h3>\n

      Multisig implementation methods vary across blockchain architectures:<\/span><\/p>\n

        \n
      • Bitcoin P2SH (Pay-to-Script-Hash):<\/b> Bitcoin processes multisig through P2SH scripts. The creator generates an address from the hash of a redeem script containing the list of authorized public keys and the corresponding threshold. To spend funds from this address, the spenders must present the original redeem script along with the required number of valid signatures.<\/span><\/li>\n
      • Smart Contract Wallets (e.g., Ethereum):<\/b> On EVM-compatible and programmable blockchains, multisig functionality is typically deployed via smart contracts. The contract stores the authorized public keys and threshold parameters on-chain, evaluating signature counts and verifying conditions programmatically for each transaction request.<\/span><\/li>\n
      • Native vs. Script-Level Support:<\/b> Certain protocols build multisig logic directly into the core protocol layer, meaning validation happens natively within the node client. Others rely on application-layer smart contracts. Protocol-native solutions generally offer lower gas costs and structural simplicity, while smart contract implementations provide greater flexibility and programmable logic.<\/span><\/li>\n<\/ul>\n

        Distinguishing Multisig from Threshold Signatures (TSS)<\/b><\/h3>\n

        Multisig is frequently confused with Threshold Signature Schemes (TSS), a subset of multi-party computation (MPC). However, their underlying architectures differ significantly:<\/span><\/p>\n

          \n
        • Multisignature:<\/b> Multiple independent private keys generate multiple distinct digital signatures. These signatures are attached to the transaction payload and verified individually on-chain by validators.<\/span><\/li>\n
        • Threshold Signatures:<\/b> Multiple key shards interact off-chain to generate a single, standard digital signature. To the blockchain, the transaction looks identical to a standard singlesig transaction, hiding the underlying signer distribution.<\/span><\/li>\n<\/ul>\n

          This analysis focuses on on-chain verifiable multisig mechanisms, where the link to public keys remains transparent: each private key corresponds to an independent, public key recorded directly within the on-chain address or smart contract configuration.<\/span><\/p>\n

          Security Frameworks and Trust Assumptions<\/b><\/h2>\n

          Mathematical Security Guarantees<\/b><\/h3>\n

          Multisig security relies on two distinct layers:<\/span><\/p>\n

            \n
          • ECDSA\/EdDSA Cryptographic Hardness:<\/b> Every individual signature is protected by the mathematical complexity of the Elliptic Curve Discrete Logarithm Problem (ECDLP). An attacker cannot forge a valid signature for any given public key without possessing the underlying private key.<\/span><\/li>\n
          • Threshold Redundancy:<\/b> Even if an attacker compromises multiple private keys, the assets remain secure as long as the number of compromised keys is lower than the threshold (m). Assuming key compromises are independent events, the overall security density of a multisig setup scales exponentially relative to a singlesig model.<\/span><\/li>\n<\/ul>\n

            Vectors Mitigated by Multisig Configurations<\/b><\/h3>\n

            Multisig setups mitigate several critical operational and security risks:<\/span><\/p>\n

              \n
            • Single-Point Compromise:<\/b> The loss or theft of a single private key does not lead to asset loss. The attacker only holds one signing factor, which falls short of the execution threshold.<\/span><\/li>\n
            • Internal Collusion and Malicious Actors:<\/b> Individual rogue actors within an organization cannot unilaterally misappropriate funds, provided their access is capped below the execution threshold.<\/span><\/li>\n
            • Coercion and Physical Extortion:<\/b> Physical extortion targeted at a single executive or keyholder fails to compromise the treasury, as attackers must gain control of at least m distributed keyholders simultaneously.<\/span><\/li>\n<\/ul>\n

              Residual Operational Risks<\/b><\/h3>\n

              Despite its structural security, multisig introduces specific operational risks:<\/span><\/p>\n

                \n
              • Collusion Vulnerabilities:<\/b> If thresholds are set too low (e.g., 2-of-3), a subset of participants can collude to bypass corporate governance policies.<\/span><\/li>\n
              • Key Loss and Deadlock:<\/b> If the number of lost keys exceeds n – m + 1, the remaining active keys will be unable to meet the threshold requirement, resulting in a permanent lock on the assets.<\/span><\/li>\n
              • Smart Contract Flaws:<\/b> For smart-contract-based multisig wallets, vulnerabilities or logic errors in the contract code can open the door to exploitation, allowing attackers to bypass signature validation checks entirely.<\/span><\/li>\n
              • Targeted Social Engineering:<\/b> Sophisticated attackers can deploy multi-pronged phishing or social engineering campaigns to compromise the required number of keys sequentially over time.<\/span><\/li>\n<\/ul>\n

                Enterprise Deployment Strategies<\/b><\/h2>\n

                Classic Threshold Configurations<\/b><\/h3>\n

                Different m-of-n configurations align with specific institutional governance structures:<\/span><\/p>\n\n\n\n\n\n\n\n
                Configuration<\/b><\/td>\nTypical Use Case<\/b><\/td>\nOperational Profile<\/b><\/td>\n<\/tr>\n
                2-of-3<\/b><\/td>\nSmall Teams \/ Joint Accounts<\/span><\/td>\nLow latency, high redundancy. Vulnerable if two parties collude.<\/span><\/td>\n<\/tr>\n
                3-of-5<\/b><\/td>\nInstitutional Treasury \/ Corporate Governance<\/span><\/td>\nStandard enterprise profile. Balance of security and operational speed; resilient to individual device failure or absence.<\/span><\/td>\n<\/tr>\n
                4-of-7<\/b><\/td>\nLarge-Scale Funds \/ Custodial Arrays<\/span><\/td>\nHigh security. Geographically distributed key distribution; usually paired with time-locks for larger fund management.<\/span><\/td>\n<\/tr>\n
                5-of-9<\/b><\/td>\nDAO Core Treasury \/ Protocol Governance<\/span><\/td>\nHighly decentralized. Mitigates systemic risk across distributed contributor networks; higher coordination overhead.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                 <\/p>\n

                Keyholder Architecture and Access Distribution<\/b><\/h3>\n

                Selecting keyholders requires a strategic approach to risk diversification. Institutional setups should follow these core principles:<\/span><\/p>\n

                  \n
                • Role Heterogeneity:<\/b> Distribute signing authority across different operational divisions (e.g., Treasury, Legal, Operations) and include independent external parties, such as third-party auditors or fund administrators.<\/span><\/li>\n
                • Geographic Dispersion:<\/b> Distribute keyholders across different jurisdictions and time zones. This reduces the risk of simultaneous operational disruptions caused by regional geopolitical shifts or natural disasters.<\/span><\/li>\n
                • Infrastructure Diversity:<\/b> Store keys across an assortment of device architectures. Combining hardware security modules (HSMs), cold hardware wallets, and sandboxed mobile environments protects against systemic supply chain vulnerabilities targeting a single device class.<\/span><\/li>\n<\/ul>\n

                  Key Recovery and Succession Frameworks<\/b><\/h3>\n

                  To prevent operational deadlocks from sudden personnel changes, organizations should implement formal recovery and succession strategies:<\/span><\/p>\n

                    \n
                  • Cold Backup Provisions:<\/b> Store backup seed phrases in highly secure locations, such as bank vaults. These keys should only be accessible through verified multi-step identification protocols with built-in time delays.<\/span><\/li>\n
                  • Dynamic Threshold Adjustments:<\/b> Implement programmable conditions that automatically recalculate thresholds or remove inactive keys if a keyholder fails to participate in signing activities over a set period (e.g., 180 days).<\/span><\/li>\n
                  • Legal and Institutional Escrow:<\/b> Entrust a subset of keys to professional third-party custodians under strict service-level agreements. These keys are only released upon presentation of verified corporate resolutions or formal legal orders.<\/span><\/li>\n<\/ul>\n

                    Operational Use Cases in Enterprise Governance<\/b><\/h2>\n

                    Corporate Treasury and Expense Approval Workflow<\/b><\/h3>\n

                    Multisig workflows natively reflect traditional corporate finance controls, such as dual-authorization and joint-signoff rules. Aligning cryptographic thresholds with corporate compliance structures enables automated enforcement:<\/span><\/p>\n

                    [Expense Triggered]<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2502<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500> Internal Budget Space (<$50K)\u00a0 \u2500\u2500\u2500> Requires 2 Financial Officers<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2502<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500> Capital Expenditure (>$50K)\u00a0 \u2500\u2500\u2500> Requires CFO + CEO Signatures<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2502<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500> Out-of-Scope Transactions\u00a0 \u00a0 \u2500\u2500\u2500> Requires CFO + CEO + Compliance Officer<\/span><\/p>\n

                     <\/p>\n

                    This alignment ensures that digital asset movements are governed by corporate policy at the cryptographic layer, removing the reliance on manual operational checks.<\/span><\/p>\n

                    DAO Treasury Execution<\/b><\/h3>\n

                    For decentralized autonomous organizations, multisig wallets function as the execution layer for off-chain or snapshot-based governance models:<\/span><\/p>\n

                      \n
                    1. Community members submit a proposal that undergoes a signaling vote.<\/span><\/li>\n
                    2. Upon successful consensus, an on-chain transaction payload is generated.<\/span><\/li>\n
                    3. The payload is queued in the DAO’s multisig contract interface.<\/span><\/li>\n
                    4. Designated signers (typically an elected steering committee) sign off on the transaction until the threshold is met.<\/span><\/li>\n
                    5. The transaction executes, programmatically routing treasury funds according to the proposal guidelines.<\/span><\/li>\n<\/ol>\n

                      Special Purpose Vehicles (SPVs) and Co-Investment Schemes<\/b><\/h3>\n

                      When multiple institutional allocators pool capital into an SPV or joint liquidity provision pool, multisig provides a trustless framework for capital deployment:<\/span><\/p>\n

                        \n
                      • Each investing entity maintains exclusive control over one signing key.<\/span><\/li>\n
                      • The system is configured with a supermajority threshold (e.g., greater than two-thirds), ensuring major capital deployments reflect investor consensus.<\/span><\/li>\n
                      • All capital distribution paths (investments, distributions, management fees) are hardcoded into the setup, providing end-to-end auditability.<\/span><\/li>\n<\/ul>\n

                        Comparative Analysis: Native Multisig, Smart Contracts, and MPC<\/b><\/h2>\n

                        Choosing the right asset protection framework requires a clear understanding of the technical tradeoffs between native multisig, smart contract wallets, and MPC implementations:<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n
                        Feature Dimension<\/b><\/td>\nProtocol-Native Multisig<\/b><\/td>\nSmart Contract Multisig Wallet<\/b><\/td>\nMPC Threshold Signatures (TSS)<\/b><\/td>\n<\/tr>\n
                        Signature Format<\/b><\/td>\nMultiple discrete signatures attached to payload<\/span><\/td>\nMultiple discrete signatures verified via contract<\/span><\/td>\nSingle aggregated cryptographic signature<\/span><\/td>\n<\/tr>\n
                        On-Chain Transparency<\/b><\/td>\nPublic key arrays and signature volumes are fully public<\/span><\/td>\nPublic key arrays and signature volumes are fully public<\/span><\/td>\nOn-chain footprints are indistinguishable from singlesig accounts<\/span><\/td>\n<\/tr>\n
                        Gas Cost Profile<\/b><\/td>\nScales linearly with signature count<\/span><\/td>\nScales linearly with signature count; carries higher execution overhead<\/span><\/td>\nFixed; identical to standard singlesig transaction fees<\/span><\/td>\n<\/tr>\n
                        Address Permanence<\/b><\/td>\nMembership changes require a new address and asset migration<\/span><\/td>\nMembership changes require a state update or new deployment<\/span><\/td>\nMembership changes occur off-chain; address remains static<\/span><\/td>\n<\/tr>\n
                        Protocol Compatibility<\/b><\/td>\nLimited to specific chains (e.g., Bitcoin)<\/span><\/td>\nLimited to programmable smart contract chains (e.g., EVM)<\/span><\/td>\nAgnostic; compatible with any chain utilizing ECDSA\/EdDSA<\/span><\/td>\n<\/tr>\n
                        Audit Compliance<\/b><\/td>\nHigh; public key access lists are fully verifiable on-chain<\/span><\/td>\nHigh; public key access lists are fully verifiable on-chain<\/span><\/td>\nComplex; requires off-chain log reconstruction for individual attribution<\/span><\/td>\n<\/tr>\n
                        Collusion Mitigation<\/b><\/td>\nTied directly to configuration and keyholder independence<\/span><\/td>\nTied directly to configuration and keyholder independence<\/span><\/td>\nIdentical, with more granular off-chain share rotation capabilities<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                        Multisig\u2019s main advantage is its transparency and auditability. Because every participating public key and signature is visible on-chain, external auditors and compliance teams can independently verify that transactions conform to authorized governance structures. This makes it an ideal fit for regulated custody environments that require public accountability.<\/span><\/p>\n

                        Operational Implementation Guide<\/b><\/h2>\n

                        Public Key Lifecycle Management<\/b><\/h3>\n

                        Managing the lifecycle of public keys is critical to maintaining the security of a multisig system:<\/span><\/p>\n

                          \n
                        • Generation Phase:<\/b> Every keyholder must generate their key pairs independently on isolated, secure hardware. Private keys must never leave the physical boundaries of the device. Public keys should be compiled using secure channels, such as face-to-face verification or PGP-encrypted communication.<\/span><\/li>\n
                        • Verification Phase:<\/b> Before deploying assets to a multisig address, the key setup must be cross-verified. This ensures that the compiled public keys match the keyholders’ private keys, protecting against interception or key-substitution attacks during setup.<\/span><\/li>\n
                        • Storage Phase:<\/b> While public keys can be stored openly, their structural integrity must be protected. If an attacker alters the public key registry, it can prevent successful signature verification and lock up funds.<\/span><\/li>\n
                        • Rotation and Updates:<\/b> When corporate membership changes, the organization should generate a new public key set, deploy a new wallet address, and transfer all remaining assets to the updated address.<\/span><\/li>\n<\/ul>\n

                          Signing Protocols and Operational Guidelines<\/b><\/h3>\n

                          To ensure smooth operations, organizations should establish clear guidelines for execution workflows:<\/span><\/p>\n

                            \n
                          • Order Independence:<\/b> Design execution flows so that signatures can be collected in any sequence, preventing operational bottlenecks.<\/span><\/li>\n
                          • Payload Verification:<\/b> Signers must independently verify transaction details (target address, asset amounts, data payloads) on their device screens before signing, rather than relying on external dashboards.<\/span><\/li>\n
                          • Automated Status Notifications:<\/b> The system should notify all keyholders as soon as a signature is added, keeping the team aligned and preventing duplicate work.<\/span><\/li>\n<\/ul>\n

                            Monitoring and Alerts<\/b><\/h3>\n

                            Once a multisig wallet is deployed, it should be monitored continuously:<\/span><\/p>\n

                              \n
                            • Pending Transaction Tracking:<\/b> Track transactions that have been initiated but haven’t reached the signing threshold to keep them from stalling.<\/span><\/li>\n
                            • Signer Activity Audits:<\/b> Monitor how often each keyholder signs transactions to identify inactive keys that may need to be rotated.<\/span><\/li>\n
                            • Anomalous Request Alerts:<\/b> Set up automated alerts for unusual activity, such as signatures requested outside regular working hours, interactions with unverified contract addresses, or rapid consecutive execution requests.<\/span><\/li>\n<\/ul>\n

                              Limitations and Future Outlook<\/b><\/h2>\n

                              Structural Constraints of Multisig<\/b><\/h3>\n

                              While highly effective, standard multisig has a few notable limitations:<\/span><\/p>\n

                                \n
                              • Protocol Fragmentation:<\/b> Implementation logic varies by blockchain, making cross-chain treasury management complex and operationally demanding.<\/span><\/li>\n
                              • High Governance Overhead:<\/b> Updating keyholders requires deploying a new address and migrating assets, which can create significant operational friction for growing organizations.<\/span><\/li>\n
                              • Privacy Trade-offs:<\/b> Because public key sets are visible on-chain, external entities can map corporate governance structures, which may not be ideal for sensitive business operations.<\/span><\/li>\n
                              • Coordination Delays:<\/b> Gathering signatures from distributed keyholders can introduce latency, making it less suitable for time-sensitive market actions.<\/span><\/li>\n<\/ul>\n

                                Integration with Account Abstraction<\/b><\/h3>\n

                                The rise of Account Abstraction (such as ERC-4337) introduces new possibilities for multisig systems. Instead of relying purely on standard on-chain signature aggregation, future implementations can leverage more flexible logic:<\/span><\/p>\n

                                  \n
                                • Signature Compression:<\/b> Aggregating multiple signatures into a single proof significantly reduces on-chain gas fees.<\/span><\/li>\n
                                • Session Key Delegation:<\/b> Temporarily delegating signing authority to a single key for low-risk, high-frequency actions, while reserving the full multisig threshold for large transfers.<\/span><\/li>\n
                                • Conditional Thresholds:<\/b> Dynamically adjusting required signatures and thresholds based on transaction risk, destination addresses, or real-time asset values.<\/span><\/li>\n<\/ul>\n

                                  The Hybrid Multisig-MPC Landscape<\/b><\/h3>\n

                                  Multisig and MPC technologies are beginning to converge into hybrid models that offer the best of both approaches:<\/span><\/p>\n

                                    \n
                                  • Hybrid Key Generation:<\/b> Using off-chain MPC protocols to generate individual signatures that are then submitted to an on-chain multisig setup. This compresses transaction size while preserving on-chain auditability.<\/span><\/li>\n
                                  • Layered Governance Hierarchies:<\/b> Designing configurations where a single public key within an institutional multisig setup is managed internally by a departmental MPC cluster, creating structured, multi-layered authorization architectures.<\/span><\/li>\n<\/ul>\n

                                    This hybrid approach allows organizations to combine the clear transparency and audit readiness of multisig with the operational flexibility and cost savings of MPC frameworks.<\/span><\/p>\n

                                    The Role of Multisig in Digital Asset Governance<\/b><\/h2>\n

                                    Multisig is more than just a multi-signature tool; it is a natural extension of public key cryptography into organizational governance. It shifts risk management away from individual human trusted points and anchors it in distributed, mathematical consensus.<\/span><\/p>\n

                                    In this framework, public keys serve as digital representations of corporate structure: each key represents an authorized operational node, each configuration defines a business policy, and each threshold match represents verified corporate intent. As institutional asset management matures, multisig remains a reliable, time-tested framework for distributed authority, providing a secure foundation for on-chain asset governance.<\/span><\/p>\n

                                     <\/p>\n","protected":false},"excerpt":{"rendered":"

                                    In digital asset governance, establishing authorized decision-making frameworks without relying on a single trusted entity remains a core architectural challenge. Multisignature (multisig) technology, a distributed authorization mechanism built on public key cryptography, offers a robust solution. By eliminating reliance on centralized intermediaries and avoiding additional trust assumptions, multisig leverages mathematical relationships to transition asset control […]<\/p>\n","protected":false},"author":7,"featured_media":14018,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[120],"tags":[],"class_list":["post-14017","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-custody-wallet"],"acf":[],"_links":{"self":[{"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/posts\/14017","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/comments?post=14017"}],"version-history":[{"count":1,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/posts\/14017\/revisions"}],"predecessor-version":[{"id":14019,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/posts\/14017\/revisions\/14019"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/media\/14018"}],"wp:attachment":[{"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/media?parent=14017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/categories?post=14017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/test.keysecure.io\/zh\/wp-json\/wp\/v2\/tags?post=14017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}