MRPoS: Dual Contexts in Blockchain and Robotics

• MRPoS is an overloaded acronym with dual meanings: a blockchain protocol using multi-agent reinforcement learning for PoS and a mixed-reality interface for robot navigation.
• In blockchain, MRPoS integrates reinforcement learning to dynamically manage validator reputation, enhancing leader selection and detecting malicious nodes.
• In robotics, MRPoS combines spatial pointing and speech with MR visualization to enable efficient robot goal specification, with minor trade-offs in orientation accuracy.

MRPoS is an overloaded research acronym whose meaning depends on disciplinary context. In blockchain research, it commonly denotes shorthand for MRL‑PoS, a Multi‑agent Reinforcement Learning based Proof‑of‑Stake protocol, and in some usage also for the related MRL‑PoS+ variant; both embed a multi‑agent reinforcement learning–style reputation and penalty‑reward layer into Proof‑of‑Stake validator selection and malicious-node handling (Islam et al., 2023, Bappy et al., 2024). In robotics and human–robot interaction, MRPoS denotes the Mixed Reality‑Based Robot Navigation Interface using Spatial Pointing and Speech, an MR interface that combines spatial pointing, speech, and a LLM to specify robot navigation goals visualized as MR‑beacons (Iglesius et al., 4 Mar 2026). The acronym therefore does not identify a single standardized method; it names distinct systems in different technical literatures.

1. Terminological scope and disambiguation

Within the blockchain literature, MRL‑PoS stands for Multi‑agent Reinforcement Learning based Proof‑of‑Stake, and the shortened query form “MRPoS” is described as a natural shorthand for that protocol even though the exact compressed term is not explicitly used in the underlying paper (Islam et al., 2023). A later security-oriented extension, MRL‑PoS+, is likewise described as being “sometimes loosely referred to as ‘MRPoS’ in shorthand,” again in a PoS consensus context (Bappy et al., 2024). In robotics, by contrast, MRPoS is the exact name of a multimodal mixed-reality interface: Mixed Reality‑Based Robot Navigation Interface using Spatial Pointing and Speech (Iglesius et al., 4 Mar 2026).

This dual usage matters because the two families are unrelated in objective, architecture, and evaluation. The blockchain usage concerns validator election, malicious-node detection, and adaptive reputation in decentralized consensus. The robotics usage concerns front-end goal specification for mobile robots using HoloLens 2, ROS 2, spatial pointing, and LLM-based speech parsing. This suggests that MRPoS should be interpreted strictly from local domain cues such as references to PoS, validators, and stake, or alternatively to MR‑beacons, HoloLens, and ROS.

2. MRL‑PoS as a reinforcement-learning Proof‑of‑Stake protocol

MRL‑PoS is fundamentally a Proof‑of‑Stake protocol that adds a multi‑agent reinforcement learning layer for dynamic reputation maintenance, voting-based leader selection, and reward/penalty updates (Islam et al., 2023). The core design models each validator as an RL agent that maintains a reputation table about peers, uses a learned voting policy to select a lead validator, and receives rewards or penalties depending on whether it voted in line with the final correct consensus and whether it correctly identified malicious actors. The stated goals are fairer validator selection, dynamic detection and elimination of malicious nodes, and adaptability to new behaviors through continual learning.

The protocol’s reputation model is five-dimensional. For an agent $i$, the reputation vector is described by accuracy, transaction holding tendency, processing delay, super processing power, and ability to detect illegitimate transactions. In notation,

$$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$

Each agent maintains such information for all peers. The action space is centered on voting for candidate validators and on adjusting internal constants in the voting rule. The paper’s Voting() pseudocode assigns a baseline vote $a+b+c+d+e$ to a new agent and otherwise computes vote values from the five reputation metrics and tunable constants $a,b,c,d,e$. The pseudocode itself repeatedly multiplies metrics by $a$, while the surrounding explanation treats $a,b,c,d,e$ as the constants governing the voting function.

The penalty–reward rule is explicit and scalar. Let $C$ denote whether the agent supported the correct consensus and $D$ whether it detected the bad actor. Then

$$r(C,D)= \begin{cases} +5, & C=1, D=1,\ +2, & C=1, D=0,\ -1, & C=0, D=1,\ -4, & C=0, D=0. \end{cases}$$

This mechanism strongly incentivizes simultaneously reaching the right consensus and detecting malicious behavior. The paper abstracts the precise internal update rule through UpdateRepTab(R_a, reputation), which updates the agent’s reputation table and, conceptually, the internal learning parameters that affect later voting.

The protocol workflow is iterative. A new agent joins with baseline treatment in the voting function; agents maintain reputational observations; each round they compute votes over candidates; aggregated reputational voting selects a lead validator; the leader proposes a block; other agents validate correctness and watch for behaviors such as withholding, delay, or faulty processing; consensus determines the correct block outcome; and each agent’s reward or penalty updates its local learning state. Over repeated rounds, honest and accurate agents accumulate higher reputation, while malicious or unreliable agents become less likely to be selected as leaders.

The threat model is practical rather than formal. Four main experimental cases are identified: transaction holding, artificial processing delay, excessive computing power or unfair advantage, and transaction processing errors. The design also implicitly targets fraud detection and censorship or misbehavior detection through the “ability to detect illegitimate transactions” metric. However, the work does not provide a formal cryptographic adversary model, stake threshold analysis, or Byzantine fault-tolerance theorem. It is presented as conceptual and experimental work rather than a fully proved security construction.

3. MRL‑PoS+ and the formalization of attack-aware reputation

MRL‑PoS+ extends the same general idea into a more explicit attack-aware PoS consensus design. It treats each validator as a semi‑automated agent and augments consensus with a reputation table containing four key parameters: attackProbability, lastAttackAge, restrictions, and isActive (Bappy et al., 2024). The protocol explicitly targets six major attack classes—51% attack, double-spending, Sybil attack, replay attack, smart contract exploitation, and DDoS / BDoS-like attacks—mapped to sixteen observable behaviors $b_1,\dots,b_{16}$.

Although the paper is conceptually based on multi-agent Q-learning, it does not implement a full centralized RL learner. The generic update equation used as conceptual basis is

$$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$0

In practice, the implemented mechanism uses the reputation table and penalty–reward dynamics as an implicit learned value function. A simplified node state is described as

$$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$1

This state is updated by an Activity Tracker that monitors block proposal, transaction validation, and message relay behavior.

Validator selection combines stake with reputation. For each candidate node $$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$2, the protocol retrieves $$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$3 and $$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$4. Nodes are filtered out if

$$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$5

Otherwise the node receives an agent score

$$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$6

The algorithm then sorts candidate nodes by score and includes a special tie-handling rule in which, if multiple nodes have the highest stake, one is chosen randomly among them. Reputation recovery is built in: if $$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$7, it is decremented each round without new misbehavior, reducing the effect of older attacks.

The penalty–reward mechanism is coupled to economic incentives. Honest behavior yields transaction fees, a decrease in attackProbability, and possible removal of restrictions. Malicious behavior yields stake loss, an increase in attackProbability, additional restrictions, and potentially setting isActive to false. Persistent malicious nodes are therefore gradually excluded from future validator selection, whereas nodes that cease misbehavior can partially recover.

Unlike the earlier MRL‑PoS paper, MRL‑PoS+ reports concrete proof-of-concept results. In simulations with 40 malicious and 60 honest nodes per attack type over 100 rounds, the number of malicious nodes selected as validators decreases steadily as rounds progress. Compared to traditional PoS and DPoS, and using 50 malicious nodes as the comparison point, the paper reports that MRL‑PoS+ eliminates malicious nodes significantly faster. The implementation is described as Go (Ethereum-like) and deployed on Azure VMs; reported memory usage is approximately 9.7 GB for the PoS baseline and 9.81 GB for MRL‑PoS+, and the paper states that the scheme does not incur additional computation overhead in practice.

4. Related voting-power theory for stake-based systems

A distinct but mathematically relevant line of work for MRPoS-style PoS design is the theory of polynomial voting rules (Tang et al., 2022). This work does not define an MRPoS protocol, but it proposes a class of stake-based voting rules for decentralized decision and consensus systems, including PoS, in which a bidder’s voting power is differentiated from its stake share. The central rule $$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$8 defines the reward probability

$$R_i = \bigl(R_i^{\text{acc}}, R_i^{\text{hold}}, R_i^{\text{delay}}, R_i^{\text{power}}, R_i^{\text{detect}}\bigr).$$9

Here $a+b+c+d+e$0 is validator $a+b+c+d+e$1’s stake, $a+b+c+d+e$2 is total stake, and $a+b+c+d+e$3 is stake share.

Two asymptotic properties are especially relevant. First, the shares $a+b+c+d+e$4 form a martingale and converge almost surely to a Dirichlet-distributed limit: $a+b+c+d+e$5 Second, the voting powers $a+b+c+d+e$6 form a super-martingale and, for $a+b+c+d+e$7, decay to zero over time: $a+b+c+d+e$8 The total stake process satisfies

$a+b+c+d+e$9

The paper interprets this as a way to preserve fairness in stake shares while dampening absolute voting power as the system grows.

The theory also identifies a phase transition in share stability. Large bidders with $a,b,c,d,e$0 retain shares close to their initial proportion with high probability, whereas small bidders with $a,b,c,d,e$1 exhibit persistent volatility in relative share. A further extension studies stake trading and classifies bidder utility behavior into super-martingale, sub-martingale, and martingale regimes according to the sign of $a,b,c,d,e$2. In the super-martingale regime, non-participation is optimal; in the sub-martingale regime, buy-out becomes optimal; and in the martingale regime, the bidder is indifferent across feasible strategies. For blockchain MRPoS research, these results provide a formal vocabulary for discussing stake, selection probability, issuance throttling, and concentration dynamics, even though the polynomial-voting framework is not itself an MRL‑PoS protocol.

5. MRPoS as a mixed-reality navigation interface

In robotics, MRPoS names a completely different system: the Mixed Reality‑Based Robot Navigation Interface using Spatial Pointing and Speech (Iglesius et al., 4 Mar 2026). Its purpose is to let a user specify robot navigation goals by pointing in 3D space to choose positions and speaking natural language commands interpreted via an LLM to choose orientations and actions, while visualizing goals as virtual MR‑beacons in the real world. The design is motivated by limitations of 2D displays, gesture-only MR interfaces that rely on “air tap” interaction, and language-only interfaces that are natural but weak in spatial grounding and intent transparency.

The architecture has four modules: HoloLens 2, ROS 2 middleware, a Model Server, and a robot platform. HoloLens 2 provides the hand menu, ray-based pointer, MR‑beacons, and MR‑labels; ROS 2 bridges MR and robot state; the model server, hosted with FastAPI, provides faster‑whisper (small.en) for STT and meta‑llama/Llama‑3.1‑8B‑Instruct for landmark extraction; and the robot platform is a Kachaka mobile robot using a ROS 2 navigation stack. Coordinate alignment is performed with Vuforia and a reference QR code, yielding the transform

$a,b,c,d,e$3

The interface supports four operations on MR‑beacons: Add, Edit, Go, and Delete. During an inference action such as Add, a Voice Activity Detector segments speech while the pointer’s floor intersection points are sampled every 0.1 s. The pointer stream is clustered by a sequential algorithm with Euclidean threshold

$a,b,c,d,e$4

producing temporally contiguous clusters whose centroids become candidate goal locations. The speech stream is processed as audio $a,b,c,d,e$5 STT $a,b,c,d,e$6 transcript $a,b,c,d,e$7 LLM $a,b,c,d,e$8 JSON list of MR‑label names. The LLM is not used for motion planning; it functions as a constrained semantic parser and error-corrector for landmark extraction.

Pose calculation fuses ordered label names with ordered pointer clusters. For the $a,b,c,d,e$9-th beacon, the position is the cluster centroid $a$0, the reference landmark position is $a$1, and the orientation yaw is

$a$2

The result is a full pose $a$3, which is stored as an MR‑beacon and can be sent through ROS‑TCP to the robot’s navigation stack. The system emphasizes reduced reliance on repeated mid-air gestures, visible semantic anchors via MR‑labels, and pre-execution intent transparency through in-situ visualization.

The evaluation compares MRPoS with the gesture-based MR baseline MRNaB using 16 participants, mostly without prior ROS or VR/AR/MR experience, in an indoor environment with objects such as a tissue box, chair, water bottle, coffee machine, flower pot, and TV.

Metric	Stage 1	Stage 2
Task time, MRNaB vs MRPoS	17.21 s vs 5.37 s	42.92 s vs 17.88 s
Add+Edit actions, MRNaB vs MRPoS	1.38 vs 1.12	3.44 vs 1.69
Location error, MRNaB vs MRPoS	0.084 m vs 0.080 m	0.049 m vs 0.059 m
Rotation error, MRNaB vs MRPoS	$a$4 vs $a$5	$a$6 vs $a$7

The time differences are statistically significant in both stages: $a$8 for Stage 1 and $a$9 for Stage 2. Action count differs significantly in Stage 2 with $a,b,c,d,e$0. Accuracy is broadly comparable, with a significant difference only in rotation error for Stage 2 at $a,b,c,d,e$1, where MRPoS is slightly worse. Subjective evaluation reports SUS scores of 70.16 for MRNaB and 76.72 for MRPoS with $a,b,c,d,e$2 and effect size $a,b,c,d,e$3, and NASA‑TLX scores of 35.27 and 21.67 respectively with $a,b,c,d,e$4 and $a,b,c,d,e$5. The latency breakdown shows model overhead of roughly 1–2 seconds: for Stage 1, speaking time 4.20 s, STT 0.35 s, LLM 0.81 s, clustering 0.01 s, overall 5.37 s; for Stage 2, speaking time 15.72 s, STT 0.75 s, LLM 1.39 s, clustering 0.02 s, overall 17.88 s.

A key technical clarification is that MRPoS is an interface layer, not a new navigation planner. The underlying navigation remains standard ROS 2 localization, mapping, and planning; MRPoS focuses on multimodal goal specification and visualization.

6. Limitations, misconceptions, and broader significance

The literature does not support treating MRPoS as a single unified technical artifact. In blockchain, the acronym points to adaptive, reputation-aware PoS consensus; in robotics, it denotes an MR–LLM interface for robot goal specification. This domain dependence is the first interpretive constraint.

Within blockchain usage, both MRL‑PoS and MRL‑PoS+ remain limited by incomplete formalization. MRL‑PoS is explicitly a design + prototype implementation without explicit theorems, bounds, or proofs, and without numeric experimental results such as throughput, latency, fork rate, or attack success rate (Islam et al., 2023). Its RL mechanism is intentionally simple, with a Q‑table or learning table and heuristic constants $a,b,c,d,e$6, but without specification of learning rate, discount factor, exploration strategy, or convergence analysis. The paper also leaves open observability, non-stationarity, scalability of maintaining reputation tables for all peers, adversarial manipulation of reward signals, and the precise integration of reputation with stake.

MRL‑PoS+ advances the design with explicit attack indicators, attack probability, and proof-of-concept evaluation, but it still lacks a formal security proof and does not fully specify the aggregation from behaviors $a,b,c,d,e$7 to attackProbability or the exact penalty map (Bappy et al., 2024). The paper notes common blind spots of reputation-based mechanisms: sophisticated adversaries may attempt to stay below thresholds, attack intermittently, or exploit unmodeled behaviors.

In the robotics usage, MRPoS trades lower workload and faster goal creation for a modest orientation-accuracy penalty in some cases. The authors attribute this to the fact that orientation is computed from two MR positions—beacon and label—so label-placement error propagates into the final pose. The system also depends on robust STT, correct MR‑label naming, HoloLens tracking quality, and QR-based co-localization with line-of-sight constraints (Iglesius et al., 4 Mar 2026). The experiments are conducted in relatively simple indoor scenarios, so extension to more cluttered or safety-critical environments remains open.

Taken together, these usages give MRPoS an unusual encyclopedic profile. In one lineage it denotes an attempt to make PoS consensus stake- and behavior-aware through multi-agent reinforcement learning and adaptive reputation. In the other, it denotes a multimodal MR interface that combines spatial grounding with LLM-mediated semantic parsing for robot navigation. The shared acronym therefore signifies not a common mechanism, but a coincidence of naming across two technically sophisticated, but otherwise independent, research programs.