Transaction Details

API

Overview Execution Plan Enhanced Plan Tree Plan Receipts Summary

Receipt:

Gbjn6PnhxxqwVCQsZ3YrhtxuDCaBVGu4TRswXWAQsWTX

Status:

Success

Block:

209,896,602

Timestamp:

Aug 4, 2026 13:46:53.777 +00:00

From:

haenkohostesting1.near(ed25519:6mkk3XBN5GbuY9KkBMNMcQgs4YEWKjEun3mqj47bnGxV)

To:

vote.degenhostest.near

Value:

0.30843 Ⓝ($0.50)

Burnt Gas:

3.255 Tgas

Burnt Tokens:

0.000326 Ⓝ

Actions:

Called method create_proposal in contract vote.degenhostest.near

{

"flow": "Classic",

"actions": null,

"metadata": {

"link": "https://gov.near.org/t/hsp-xxx-evgeny-test-5/42441",

"title": "Evgeny test 5",

"description": "## Frontmatter\\n\\n```\\ntitle: Evgeny test 5\\ndescription: Add a preview and validation step before proposal submission to reduce formatting errors and incomplete proposals.\\nauthor: Alex Example <[email protected]>\\ndiscussions-to: https://staging-gov.houseofstake.org/proposals/cmsephj1z0009s00sp8mv55mb\\nstatus: Draft\\ntrack: Decision\\ntype: Simple Majority\\ncategory: Governance Tooling\\nstakeholders: Proposal Authors, Governance Portal Engineering Team, House of Stake Secretariat, QA Reviewers\\ncreated: 2026-08-04\\n```\\n\\n## Abstract\\n\\nThis proposal introduces a preview and validation step before a governance proposal is submitted. Authors will be able to review the rendered proposal, identify missing required sections, and correct common formatting errors before publication. The change matters because incomplete or malformed proposals create unnecessary review work, delay governance discussions, and reduce confidence in the submission process. The expected outcome is a clearer and more reliable authoring experience, fewer invalid submissions, and less manual intervention by governance administrators.\\n\\n## Payload\\n\\n<details>\\n<summary>Proposal Validation Rules v1</summary>\\n\\nBefore a proposal can be submitted, the governance portal shall:\\n\\n1. Confirm that all required frontmatter fields are present.\\n2. Confirm that the description does not exceed 140 characters.\\n3. Confirm that the abstract does not exceed 120 words.\\n4. Confirm that all required proposal sections exist.\\n5. Display a rendered preview of the proposal.\\n6. Clearly identify validation errors and warnings.\\n7. Prevent submission while blocking errors remain.\\n8. Allow authors to return to editing without losing entered content.\\n9. Record the validation version used during submission.\\n\\nWarnings may be displayed for recommended but non-blocking content. Warnings shall not prevent submission unless they correspond to an explicitly required governance rule.\\n\\n</details>\\n\\n## Context\\n\\nThe current proposal-authoring workflow allows authors to enter structured governance content, but authors may not always know whether their submission satisfies formatting and content requirements until after publication.\\n\\nIncomplete sections, invalid frontmatter values, incorrect character limits, and malformed Markdown can create additional work for reviewers and governance administrators. These issues may also require authors to withdraw and recreate proposals.\\n\\nCommunity discussions and internal testing have identified preview and validation as useful safeguards before publication. This proposal formalizes those safeguards as part of the standard submission workflow.\\n\\nNo previous HSP is required for this proposal.\\n\\n## Problem\\n\\nProposal authors can accidentally submit incomplete, incorrectly formatted, or difficult-to-read proposals.\\n\\nThe current workflow does not consistently provide authors with a final rendered preview or clear validation feedback before submission. As a result:\\n\\n* Required sections may be missing.\\n* Frontmatter values may be invalid.\\n* Character or word limits may be exceeded.\\n* Markdown formatting may render unexpectedly.\\n* Reviewers may spend time identifying basic formatting problems instead of evaluating proposal substance.\\n\\nThis reduces the efficiency and reliability of the governance process.\\n\\n## Approach\\n\\nThe governance portal will introduce a mandatory review step between editing and final submission.\\n\\nDuring this step, the portal will validate required content and display the proposal as it will appear after publication. Blocking errors will prevent submission, while non-blocking warnings will inform authors about potential improvements.\\n\\nThis approach is preferred over manual review because it provides immediate and consistent feedback. It is also preferred over silently correcting content because automatic corrections could change the author\\u{2019}s intended meaning.\\n\\nThe approach will not evaluate the political quality, feasibility, or expected impact of a proposal. It will only assess structural and formatting requirements that can be checked consistently.\\n\\n## End-to-end Value Hypothesis\\n\\nThe proposal delivers standalone value by improving the complete proposal-submission workflow.\\n\\nAn author drafts a proposal, receives validation feedback, reviews the rendered result, corrects identified errors, and submits a structurally complete proposal. Reviewers then receive a proposal that satisfies the portal\\u{2019}s minimum formatting and content requirements.\\n\\nThe value does not depend on a future governance proposal or an undefined third-party service. All necessary validation, preview, editing, and submission functionality is included within the proposed scope.\\n\\n### Objective\\n\\nIntroduce a mandatory proposal preview and structural validation step before final submission through the governance portal.\\n\\n### Outcome\\n\\nProposal authors experience a clearer and more predictable submission process.\\n\\nGovernance reviewers receive fewer proposals with missing sections, invalid metadata, or broken formatting. Governance administrators spend less time requesting basic corrections, while discussions can focus more directly on the substance of each proposal.\\n\\n### Dependencies\\n\\n1. **Existing governance portal**\\n\\n The proposal depends on the existing portal used to create and submit proposals.\\n\\n Evidence of existence: the portal already provides proposal creation and submission functionality.\\n\\n2. **Existing proposal template**\\n\\n Validation depends on the current HSP template and its required sections.\\n\\n Evidence of existence: the template is currently presented to authors during proposal creation.\\n\\n3. **Markdown rendering component**\\n\\n The preview requires the portal\\u{2019}s existing Markdown renderer or an equivalent supported rendering component.\\n\\n Evidence of existence: submitted proposals are currently displayed as rendered Markdown.\\n\\n4. **Proposal storage system**\\n\\n Draft content must remain available when an author moves between editing and preview.\\n\\n Evidence of existence: the portal already stores proposal content during the creation process.\\n\\nNo new third-party infrastructure is required.\\n\\n## Key Performance Indicators (KPIs)\\n\\n1. **Validation completion rate**\\n\\n Percentage of authors who successfully resolve all blocking errors and reach the submission step.\\n\\n Data source: anonymized portal validation events.\\n\\n2. **Invalid submission reduction**\\n\\n Change in the number of submitted proposals requiring correction because of missing sections, invalid frontmatter, or formatting errors.\\n\\n Data source: administrator review records and proposal status history.\\n\\n3. **Author correction rate**\\n\\n Percentage of preview sessions in which an author returns to editing and changes proposal content before submission.\\n\\n Data source: anonymized preview and editing events.\\n\\n4. **Submission abandonment rate**\\n\\n Percentage of proposal drafts abandoned after validation begins.\\n\\n Data source: anonymized draft lifecycle events.\\n\\n5. **Reviewer feedback**\\n\\n Qualitative feedback from proposal reviewers regarding readability, completeness, and time spent identifying structural issues.\\n\\n Data source: reviewer survey conducted after the first 30 submitted proposals using the new workflow.\\n\\nPersonal proposal content shall not be included in analytics beyond the information already available through published governance records.\\n\\n## Technical Specification\\n\\nThe governance portal shall add a validation service and preview interface to the proposal-creation workflow.\\n\\nThe validation service shall check:\\n\\n* Presence of required frontmatter fields.\\n* Supported values for status, track, and type.\\n* Maximum description length.\\n* Maximum abstract word count.\\n* Presence of required headings.\\n* Presence of stakeholder assignments.\\n* Presence of exactly one Accountable party for each stakeholder activity.\\n* Valid milestone table structure.\\n* Valid discussion URL format.\\n* Basic Markdown structure.\\n\\nValidation results shall use two severity levels:\\n\\n* **Error:** must be resolved before submission.\\n* **Warning:** should be reviewed but does not prevent submission.\\n\\nEach result shall include:\\n\\n* A validation identifier.\\n* Severity.\\n* A human-readable explanation.\\n* The affected field or section.\\n* A suggested correction where applicable.\\n\\nThe preview shall use the same Markdown rendering behavior as the published proposal view.\\n\\nDraft content shall remain unchanged unless the author explicitly edits it. The validation service shall not automatically rewrite proposal content.\\n\\nThe submitted proposal record shall include the validation ruleset version used at the time of submission.\\n\\n## Backwards Compatibility\\n\\nThis proposal does not change the meaning or governance effect of existing proposals.\\n\\nPreviously submitted proposals will remain valid and will not be retroactively checked against the new validation rules.\\n\\nExisting proposal URLs, identifiers, discussions, voting records, and statuses will remain unchanged.\\n\\nThe new workflow only applies to proposals created or edited after the feature is activated. Drafts created before activation may be validated when they are next opened, but authors shall be able to review all identified issues before submission.\\n\\n## Security Considerations\\n\\n1. **Content loss**\\n\\n Risk: authors may lose entered content when moving between editing and preview.\\n\\n Mitigation: automatically save drafts before validation and preserve the most recent recoverable version.\\n\\n2. **Incorrect validation**\\n\\n Risk: a validation rule may incorrectly block a valid proposal.\\n\\n Mitigation: version validation rules, test them against representative proposals, and provide administrators with an emergency rule-disable mechanism.\\n\\n3. **Preview and published output mismatch**\\n\\n Risk: the preview may render differently from the published proposal.\\n\\n Mitigation: use the same rendering component and configuration for both views.\\n\\n4. **Malicious Markdown or embedded content**\\n\\n Risk: proposal content may contain unsafe HTML, scripts, or external resources.\\n\\n Mitigation: sanitize rendered content, disable executable scripts, and apply the portal\\u{2019}s existing content security policy.\\n\\n5. **Analytics privacy**\\n\\n Risk: validation analytics could expose unpublished proposal content.\\n\\n Mitigation: collect event types and validation identifiers without storing draft text in analytics systems.\\n\\n6. **Submission bypass**\\n\\n Risk: an author may attempt to bypass client-side validation.\\n\\n Mitigation: repeat all blocking validation checks on the server before accepting a submission.\\n\\n## Stakeholders\\n\\n| Activity / Decision | Responsible | Accountable | Consulted | Informed |\\n| ------------------------------------ | ---------------------------------- | -------------------------- | ---------------------------------------------------- | ----------------------------------------- |\\n| Define validation rules | Governance Portal Engineering Team | House of Stake Secretariat | QA Reviewers, Proposal Authors | Governance Body Members |\\n| Implement validation service | Governance Portal Engineering Team | Engineering Lead | House of Stake Secretariat, Security Reviewer | Proposal Authors |\\n| Test preview and validation workflow | QA Reviewers | QA Lead | Governance Portal Engineering Team, Proposal Authors | House of Stake Secretariat |\\n| Approve production release | Engineering Lead | House of Stake Secretariat | QA Lead, Security Reviewer | Governance Body Members, Proposal Authors |\\n| Review initial performance data | Governance Analyst | House of Stake Secretariat | QA Lead, Proposal Authors | Governance Body Members |\\n\\n## Implementation Plan\\n\\n### Definition of Done\\n\\nThe proposal will be considered implemented when:\\n\\n1. Required frontmatter and proposal-section validation is available.\\n2. Description and abstract limits are validated.\\n3. Errors and warnings are displayed next to the relevant fields or sections.\\n4. Authors can open a rendered proposal preview.\\n5. Authors can return to editing without losing content.\\n6. Server-side validation prevents invalid submissions.\\n7. Existing submitted proposals remain unchanged.\\n8. Automated tests cover all blocking validation rules.\\n9. Security testing confirms that unsafe rendered content is sanitized.\\n10. User documentation explains errors, warnings, and the preview workflow.\\n11. The feature is released to all proposal authors.\\n12. Initial KPI data is collected and reviewed.\\n\\nImplementation progress will be reported weekly in the linked forum discussion. Each report will include completed work, current blockers, identified risks, and the next planned deliverable.\\n\\nCritical defects that may cause data loss, security exposure, or invalid proposal publication will be reported immediately.\\n\\n## Milestones\\n\\n| Milestone name | Target date | Deliverable | Success criteria |\\n| -------------------------------- | ----------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------ |\\n| Validation rules approved | 2026-08-15 | Versioned validation ruleset and test cases | All required template fields and sections have documented validation behavior |\\n| Preview prototype completed | 2026-08-31 | Working preview and validation interface in a test environment | Authors can preview a draft, view errors, and return to editing without content loss |\\n| Security and QA review completed | 2026-09-15 | QA report, security review, and resolved defect list | No unresolved critical defects and all blocking rules pass automated tests |\\n| Production release | 2026-09-30 | Preview and validation workflow available in production | Server-side validation is active and existing proposals remain accessible |\\n| Initial impact review | 2026-11-15 | KPI summary and reviewer feedback report | Data from at least 30 proposal validation sessions has been evaluated |\\n\\n## Budget & Resources\\n\\nNot applicable.\\n\\nThe proposal requests no governance funding. Implementation will use the existing governance portal infrastructure and the engineering and QA resources already allocated to portal maintenance.\\n\\n## Conflict of Interest\\n\\nThe author has read and agrees with the House of Stake Conflict of Interest policy.\\n\\nThe author declares no known financial, organizational, or personal conflict of interest related to this proposal.\\n\\nThe author is participating only for testing, documentation, and proposal-workflow evaluation purposes.\\n\\n## Copyright\\n\\nCopyright and related rights waived via CC0 1.0.\\n\\n",

"voting_options": [

"For",

"Against",

"Abstain"

]

}

Result:

268

Logs:

{  "standard": "venear",  "version": "1.0.0",  "event": "create_proposal",  "data": [    {      "proposer_id": "haenkohostesting1.near",      "proposal_id": 268    }  ]}

Receipt:

GjRf9bvqNXqWXq4Hf14rX4Bxw7Az8hybStaFXFAyCvHE

Status:

Success

Block:

209,896,603

Timestamp:

Aug 4, 2026 13:46:54.445 +00:00

From:

vote.degenhostest.near(ed25519:6mkk3XBN5GbuY9KkBMNMcQgs4YEWKjEun3mqj47bnGxV)

To:

haenkohostesting1.near

Value:

0.05099 Ⓝ($0.08)

Burnt Gas:

0.223 Tgas

Burnt Tokens:

0.000022 Ⓝ

Actions:

Transfer 0.05099

{

"deposit": "50990000000000000000000"

}

Result:

Empty Result

Logs:

No Logs

Receipt:

AmAMyLwbjVf8rcW9knk3g986sZDwEECiUiYcYsbPRYWN

Status:

Success

Block:

209,896,604

Timestamp:

Aug 4, 2026 13:46:55.044 +00:00

From:

system

To:

haenkohostesting1.near

Value:

0.000201 Ⓝ($0.00032)

Burnt Gas:

0.223 Tgas

Burnt Tokens:

0 Ⓝ

Actions:

Transfer 0.000201

{

"deposit": "200864306250000000000"

}

Result:

Empty Result

Logs:

No Logs

Receipt:

4pEoaBcXNk7ZG28Jc7PdAcGBb9yJsCHwpDsCS9tS38tR

Status:

Success

Block:

209,896,603

Timestamp:

Aug 4, 2026 13:46:54.445 +00:00

From:

system

To:

haenkohostesting1.near

Value:

0.100375 Ⓝ($0.16)

Burnt Gas:

0.223 Tgas

Burnt Tokens:

0 Ⓝ

Actions:

Transfer 0.100375

{

"deposit": "100374638139857300000000"

}

Result:

Empty Result

Logs:

No Logs