mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +00:00
zeekayandHanzo Dev
178febad68
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across the paper corpus is rewritten to the correct canonical chain by concern: threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM); FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport / cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes). Braided "T-Chain" sections split by concern (M vs F). Only lp-020's chain-separation rationale and the shared lux/chains/thresholdvm library path retain the name, to record the removal. All changed papers rebuilt (pdflatex, rc=0, no undefined refs). §09 of lux-dao-governance-framework reframed: fabricated "production deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024") relabeled as illustrative design configurations with no invented replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion echo + one "first production" overclaim softened. This commit also captures concurrent corpus workstreams on the same tree. Co-authored-by: Hanzo Dev <[email protected]>
57 lines
1.9 KiB
TeX
57 lines
1.9 KiB
TeX
\section{Holographic Consensus}
|
||
|
||
|
||
\subsection{Scalable Governance Mechanism}
|
||
|
||
Traditional DAOs require all token holders to review every proposal, leading to:
|
||
\begin{itemize}
|
||
\item \textbf{Voter fatigue}: Overwhelmed by proposal volume
|
||
\item \textbf{Low participation}: <5\% typical voting rates
|
||
\item \textbf{Gridlock}: Important proposals blocked by apathy
|
||
\end{itemize}
|
||
|
||
\textbf{Holographic consensus} solves this through \emph{prediction markets} that filter proposals:
|
||
|
||
\begin{algorithm}[H]
|
||
\caption{Holographic Consensus Filtering}
|
||
\begin{algorithmic}[1]
|
||
\Function{FilterProposal}{$proposal, predictionMarket$}
|
||
\State $stake \gets$ InitializePredictionMarket($proposal$)
|
||
\State $supporters \gets$ StakeFor($proposal$)
|
||
\State $opponents \gets$ StakeAgainst($proposal$)
|
||
|
||
\If{$supporters > threshold$}
|
||
\State \textbf{return} \texttt{BOOSTED} \Comment{Fast-track to full DAO vote}
|
||
\ElsIf{$opponents > threshold$}
|
||
\State \textbf{return} \texttt{REJECTED} \Comment{Filtered out early}
|
||
\Else
|
||
\State \textbf{return} \texttt{REGULAR} \Comment{Normal governance queue}
|
||
\EndIf
|
||
\EndFunction
|
||
\end{algorithmic}
|
||
\end{algorithm}
|
||
|
||
\subsection{Prediction Market Mechanics}
|
||
|
||
\textbf{Staking for Prediction}:
|
||
\begin{itemize}
|
||
\item Supporters stake tokens predicting proposal will pass
|
||
\item Opponents stake predicting proposal will fail
|
||
\item Winner receives staked tokens from losing side (minus 2\% protocol fee)
|
||
\end{itemize}
|
||
|
||
\textbf{Incentive Alignment}:
|
||
\begin{itemize}
|
||
\item High-quality proposals attract supporter stakes (boosted)
|
||
\item Low-quality proposals attract opponent stakes (filtered)
|
||
\item Reduces voter fatigue by pre-filtering proposals
|
||
\end{itemize}
|
||
|
||
\textbf{Projected outcomes} (design targets, not measured):
|
||
\begin{itemize}
|
||
\item 87\% of boosted proposals ultimately pass full DAO vote
|
||
\item 91\% of filtered proposals would have failed DAO vote
|
||
\item 3× improvement in voter participation for boosted proposals
|
||
\end{itemize}
|
||
|