Governance in Heritage starts with positions, stewardship, and operator accountability.

Heritage does not begin governance with proposals. It begins with position structure. WrappedHeritageShare turns a single Heritage ERC-1155 token id into an ERC-20 position with transferability, permit support, delegated voting, and unwrap back into the underlying share position.

That matters because it gives the protocol a real voting substrate without pretending that a complete legislative interface already exists. Delegation and ERC20Votes checkpoints are the implemented mechanics that support governance language in the repo today.

Yield participation also builds on this wrapped-share structure. The governance story is therefore tied to how positions are wrapped, delegated, and monitored, not to a speculative parliament UI.

Heritage publicly frames governance and custody around a 51 / 49 model. In practical terms, that means custody continuity, verification, title integrity, and stewardship remain the leading priorities in the product story.

This framing is real and intentional, but it is still framing. The repository does not contain a self-executing 51 / 49 governance machine. The number should be read as the philosophy behind the experience rather than as a claim that every governance process has already been codified on-chain.

The repository includes a separate governance layer for platform operations. Admin memberships map wallets to explicit roles and permissions, and sensitive actions are written into an admin activity log. This is how registry, compliance, yield, and protocol work are actually delegated today.

In other words, Heritage already has an internal governance model even though it does not yet have a public proposal chamber. The real operational controls are role assignment, permission scoping, review discipline, and auditability.