# SHx Governance Rules Foundational rules for how SHx governance is conducted. Notes are provided for informational purposes only and are not part of the SHx Governance Rules. ## Article I: Fundamental Principles 1. These Rules establish the governance framework for SHx on the Stellar Network. 2. This is the foundational document to build trust, increase transparency, and ensure the security of the SHx voting process. ## Article II: Definitions 1. SHx Token: The token created with the ID `SHX:GDSTRSHXHGJ7ZIVRBXEYE5Q74XUVCUSEKEBR7UCHEUUEK72N7I7KJ6JH` on the Public Global Stellar Network. SHx is divisible to 7 decimal places. 1. The SHx Soroban Contract ID is `CCKCKCPHYVXQD4NECBFJTFSCU2AMSJGCNG4O6K4JVRE2BLPR7WNDBQIQ` 2. SHx has been created on the Ethereum network as an ERC-20 compatible token with the address `0xee7527841a932d2912224e20a405e1a1ff747084` 2. Total Supply: The total number of SHx tokens existing on the Stellar Network. 3. Circulating Supply: The total number of SHx tokens released and available for participation in governance. Does not include tokens in designated reserve or locked accounts. Includes SHx released and available on both the Stellar and Ethereum networks. 4. Active Circulating Supply: Circulating Supply, with balances in inactive accounts excluded. Inactive accounts are those which have not recorded valid transactions to the ledger in the previous 3 years (1095 days) from the calculation date.\ \ Active Circulating Supply will be reduced by a vote by the voting power that indicates it is not participating in a vote. 5. Super-Majority: Requires a 2/3 (66.67%) vote in favor 6. Simple-Majority: Requires a 50% +1 vote in favor 7. The SHx Governance Rules: This document, which serves as the supreme governing document for SHx governance. 8. The Rules: The operational procedures and guidelines established by this document. 9. Snapshot: A record of token holdings at a specific ledger number used to determine voting power. 10. Quorum: The minimum participation threshold required for a vote to be valid. ## Article III: Governance Structure ### Section 1: Proposal Types 1. Governance Rules Amendment: Any major proposal that amends the established SHx Governance Rules document and requires a super-majority vote (66.67% in favor) 2. Normal Proposal: Modifications to processes and procedures that require a simple majority (50% +1 in favor) ### Section 2: Amendment Powers 1. Governance Rules Amendments 1. Require a super-majority vote of 2/3 (66.67%) in favor 2. Require a minimum Quorum of 25% of the Active Circulating Supply 3. Must be clearly labeled as Amendments in proposals 2. Normal Proposals 1. Require a simple majority vote of 50% + 1 in favor 2. Require a minimum Quorum of 1% of the Active Circulating Supply 3. Abstentions are recorded and will count to Quorum. However, they are NOT counted toward the final percentage calculation. 4. Non-participation will not impact Quorum and will reduce the Active Circulating Supply for that vote. #### Section 3: Question Formats 1. Binary Choice 1. “For”/“Against” voting options 2. “Abstain” option available but not counted toward final percentages 2. Multiple Choice 1. Three or more distinct options 2. Highest percentage winner 3. Abstain option available 3. Weighted Average 1. Where votes for a percentage are totaled for a final weighted percentage 2. Used for budget distribution and similar numerical decisions ## Article IV: Proposal Process ### Section 1: Proposal Lifecycle 1. Community Discussion 1. Initiated in the designated public forum 2. Open Community Discussion period for community feedback 3. Time limits to Community Discussion will be determined by the community 2. Draft Proposal 1. Formal proposal document created in the public forum 2. Must follow standard Proposal Template: 3. Continued Community Discussion and refinement 3. Preliminary Vote 1. Preliminary vote to gauge community support in public forum 2. Requires minimum endorsement voting power threshold equal to 50% + 1 of the Quorum requirement of a Normal Proposal 3. Must pass endorsement to proceed to formal vote 4. Governance Vote 1. Vote leaves public forum and is uploaded into the [SHx Voting Tool](https://vote.stronghold.co/) 2. Binding votes on the Stellar Network 3. Clear start and end times defined by ledger numbers ## Article V: Voting Mechanics ### Section 1: Voting Power 1. Calculation based on SHx holdings at Snapshot 2. One token equals one vote 3. Voting power is calculated as the number of SHx in that account's possession at the vote's designated ledger snapshot. Fractional SHX balances are not counted.\ \ For example, an account holding 24,591.9135 SHX in the ledger snapshot will have a voting power of 24,591. ### Section 2a: Stellar Voting Process #### Voting Requirement A Manage Data operation must be submitted to the ledger with the source account being the voting account. The last operation that the account submits within the voting window will be taken as the vote cast by the account. \ The data entry must be formatted as follows: * `name` => `"SHX::PROP:"`e.g. `"SHX::PROP:1"` * `value` => comma delimited vote positions, e.g. `"FOR,40"` ('for' the first question, at a 40 value for the second). {% hint style="info" %} Note: Many Stellar/Horizon tool and libraries will base64 encode the ASCII bytes for you for submission: note that some blockchain explorers display the data value as decimal bytes. This will not prevent the counting of votes. {% endhint %} #### Reference Voting Implementation The Reference Voting Implementation (hosted at vote.stronghold.co) submits a vote to the ledger in the following manner: A single transaction, having two operations and the memo `"SHX PROPOSAL VOTE"` * Operation 1: `manageData(name: "SHX::PROP:", value: "")` * Operation 2: `manageData(name: "SHX::PROP:", value: "")` The second operation clears the data entry so the account does not incur an ongoing reserve cost. It is not required for the vote to be counted. The memo on the transaction may be used to store metadata for the voting tool, e.g. analytics. #### Vote Management * Voters may change their vote during the voting period by submitting another valid vote to the ledger * An accounts last vote within the voting period recorded overrides all previous votes * No votes accepted before start ledger or after end ledger #### Voting Windows * Voting window start and end times will be determined upon Proposal approval * Start ledger number will be determined as the last ledger that ‘closes’ prior to or at the Proposal’s approved voting start time * End ledger number will be determined as the first ledger that ‘closes’ at or after the voting end time ### Section 2b: Ethereum Voting Process Voting on Ethereum is conducted using the Snapshot platform. The SHX governance space can be found at The operation of the Snapshot space should as closely as possible follow the voting mechanics set forth for the Stellar Voting Process. {% hint style="info" %} Note: SHx Ethereum voting is currently underutilized and so the voting process is not well defined in these Governance Rules. If Ethereum voting usage increases, it is recommended that these Governance Rules be amended as appropriate. {% endhint %} ## Article VI: Implementation 1. The SHx Governance Rules Document becomes effective upon receiving a super-majority approval vote from the SHx holdership 2. All previous governance documents are superseded by the SHx Governance Rules ## Article VII: Amendments 1. Proposals to amend SHx Governance Rules must: 1. Be approved by the supermajority 2. Clearly state the text to be modified 3. Provide rationale for the change 4. Include implementation timeline 5. Follow the formal proposal process 2. Approved amendments become effective: 1. According to the timeline specified in the proposal 2. No sooner than 24 hours after vote confirmation 3. No later than 30 days after vote confirmation

# EDP Learn more about the SHx Ecosystem Development Program (EDP). ## Ecosystem Development Program Stronghold has established the Ecosystem Development Program (EDP) with the mandate of prioritizing and supporting initiatives that accelerate the development of the wider SHx ecosystem. The EDP provides tools, resources, and access to Stronghold products and team members where appropriate to empower those outside of Stronghold who are building in the SHx ecosystem, including SHx-powered StrongholdNET integrations. {% hint style="info" %} Working on a StrongholdNET integration with SHx enabled features? Ask your partner success/integration specialist about how the EDP can assist with engineering consultations and development resourcing! {% endhint %} ### Ecosystem Grants To support the ecosystem and allow for creativity the EDP is holding an open call for proposals. See [Ecosystem Grants](/ecosystem/edp/ecosystem-grants) to learn more. ### Bounties From time to time the EDP may issue bounties for specific projects/activities. To learn more, see [Bounties](/ecosystem/edp/bounties). # Ecosystem Grants ### Ecosystem Grants The EDP accepts proposals for Ecosystem Grants on a rolling basis for projects that enhance and expand the SHx ecosystem. It welcomes innovative ideas across a wide range of categories that contribute to the SHx ecosystem's growth and development. #### Eligible Project Categories Ecosystem Grants can be offered in support of various initiatives, including, but not limited to: * Infrastructure and tooling development * Community engagement and education programs * Integration solutions * Governance tools and improvements * Research and analysis projects #### Application Process 1. Initial Submission * Expected impact on SHx ecosystem * Brief project overview * Team background * Estimated resource requirements * You may upload a slide deck/presentation to answer these questions or use the text entries in the form 2. Full Proposal (by invitation) * Detailed project description and technical specifications * Implementation timeline with clear milestones * Comprehensive budget breakdown * Team qualifications and experience * Success metrics and KPIs * Long-term maintenance and sustainability plan * An interview may be required Initial applications can be submitted at #### Evaluation Criteria Proposals are evaluated based on: * Potential impact on SHx ecosystem * Technical feasibility * Team capability and track record * Resource requirements and cost efficiency * Implementation timeline * Long-term sustainability * Innovation level * Community benefit #### Grant Structure * Funding is disbursed based on achievement of predetermined milestones * Regular progress check-ins with the EDP team * Technical support and mentorship available when needed * Final deliverable requirements specified in grant agreement #### Reporting Requirements Grant recipients must provide: * Milestone completion reports * Final project documentation * Open source code (where applicable) * Community engagement metrics * Also see [General Eligibility](/ecosystem/edp/general-eligibility) # Bounties ### Current Bounties No bounties are currently being offered. Have a proposal for something that benefits the SHx ecosystem? See [Ecosystem Grants](/ecosystem/edp/ecosystem-grants) for an open call for proposals. ### Historic Bounties * VOTE2BOUNTY\ Applications accepted 16 July 2024 to 31 December 2024 $10,000 per award. At least two awards are available.\ \ This bounty is intended to encourage the building of public venues that are contemplated by the passing of the second SHx governance vote: [2 - Establishing a Public Governance Venue and Voting Proxy](/governance/proposals/2-establishing-a-public-governance-venue-and-voting-proxy)\ \ Stronghold currently does not intend to setup its own public venue, nor will it select any single public venue as an 'official' governance venue. Instead, any number of communities may be sources of governance proposals. A future vote may set up the guidelines by which governance proposals are promoted from these venues into 'official' votes.\ \ The definition of 'venue' is broad - it could be a website forum dedicated to SHx, or a community on a larger existing social media site. * The venue must allow for the publishing of, and discussion on, proposals for SHx governance votes. * The venue must be publicly available. Registration requirements (e.g. for signing up and logging into accounts) are OK, but there must be no fee or onerous signup process to be able to comment on proposals. The publishing of new proposals does not have to be available to the wider public. * The venue must incorporate the [SHx Community Guidelines](/community/shx-community-guidelines) into their own community guidelines, and moderate accordingly where possible. Application * Submissions are no longer being accepted. * You will be asked some basic qualification/contact info questions. * You will be asked three questions related to the details of the project: * Briefly, how does allow for the publishing of, and discussion on, proposals for SHx governance? * Tell us more about your project, in text. * Tell us more about your project, via a PDF upload of a document or presentation. * You can complete either or both of the text and file upload details questions. #### # General Eligibility To be eligible for a grant, bounty award, or any support from the Ecosystem Development Program, the recipient must: * Not be a current or former employee or shareholder of the Stronghold group of companies, including 20022Labs * Not be a resident of a country with active OFAC sanctions prohibiting Stronghold from dealing with persons from/in that country * Not be on OFAC's SDN list * In the case of any monetary support * Submit KYC information, including full name, date of birth, proof of address, and copy of passport or other government issued ID * Submit an IRS Form W-8 / W-8 BEN as appropriate # Account Voting Power Learn about how voting power is calculated. ### Voting Power An account's **voting power** indicates the weighting of a vote cast by that account in a proposal. The amount of SHX held in an account at the relevant ledger snapshot gives that account voting power for a particular proposal's vote. #### Ledger Snapshot To calculate SHX account balances for voting, a **snapshot** of the ledger is taken. A time will be announced for the vote, and the first ledger to close after that time will be selected as the snapshot. The snapshot will contain a point-in-time list of all accounts holding SHX and their respective balances. The ledger sequence/height and time will be published, allowing account holders to verify their voting power in advance of the vote. A snapshot of all relevant protocols/blockchains will be taken, which currently includes both Stellar and Ethereum. {% hint style="warning" %} ### Not All Balances Are Equal Since balances are recorded at the account level as per the ledger, to ensure and maximize your voting power, SHX should be moved to an on-ledger wallet that you control the secret key for. Balances held on exchanges will not grant you voting power, as you will not have access to the secret key(s) necessary to sign for that account. In addition, certain accounts (Stronghold owned wallets and other aggregate accounts such as exchanges) will be excluded from the snapshot and therefore have no voting power. {% endhint %} If you have SHx balances across multiple protocols, you must vote with each holding separately, even if the account ID of the wallet holding the balances is the same across those protocols. #### Voting Power Calculation An account's voting power for any governance vote is calculated as the number of SHx in that account's possession at the vote's designated ledger snapshot. Fractional SHX balances are counted. For example, an account holding `24,591.9135 SHX` in the ledger snapshot will have a voting power of `24,591.9135`. ### Stronghold Voting Power SHx in Stronghold's possession will have a voting power of zero. As such, Stronghold will be unable to participate in proposal votes. # Proposals Governance proposals put to vote. If you are looking for the active voting page, please head to | Proposal | Step | | | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | [1 - MCA Origination Fee Burn](/governance/proposals/1-mca-origination-fee-burn) | Complete | This proposal asks whether a portion of the origination fee should be burned instead of paid to contributors. | | [2 - Establishing a Public Governance Venue and Voting Proxy](/governance/proposals/2-establishing-a-public-governance-venue-and-voting-proxy) | Implementation | This proposal asks whether a public venue be established for the submission and discussion of SHx governance proposals by SHx holders. | | [3 - Opening Access to StrongholdNET](/governance/proposals/3-opening-access-to-strongholdnet) | Implementation | This proposal asks which set of APIs should be prioritized for development and release in the StrongholdNET open-access developer console. | | [4 - Adoption of Proposed SHx Governance Rules](/governance/proposals/4-adoption-of-proposed-shx-governance-rules) | Complete | This proposal asks if the proposed SHX Governance Rules be adopted as the foundational rules for how SHx governance is conducted. | | [5 - Recording of Votes in a Smart Contract](/governance/proposals/5-recording-of-votes-in-a-smart-contract) | Implementation | This proposal asks whether SHx governance votes from all ledgers (Stellar & Ethereum) be recorded in a smart contract on the Stellar ledger. | | [6 - Vote Locked SHx (lSHX)](/governance/proposals/6-vote-locked-shx-lshx) | Voting | This proposal asks whether SHx holders should be able to lock their tokens into a smart contract to receive lSHX (locked SHx) with increased voting power. | | [7 - SHx Voting Power Delegation](/governance/proposals/7-shx-voting-power-delegation) | Voting | This proposal asks whether SHx holders should be able to delegate their voting power to other addresses while retaining ownership of their tokens. | # 1 - MCA Origination Fee Burn This proposal asks whether a portion of the origination fee should be burned instead of paid to contributors. {% hint style="success" %} Outcome: FOR. 70% of the origination fee should be burned, with the remaining 30% paid to pool contributors. {% endhint %} | Event | Date | Notes | | ----------------- | ---------------------- | ----------------------------------------- | | Snapshot Time | Nov 27, 2023 20:00 GMT | Stellar ledger sequence 49,210,507 | | Vote Start | Dec 24, 2023 20:00 GMT | First included Stellar ledger: 49,609,988 | | Vote End | Dec 31, 2023 20:00 GMT | Last included Stellar ledger: 49,713,260 | | Results Published | Jan 16, 2024 23:00 GMT | | | Implementation | Q1 2024 | | | Completed | Apr 1, 2024 | | ### Description This proposal asks whether a portion of the origination fee should be burned instead of paid to contributors. Burning involves a payment of SHx back to the issuing account on the ledger. This results in those tokens being destroyed and forever inaccessible, reducing SHx's total supply. As a result, capital contributors will receive a lower proportion of the origination fee and may seek to adjust their participation including altering the offered factor rate. ### Background Merchants who are members of StrongholdNET and who have actively processed payments for at least 3 months are eligible to apply for Merchant Cash Advances. Advances may be used for working capital, storefront improvements, acquisitions, opening locations, and other projects which are expected to increase the value of the business. An origination fee is charged to the merchant at the beginning of the advance period, in SHx, and is used to pay for administrative costs incurred during the underwriting phase. As Stronghold uses an efficient and digitized underwriting model, combined with StrongholdNET payments data, the administrative costs are lower compared to industry averages and the origination fee is instead passed through to contributors as further incentive. The origination fee is an extra benefit for capital contributors to reward them for their continued participation in the MCA program for writing new advances. As an up-front payment, it also adds some de-risking qualities and may offset the factor rate (e.g. similar to an interest rate). ### Voting Notes The vote contains two questions. The first asks whether a proportion of the fees should be burned. The second asks what proportion should be burned, and is taken into account only if the first question passes by simple majority. If the proposal's first question passes, then the burn proportion will be calculated as the weighted average of the second question's voted values, rounded to the nearest 5%, [ties away from zero](https://en.wikipedia.org/wiki/Rounding#Rounding_half_away_from_zero). *** ### Results A total of 210,227,918 voting power participated in the proposal vote. #### Question 1 *Should a portion of the MCA fees should be burned?* | Response | Position | Votes | | -------- | ------------------------------------------------------------------------------------------------ | ----------- | | FOR | A portion of the origination fee should be burned, with the remainder paid to pool contributors. | 204,886,715 | | AGAINST | 100% of the origination fee should continue to be paid to pool contributors. | 3,389,619 | | ABSTAIN | Abstain from voting for this proposal. | 2,951,584 | {% hint style="success" %} Outcome: FOR; a portion of the origination fee should be burned, with the remainder paid to pool contributors. {% endhint %} #### Question 2 *If the proposal to burn a portion of the origination fee is passed, what proportion of the fee should be burned?* The weighted average burn proportion was 69.73%. Rounded to the nearest 5% results in a 70% proportion. {% hint style="info" %} Outcome: 70%; 70% of the origination fee should be burned, with the remaining 30% paid to pool contributors. {% endhint %} # 2 - Establishing a Public Governance Venue and Voting Proxy This proposal asks whether a public venue be established for the submission and discussion of SHx governance proposals by SHx holders. This vote allows Ethereum-based SHx holders to participate. {% hint style="success" %} Outcome: Q1 FOR & Q2 FOR. The public venue and proxy voter should be established. {% endhint %} | Event | Date | Notes | | ----------------- | ---------------------- | ---------------------------------------------------------------------- | | Snapshot Time | Apr 21, 2024 20:00 GMT |

Ledger Sequences

Stellar: 51,340,493 Ethereum: 19,706,027

| | Vote Start | Apr 22, 2024 20:00 GMT | First included Stellar ledger: 51,354,854 | | Vote End | Apr 26, 2024 20:00 GMT | Last included Stellar ledger: 51,412,049 | | Results Published | May 15, 2024 11:30 GMT | | | Implementation | H2 2024 | | ### Description This proposal asks whether a public venue be established for the submission and discussion of SHx governance proposals by SHx holders. SHx holders who are bound by the requirements of the StrongholdNET terms of membership are not invited to participate in this venue. ### Background Wider SHx holdership should be able to discuss, curate, and submit proposals that are put to a a governance vote. A public venue, such as a forum, could be created that allows for the public to discuss proposals. Should this proposal pass, Stronghold will engage with the community to determine a suitable form/software and implement such a venue. Guidance or rules for how proposals become eligible for a vote are not set forth by this proposal, and are suggested to be a topic for future votes. Secondly, StrongholdNET members, or other parties bound by the requirements of the StrongholdNET terms of membership, are required to provide feedback and rule change suggestions via the channels established in the terms of membership. Due to this requirement, these parties will not be able to participate in the the newly created venue, nor are they able to participate in SHx governance directly. To ensure that the voice of the StrongholdNET members are heard in governance proposals, Stronghold seeks to oversee the establishment and administration of a voting proxy, whereby Stronghold can vote on behalf of members according to the relevant terms of membership. Stronghold will not make its own vote via this proxy. ### Voting Notes The vote contains two questions. The first asks whether a public venue be established for the submission and discussion of SHx governance proposals by SHx holders who are not bound by the requirements of the StrongholdNET terms of membership. The second asks whether a proxy voter be established and administered by Stronghold that is able to vote on behalf of StrongholdNET members, and is taken into account only if the first question passes by simple majority. If the proposal's first question passes, then the proxy voter is established if the second question also passes by simple majority. While [1 - MCA Origination Fee Burn](/governance/proposals/1-mca-origination-fee-burn) counted Stellar votes only, this, and subsequent votes, will count votes made on both Stellar and Ethereum. *** ### Results A total of 210,227,918 voting power participated in the proposal vote. #### Question 1 *Should a public venue be established for the submission and discussion of SHx governance proposals by SHx holders who are not bound by the requirements of the StrongholdNET terms of membership?*
ResponsePositionVotes
FORThe venue should be established.164,893,732.27797347
AGAINSTThe venue should not be established.3,265,564.77024
ABSTAINAbstain from voting for question 1.5,692,253.355758299
{% hint style="success" %} Outcome: FOR; the venue should be established. {% endhint %} #### Question 2 *Should a proxy voter be established and administered by Stronghold that is able to vote on behalf of StrongholdNET members?* | Response | Position | Votes | | -------- | ------------------------------------------ | -------------------- | | FOR | The proxy voter should be established. | 131,175,309.42257048 | | AGAINST | The proxy voter should not be established. | 35,762,660.224322 | | ABSTAIN | Abstain from voting for question 2. | 6,913,580.757079199 | {% hint style="success" %} Outcome: FOR; the proxy voter should be established. {% endhint %} # 3 - Opening Access to StrongholdNET This proposal asks which set of APIs should be prioritized for development and release in the StrongholdNET open-access developer console. {% hint style="success" %} Outcome: Choice 3 - US bank to distributed ledger SHX settled USD payment APIs {% endhint %} | Event | Date | Notes | | ----------------- | ---------------------- | ---------------------------------------------------------------------- | | Snapshot Time | Sep 8, 2024 20:00 GMT |

Ledger Sequences

Stellar: 53,407,636 Ethereum: 20,715,302

| | Vote Start | Sep 9, 2024 20:00 GMT | First included Stellar ledger: 53,422,610 | | Vote End | Sep 13, 2024 20:00 GMT | Last included Stellar ledger: 53,482,389 | | Results Published | Sep 24, 2024 20:00 GMT | | | Implementation | Q1 2025 | | ### Description Stronghold is opening access to certain StrongholdNET services to the wider developer ecosystem. This proposal asks which set of APIs should be prioritized for development and release in the StrongholdNET open-access developer console. Developers not affiliated with existing StrongholdNET members, in most jurisdictions, will be able to sign up and interact with certain released StrongholdNET services and endpoints in a sandbox environment. ### Background StrongholdNET APIs are currently available only to developers affiliated with StrongholdNET members: developers working for customers or partner technology providers. Stronghold wishes to open access to certain APIs, allowing the wider ecosystem to understand better the functionality and principles behind some of StrongholdNET's capabilities. To provide access to and assist development, Stronghold will release a developer console that is open to the public. The console will allow for the issuance of API keys that can be used to call the endpoints in a sandbox environment, allowing for development and testing of code that integrates with StrongholdNET. Existing functionality will need to be adapted to work better in sandbox environments and outside of the context of the rest of the StrongholdNET APIs, so effort is required to 'port' over features. Some additional work is required to ensure full coverage of relevant ISO20022 message types, since some older areas in StrongholdNET support messages only to satisfy particular partner companies (and their specific workflows). 1. Distributed ledger to US bank stablecoin payment APIs\ Allows for the settlement of certain USD-denominated stablecoins from distributed ledger technologies to a US bank account. 2. Distributed ledger to US bank USD settled SHX payment APIs\ Allows for the transfer of SHx from distributed ledger technologies to a US bank settled as USD (i.e. an currency conversion occurs). 3. US bank to distributed ledger SHX settled USD payment APIs\ Allows for the transfer of USD from a US bank account to distributed ledger technologies settled as SHx (i.e. an currency conversion occurs). These API endpoints will be made available in both RESTful JSON format as well as allow for the submission of ISO20022 XML messages to effect transmission. Stronghold notes that most developers will not have access to tooling that allows for interacting with ISO20022 messages and sees these endpoints as potentially beneficial to developers looking for experience with this standard. ### Voting Notes The vote asks which StrongholdNET APIs should be prioritized for development and release in the open-access developer console. 1. Distributed ledger to US bank stablecoin payment APIs 2. Distributed ledger to US bank USD settled SHX payment APIs 3. US bank to distributed ledger SHX settled USD payment APIs The choice with the highest vote will be prioritized for first release in the developer console. *** ### Results A total of 173,263,197 voting power participated in the proposal vote. #### Question *Which StrongholdNET APIs should be prioritized for development and release in the open-access developer console?* | Response | Position | Votes | | -------- | ---------------------------------------------------------- | ----------- | | Choice 1 | Distributed ledger to US bank stablecoin payment APIs | 11,896,640 | | Choice 2 | Distributed ledger to US bank USD settled SHX payment APIs | 45,090,814 | | Choice 3 | US bank to distributed ledger SHX settled USD payment APIs | 116,275,743 | {% hint style="success" %} Outcome: Choice 3 - US bank to distributed ledger SHX settled USD payment APIs {% endhint %} # 4 - Adoption of Proposed SHx Governance Rules This proposal asks if the proposed SHX Governance Rules be adopted as the foundational rules for how SHx governance is conducted. {% hint style="success" %} Outcome: FOR. The proposed SHx Governance Rules document should be adopted as the foundational governance framework for SHx. {% endhint %} | Event | Date | Notes | | ----------------- | ---------------------- | ------------------------------------------------- | | Snapshot Time | Dec 11, 2024 20:00 GMT |

Ledger Sequences

Stellar: 54,784,871

| | Vote Start | Dec 16, 2024 20:00 GMT | First included Stellar ledger: 54,857,024 | | Vote End | Dec 21, 2024 20:00 GMT | Last included Stellar ledger: 54,929,175 | | Results Published | Dec 31, 2024 20:00 GMT | | | Implementation | Q1 2025 | | ## Description The vote seeks approval for the adoption of the Proposed SHx Governance Rules document, which establishes the governance framework, voting processes, and amendment procedures for SHx governance on the Stellar and Ethereum networks. ## Background The Proposed SHx Governance Rules are designed to formalize SHx governance, ensuring transparency, security, and trust. Key highlights include: * Voting mechanics based on Active Circulating Supply and token snapshots. * Proposal lifecycle processes, including community discussions, draft proposals, and binding votes. * Governance structures, such as the requirements for super-majority and simple-majority approvals for different types of proposals. Adopting these rules is a foundational step in enhancing Stronghold's decentralized governance approach and streamlining future decision-making processes. ## Voting Notes The vote asks if the Proposed SHx Governance Rules document should be adopted as the foundational governance framework for SHx, passing by simple majority. *** ### Results A total of 158,320,372 voting power participated in the proposal vote. #### Question *Which StrongholdNET APIs should be prioritized for development and release in the open-access developer console?* | Response | Position | Votes | | -------- | ------------------------------------------------------------------------------------------------------------------ | ----------- | | FOR | The proposed SHx Governance Rules document should be adopted as the foundational governance framework for SHx. | 112,393,017 | | AGAINST | The proposed SHx Governance Rules document should not be adopted as the foundational governance framework for SHx. | 0 | | ABSTAIN | Abstain from voting for this proposal. | 45,932,355 | {% hint style="success" %} Outcome: FOR. The proposed SHx Governance Rules document should be adopted as the foundational governance framework for SHx. {% endhint %} # 5 - Recording of Votes in a Smart Contract This proposal asks whether SHx governance votes from all ledgers (Stellar & Ethereum) be recorded in a smart contract on the Stellar ledger. {% hint style="success" %} Outcome: FOR. ​The adoption of the SHx Governance Snapshot unifies all SHx governance votes—from both Stellar and Ethereum—under a single smart contract on the Stellar network. {% endhint %} | Event | Date | Notes | | ----------------- | ---------------------- | ------------------------------------------------- | | Snapshot Time | Mar 12, 2024 20:00 GMT |

Ledger Sequences

Stellar: 56,121,374

| | Vote Start | Mar 17, 2024 20:00 GMT | First included Stellar ledger: 56,197,285 | | Vote End | Mar 21, 2024 20:00 GMT | Last included Stellar ledger: 56,256,292 | | Results Published | Apr 2, 2024 20:00 GMT | | | Implementation | Q2 2025 | | ## Description [SHx Governance Rules](/#section-2a-stellar-voting-process) in Article V of the [SHx Governance Rules](/) currently specify separate methods for recording votes on the Stellar and Ethereum ledgers. With Soroban functionality now stable and available, SHx votes can be recorded in smart contracts rather than as transactions on the Stellar chain or through Snapshot.org for Ethereum. This transition will enhance the capabilities of the SHx governance application through expanded smart contract functionality. This proposal seeks to consolidate the recording of votes from all ledgers into a single smart contract deployed on Soroban, replacing Article V Section 2 entirely. Specific implementation details will be developed following approval of this proposal. ## Background Following the successful launch of Stellar's Soroban smart contracts platform, Stronghold is developing additional Stellar-based smart contract functionality for the SHx ecosystem. These developments include treasury escrows and the proposed voting record system (with snapshots being considered contingent on this proposal's passage). Regardless of this vote's outcome, Stronghold will enhance the SHx voting portal to create a comprehensive governance hub. This hub will facilitate voting, provide access to historical vote information, and connect to SHx-related smart contracts such as escrows for easier inspection. Consolidating votes from all ledgers (Stellar, Ethereum, and any future blockchain integrations) into a Stellar-based smart contract would streamline voting operations. This approach would simplify development of additional voting tools, vote counting mechanisms, and other governance applications. The current system—relying on Snapshot for Ethereum and transaction-based voting for Stellar—presents integration challenges and lacks the elegance and functionality of a dedicated smart contract solution. ## Voting Notes The vote asks whether SHx governance votes from all ledgers (Stellar & Ethereum) be recorded in a smart contract on the Stellar ledger. As a Governance Rules amendment, this proposal requires a two-thirds (2/3) super-majority and a quorum of 25% of the active circulating supply to pass. If necessary, Stronghold will vote in alignment with the simple majority's preference to help implement the community's desired outcome. *** ### Results A total of 78,808,031 voting power participated in the proposal vote. #### Question *Should SHx gov votes from all ledgers (Stellar & Ethereum) be recorded in a smart contract on the Stellar ledger?* | Response | Position | Votes | | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | FOR | The adoption of the SHx Governance Snapshot unifies all SHx governance votes—from both Stellar and Ethereum—under a single smart contract on the Stellar network. | 77,148,850 | | AGAINST | The proposal to record all SHx votes on Stellar smart contracts should not be adopted as the sole voting mechanism for SHx governance. | 0 | | ABSTAIN | Abstain from voting for this proposal. | 1,659,181 | {% hint style="success" %} Outcome: FOR. ​The adoption of the SHx Governance Snapshot unifies all SHx governance votes—from both Stellar and Ethereum—under a single smart contract on the Stellar network. {% endhint %} # 6 - Vote Locked SHx (lSHX) This proposal asks whether SHx holders should be able to lock their tokens into a smart contract to receive lSHX (locked SHx) with increased voting power. | Event | Date | Notes | | ----------------- | ---------------------- | ----------------------------------------- | | Snapshot Time | Sep 07, 2025 20:00 GMT | Stellar Ledger Sequence: 58,824,812 | | Vote Start | Sep 08, 2025 20:00 GMT | First included Stellar ledger: 58,839,906 | | Vote End | Sep 12 2025 20:00 GMT | Last included Stellar ledger: 58,900,084 | | Results Published | Sept 30 2025 20:00 GMT | | | Implementation | | | ## Description Allow SHx holders to lock their tokens into a smart contract to receive lSHX (locked SHx) with increased voting power. Unlike traditional time-lock systems where users commit to a fixed lock duration, this mechanism would allow users to select a notice period upfront—the longer the notice period chosen, the greater the voting power multiplier received. Under this system, locked tokens (lSHx) would maintain their enhanced voting power indefinitely until the holder initiates a withdrawal. To convert lSHx back to SHx, holders must declare their withdrawal intention and wait for their chosen notice period to elapse. Alternatively, holders can bypass the waiting period by accepting a penalty, receiving fewer SHx tokens than they originally locked. Further, a locking mechanism provides a natural platform to build upon for offering additional benefits in the future, such as an equivalent to staking rewards or new utility. ## Background Current SHx governance operates on a one-token-one-vote basis, which can lead to short-term oriented decision-making and allows large holders to influence governance without demonstrating long-term protocol alignment. Many successful DeFi protocols have implemented various locking mechanisms to address these challenges and create stronger alignment between voting power and long-term protocol success. 'Traditional' vote-locking models (like Curve's veCRV) require users to commit to specific lock durations upfront, with voting power decaying over time. This creates friction as users must repeatedly re-lock to maintain voting power and cannot access their capital during emergencies without forfeiting all benefits. Our proposed notice period system offers several advantages: * **Persistent voting power:** Once locked with a chosen notice period, voting power remains constant without decay, eliminating the need for periodic re-locking. * **Flexibility with commitment:** Users can initiate withdrawal at any time, but must honor their committed notice period or pay a penalty. * **Risk-adjusted alignment:** Longer notice periods represent greater protocol alignment and illiquidity risk, justifying higher voting multipliers. * **Emergency exit option:** The penalty mechanism provides liquidity in urgent situations while maintaining the integrity of the commitment system. **Multiplier Structure:** Specific parameters would be finalized in a subsequent vote. For illustration of notice tiers: * 1 week notice: 1.25x voting power * 1 month notice: 1.5x voting power * 3 months notice: 2x voting power * 1 year notice: 4x voting power **Penalty Mechanism:** Early withdrawal penalties would be proportional to the remaining notice period bypassed, with fees burned to benefit all SHx holders through supply reduction or redistributed to other locked balances. This creates a cost for breaking commitments while providing an emergency exit option. Specific parameters would be finalized in a subsequent vote. The notice period model aligns with Stronghold's partner/merchant-focused ecosystem, where business planning cycles and capital commitments often operate on predictable timeframes rather than indefinite locks. This system rewards stability and commitment while acknowledging that circumstances change and flexibility has value. ## Voting Notes This vote contains a single question asking whether the SHx protocol should implement a locking mechanism where tokens can be locked for enhanced voting power based on chosen notice periods for withdrawal. If this proposal passes by simple majority, the development team will begin implementation of the lSHx smart contract system on Stellar. A follow-up proposal will be presented detailing the specific notice period tiers, voting multipliers, and penalty structures based on economic modeling and community feedback. Key implementation considerations that will be addressed post-approval: * Exact notice period options and their corresponding voting multipliers * Penalty calculation formula for early withdrawals * Whether penalties are burned or redistributed A "FOR" vote indicates support for implementing the notice period-based token locking system with enhanced voting power. An "AGAINST" vote indicates that voting power should remain strictly proportional to token holdings without any locking mechanisms. An "ABSTAIN" vote indicates no preference on this matter. As a Governance Rules amendment, this proposal requires a two-thirds (2/3) super-majority and a quorum of 25% of the active circulating supply to pass. If necessary, Stronghold will vote in alignment with the simple majority's preference to help implement the community's desired outcome. ### Results A total of 34,946,244 voting power participated in the proposal vote. #### Question *Should SHx holders who lock tokens receive more voting power?* | Response | Position | Votes | | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | FOR | The adoption of lSHX allows SHx holders to lock tokens into a smart contract and receive lSHX (locked SHx) with increased voting power, determined by a chosen notice period for withdrawal. | 29,878,959 | | AGAINST | The proposal to implement lSHX, allowing SHx holders to lock tokens for enhanced voting power through notice periods, should not be adopted as a governance mechanism for SHx. | 1,658,300 | | ABSTAIN | Abstain from voting for this proposal. | 3,408,985 | {% hint style="success" %} Outcome: FOR. ​The adoption of lSHX allows SHx holders to lock tokens into a smart contract and receive lSHX (locked SHx) with increased voting power, determined by a chosen notice period for withdrawal. {% endhint %} # 7 - SHx Voting Power Delegation This proposal asks whether SHx holders should be able to delegate their voting power to other addresses while retaining ownership of their tokens. | Event | Date | Notes | | ----------------- | ---------------------- | ----------------------------------------- | | Snapshot Time | Sep 07, 2025 20:00 GMT | Stellar Ledger Sequence: 58,824,812 | | Vote Start | Sep 08, 2025 20:00 GMT | First included Stellar ledger: 58,839,906 | | Vote End | Sep 12 2025 20:00 GMT | Last included Stellar ledger: 58,900,084 | | Results Published | Sept 30 2025 20:00 GMT | | | Implementation | | | ## Description Delegation would allow token holders to designate another address to vote on their behalf in governance proposals without transferring the underlying SHx tokens. If implemented, delegation would be voluntary and revocable by the token holder. The delegator would retain full ownership and control of their SHx tokens, including the ability to transfer, stake, or use them in other protocol functions. Only the voting power associated with the tokens would be assigned to the delegate address. Delegation to an address, or revocation, will be able to be performed at most once every 14 days. ## Background Currently, SHx holders must directly participate in governance votes to have their voice heard in protocol decisions. This creates several challenges for the ecosystem: * **Participation barriers:** Many SHx holders may lack the time, technical knowledge, or interest to actively research and vote on every proposal, leading to lower overall governance participation rates. * **Institutional limitations:** Some institutional holders, custodians, or multi-sig wallets face operational constraints that make direct voting difficult or impossible, effectively disenfranchising these stakeholders despite their significant protocol alignment. * **Expertise distribution:** Certain proposals require specialized knowledge. Token holders may prefer to delegate their voting power to subject matter experts for specific types of proposals while retaining the ability to vote directly on others. Delegation systems have been successfully implemented across numerous DeFi protocols, including Compound, Aave, and Uniswap, where they have demonstrably increased governance participation rates and improved decision-making quality. These systems typically allow both self-delegation (explicitly activating one's own voting power) and delegation to third parties. The proposed delegation mechanism would operate on-chain through the Stellar network, ensuring transparency and auditability of all delegations. Delegates would not have access to the underlying tokens, only the voting power, maintaining security for token holders. ## Voting Notes This vote contains a single question asking whether the SHx protocol should implement a delegation system for voting power. The delegation feature, if approved, would be optional. Token holders who do not actively delegate would retain their direct voting power as they do currently. A "FOR" vote indicates support for implementing voting power delegation in the SHx protocol. An "AGAINST" vote indicates that voting should remain limited to direct participation only. An "ABSTAIN" vote indicates no preference on this matter. As a Governance Rules amendment, this proposal requires a two-thirds (2/3) super-majority and a quorum of 25% of the active circulating supply to pass. If necessary, Stronghold will vote in alignment with the simple majority's preference to help implement the community's desired outcome. ### Results A total of 34,946,244 voting power participated in the proposal vote. #### Question *Should SHx voting power be shareable through delegation?* | Response | Position | Votes | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | FOR | The proposal to enable SHx voting power to be shareable through delegation should be adopted, allowing holders to assign their governance influence to other participants. | 26,626,409 | | AGAINST | The proposal to enable SHx voting power to be shareable through delegation should not be adopted, and voting power should remain non-transferable and limited to the original holder. | 4,858,762 | | ABSTAIN | Abstain from voting for this proposal. | 3,461,073 | {% hint style="success" %} Outcome: FOR. ​The proposal to enable SHx voting power to be shareable through delegation should be adopted, allowing holders to assign their governance influence to other participants. {% endhint %} # Voting Process How to vote on SHx proposals. ### Multi-Ledger Voting The process for voting is different depending on where your SHx voting power resides, i.e. which ledger you have SHx on. Click on link below that corresponds to the ledger you have SHx on that you wish to vote using. {% content-ref url="/pages/Gf7AdNnmTP52NXZGmlu2" %} [Stellar](/governance/voting-process/stellar) {% endcontent-ref %} {% content-ref url="/pages/ZcgqBF6isr288JyjJh2l" %} [Ethereum](/governance/voting-process/ethereum) {% endcontent-ref %} # Stellar Voting for SHx voting power on Stellar. ### How to Vote Stronghold provides an interface allowing you to create and submit your vote easily, and without having to reveal your secret key. This is enabled through the use of either a **WalletConnect** enabled wallet or the Stellar Development Foundation's open source **Freighter** browser extension. #### WalletConnect You can cast your vote using a WalletConnect enabled wallet, such as Lobstr. {% embed url="" %} The process for connecting your wallet will vary depending on the particular wallet you are using. Generally the process involves downloading the wallet's mobile app and scanning the QR code on the voting interface to connect and sign your vote. For information on Lobstr's WalletConnect implementation, see [here](https://lobstr.freshdesk.com/support/solutions/articles/151000001589-walletconnect-how-to-log-in-and-use-your-stellar-wallet-from-lobstr-with-other-services).
WalletConnect QR Code

WalletConnect QR code on the voting page. Scan this with your mobile wallet.

#### Freighter Another option for voting is using the Freighter extension. You may need to import your voting account in separately, depending on whether you have a seed phrase or secret key available. {% embed url="" %} 1. Install [Freighter](https://www.freighter.app/) in a compatible web browser. 2. Either create a new Freighter wallet (this account does not need to be used/funded for voting), or if you have a 12-word seed phrase for your account, you can import your wallet into freighter. 3. Import the secret key for your voting account into Freighter. Skip this step if you created a new Freighter wallet. 4. Ensure the correct account is selected for voting.

To import your voting account click on your avatar

Then choose Import a Stellar secret key

Ensure the correct account is selected for voting

#### Voting With either a WalletConnect wallet or Freighter installed and your voting account selected, you are ready to vote on proposals! When the voting window for a proposal is open, head to [vote.stronghold.co](https://vote.stronghold.co/). {% embed url="" %} 1. Review the proposal. 2. When you are ready to vote, click *Cast Vote.* 3. Make your voting selections and click on your preferred connection method. 4. If this is your first time interacting with the voting interface, your wallet or Freighter will ask your permission to share your public key. 5. Your wallet or Freighter will ask you to confirm your voting transaction, showing you the operations that add your vote into the ledger. 6. Your transaction will be submitted to the ledger via the Stellar Development Foundation's publicly available 'Horizon' API server. Usual Stellar network fees apply. You will be shown a confirmation with a link to the transaction in a blockchain explorer once successful. * Occasionally Horizon may fail to submit your transaction to the ledger. If this is the case, please submit your vote again.

Vote confirmation. If you see this, your vote has been recorded successfully!

### Manual Voting If you cannot use either WalletConnect or Freighter via the SHx voting interface, you may create and submit your vote manually. The Stellar Development Foundation [hosts a tool](https://laboratory.stellar.org/#?network=public) which may be of use if your wallet does not provide the ability to add [Manage Data](https://developers.stellar.org/api/horizon/resources/operations/object/manage-data) operations. #### Requirement A [Manage Data](https://developers.stellar.org/api/horizon/resources/operations/object/manage-data) operation must be submitted to the ledger with the **source account being the voting account**. The **last** operation that the account submits **within the voting window** will be taken as the account's casted vote. The data entry must be formatted as follows, using the first proposal, [1 - MCA Origination Fee Burn](/governance/proposals/1-mca-origination-fee-burn) as an example: * `name` => `"SHX::PROP:"`, e.g. `"SHX::PROP:1"` * `value` => comma delimited vote positions, e.g. `"FOR,40"` ('for' the proposal, at a 40% burn proportion). Most Stellar/Horizon tool and libraries will base64 encode the ASCII bytes for you for submission. Note that some blockchain explorers display the data value as decimal bytes. This will not prevent the counting of votes. #### Reference The reference voting implementation, hosted at [vote.stronghold.co](https://vote.stronghold.co), submits a vote to the ledger in the following manner: * A single transaction, having two operations and the memo `"SHX PROPOSAL 1 VOTE"` * Operation 1: `manageData(name: "SHX::PROP:1", value: "")` * Operation 2: `manageData(name: "SHX::PROP:1", value: "")` The second operation clears the data entry so the account does not incur the ongoing reserve cost. It is not required for the vote to be counted. The memo on the transaction is also optional. ### FAQs * **Can I vote using Lobstr?**\ Yes, Lobstr supports the WalletConnect protocol. When voting, select the WalletConnect connection method and scan the QR code from the Lobstr app. * **Can I disconnect the WalletConnect connection after I vote?**\ Yes, you may safely disconnect the SHx connection after you have submitted your vote. * **How do I set up Freighter?**\ See our [Youtube walkthrough](https://www.youtube.com/watch?v=LxPMzEMC96Y) or [read about it](https://docs.shx.stronghold.co/governance/voting-process#freighter). * **How do I vote?**\ We've got a [Youtube tutorial here](https://www.youtube.com/watch?v=eYIkkwXcdOQ), or a [step-by-step writeup here](https://docs.shx.stronghold.co/governance/voting-process#voting). * **I accidentally voted more than once! Does my vote still count?**\ The last vote submitted to the ledger within the voting window will be taken as the account's cast vote. Any other vote submissions will be ignored. * **Do I have to use WalletConnect or Freighter to vote?**\ You can [manually vote](https://docs.shx.stronghold.co/governance/voting-process#manual-voting). [Stellar Laboratory](https://laboratory.stellar.org/#?network=public) may be of help for you to manually vote. * **Does it cost to vote?**\ While there is no additional fee for the vote itself, usual Stellar XLM ledger transaction fees will apply as your vote is recorded as an operation on the ledger. # Ethereum Voting for SHx voting power on Ethereum. Voting on Ethereum is conducted using the [Snapshot.org](https://snapshot.org/) platform. To visit the SHx Snapshot space, follow the link below: {% embed url="" %} # SHx Community Guidelines Official Stronghold social media accounts/spaces, as well as non-Stronghold SHx related communities, abide by the following SHx community guidelines to foster a respect and engagement environment. ## Guidelines * **Respectful Communication:** Treat everyone with respect. Discriminatory, offensive, or hateful comments will not be tolerated. Harassment, bullying, or threatening behavior of any kind is prohibited. * **Relevant Content:** Stay On Topic and ensure your comments and posts are relevant to the content being discussed. Avoid posting spam, repetitive comments, irrelevant links, or unsolicited promotional content. * **Privacy and Safety:** Do not share personal information, either your own or others', such as addresses, phone numbers, or financial information. Report any suspicious or inappropriate behavior to the moderators. * **Constructive Feedback:** When providing feedback, make it constructive and aim to help improve the community. Avoid making comments designed to provoke or upset others. * **Compliance with Laws:** Ensure your posts comply with all applicable laws and regulations. Do not share content that you do not own or have permission to share. * **Moderation and Enforcement:** Respect the decisions and instructions of the moderators. Understand that violations of these guidelines may result in content removal, temporary bans, or permanent expulsion from the community. * **Community Contributions:** Strive to contribute positively to the community by sharing helpful and insightful content. Encourage others to participate and share their thoughts in a respectful manner. * **Language and Tone:** Use appropriate language at all times. Avoid using profanity or language that could be considered offensive. Maintain a positive and encouraging tone in all interactions. * **Dispute Resolution:** If disagreements arise, handle them calmly and respectfully. If you cannot resolve a dispute, seek help from a moderator. #### Official Stronghold Accounts * **No Endorsement:** In accordance with our compliance policies, we are unable to follow individual community members or interact directly with their social media accounts. This policy helps us maintain the integrity and impartiality of our interactions. Stronghold does not necessarily endorse any followed accounts, liked or otherwise highlighted content.