EDIT: Edited the Headline We ain't no Politicians to Separating Infrastructure and policy

Background

We are all aware and have discussed this issue a lot of times, with no satisfying solution. The protocol represents a first come first serve approach when it comes to agent's filling requests. The real world data approve. All agents try to fill as fast as possible, where one (the fastest) wins and the others have the cost of a failing transaction. Currently, with a limited set of agents, we are quite balanced, but this approach as several drawbacks. Unfortunately, we need to make tradeoffs when it comes to the policy of who is able to fill the request.

tradeoffs

Let's start with the advantages of the current model. Beamer gets what we aim for. Being the fastest bridge. With the race between the agents, we incentivize being the fastest agent. And I think there is no other model which incentivizes more the speed. Drawbacks: This speed however, comes at a high cost. This kind of "free market" approach most likely results in where neo liberal approaches end. A highly centralized set of agents. 3 to 4 agents will share the cake and rule everyone else out.

On the other hand, we could introduce some sort of fair distribution restricting the protocol, so that every agents kindly queues in and takes the request at its turn. This vastly reduces the cost, as agents wont have any failing transactions, and it would probably result in a bigger variety of agents, on the other hand we lose the incentive for filling as fast as possible. For the agent at turn, there is no need to fill very fast, and even worse, if the agent is down, then no other agent can fill.

Of course, the third option is to build arbitrarily complex models to have a hybrid version where we find good tradeoffs. But Im convinced that these two forces, cheap cost against fast execution, are pulling at two ends of a rope, and we can definitely find compromises somewhere inbetween.

As a nice analogy I like to think about the differences of PoW and PoS. In PoW everybody starts to try finding a block, wasting lots of energy, but only the fastest wins. We most likely have constant or fast block times with this approach, but we also have lots of energy wasted for just one block. With PoS everybody know when it is his turn. Every validator is kindly waiting until he is supposed to propose a block. Energy consumption is saved by 99%, but on the other side, if a validator misses its turn we wait for sure 2 block times. Of course this is oversimplified and we are not a blockchain so we have different properties, we want to achieve. But I hope you get the analogy. In our case failing transactions is the wasted energy.

Separating Infrastructure and policy

I constantly struggled to find a decision on where the protocol should head. The current way of "free market" approach was decided on out of simplicity with the fine print we will fix it later. IOW it was an implicit decision based on simplicity. I think we are at a point where we will soon have to think about how to fix it. And from a protocol point of view, I think we should not be the ones making the policy for all users. We should not decide whether users want to pay a higher price and get it done quickly (i.e. MEV searchers) or be happy to wait a bit but get it done cheaper. However, I think we need to build the protocol in a way that any policy can be build on top.

Protocol Changes to facilitate any policy

I realized that we only need slight changes to the protocol in order to facilitate different policies of agents discovery. I see the protocol as a bare metal infrastructure, which allows for a secure way for users and market makers to meet and exchange service. Policies can be built on top. In order to allow both extremes a user needs to be able

to set an address which should be the filler of the request. All other claimers will automatically be invalid.
It may make sense to block this request for a certain amount of time, after which any other agent can be a claimer. (For this we would also need to forward the timestamp upon L1 resolution. Before only the given address is a valid claimer, afterwards anybody)

These are all changes to the protocol for now.

Use Cases

Let's have a look at potential use cases 1) Status quo: If the address is not set (0x0) then anybody can fill as it is today. 2) Proxy agent assignment: Users will send their requests to a proxy contract. In this proxy contract there is a whitelisted set of agents which will get assigned to incoming requests. Within the very transaction a request with the assigned agent gets forwarded to the RequestManager. To me this is a business model of its own. Agents can pay some entity to be whitelisted, will have much lower cost because of they don't have failing transactions. The entity manages the list regarding reliability or liveness of the agents. 3) Protocol owned agents: Some protocols may want to use beamer as their underlying infrastructure protocol to facilitate bridging between chains. But they want to run their own agent to facilitate the bridging. They can assign their agent to all of their users' requests.

In all of these cases, the beamer protocol brings the security mechanism for securing users and agents. It's the protocol to ensure that no money is lost. And it still will be permissonless for challenging. However, how the market is made and how users and agents are assigned, can be done by different entities or projects in the ecosystem.

4) Run the Frontend with a whitelisted set of agents: We could be the first example. For our frontend we could introduce a round robin whitelist of agents, but the protocol itself is free to use for anybody. Even further, our agents would fill any request which comes in for "the open market". We would create a proxy contract which has a whitelisted set of agents. We could implement any kind of algorithm to fairly order the agents' turns. Users of our frontend would make their requests through our proxy.

Competition for users and agents

Different entities, setting up proxies could compete for users and agents. Agents could participate in multiple entities. And there is the open and closed market. Agents can participate in the open market at all times.

Fee implications

Now of course this is tightly coupled to the fee model. Currently we only have a protocol wide fee, which is derived from the current free market model. IOW, the minLpFee takes into account that an agent will have on average n-1 failed fill transactions until succeeding the race for a fill. We obviously need to change the fee structure, which is an open question currently, that accounts for different policies of agent assignment. Regardless, the current fee structure was also always meant to be a short cut until we have a proper fee model. The one fee for all is not very efficient.

How to move forward

For now, this is just food for thought and my opinion how we can solve this dilemma on our plate separating it from the protocol. I would also love to design it in a way where we can iteratively incorporate such changes to the protocol. I'm sure elaborating on it together will bring a great solution.

Additional information

https://app.fireflies.ai/view/Think-tank::7pfYgjxUl4

I will try to comment on this piecewise, as I go.

We ain't no Politicians

I cannot disagree more with this. Some day I will probably write a blog about it, but for now let me just say that I view what we are doing as highly political work.

Of course we have the right to say "we do not want to decide on the policy, let others do it". However, my point is, that stance in itself is a political one, much more so in our domain than in many others. The way I see it, thinking of us as above politics is quite a fallacy. By choosing not to do something, you are very much making a political choice no matter how much you say "it is none of our business". For a nice analogy to this, consider the Ethereum community's attitude (dare I say, politics?) toward MEV.

Moreover, by explicitly pulling back from making a policy, we do not get automatically excused from considering the consequences of such a decision.

I will try to comment on this piecewise, as I go.

We ain't no Politicians

I cannot disagree more with this. Some day I will probably write a blog about it, but for now let me just say that I view what we are doing as highly political work.

Of course we have the right to say "we do not want to decide on the policy, let others do it". However, my point is, that stance in itself is a political one, much more so in our domain than in many others. The way I see it, thinking of us as above politics is quite a fallacy. By choosing not to do something, you are very much making a political choice no matter how much you say "it is none of our business". For a nice analogy to this, consider the Ethereum community's attitude (dare I say, politics?) toward MEV.

Moreover, by explicitly pulling back from making a policy, we do not get automatically excused from considering the consequences of such a decision.

Reading your comment, I clearly did not express my ideas correctly. Let me try to rephrase it.

You are completely right that we are doing political work. Thus the word politician is misplaced here. Reading my comment further, I'm actually describing very well where we as Beamer do make policies. Namely, in the Proxy contract which is bound to the frontend, we provide.

Let me try to explain my mental model and please note, due to development shortcuts it may not be implemented this way yet:

My thinking is that, whether having a round robin style agent choice over a first come first serve principle (or even something we don't imagine yet) depends on the need of the users. And Beamer may have different types of users in the future. The Beamer protocol is an infrastructure which provides the ability for users to exchange tokens with each other securely. On this level, there is no real policy on how they find each other, under what conditions they exchange.

However, directly on top of this protocol (or contracts which implement the protocol), there is exactly that. Policies on how users and service providers find each other. And for sure, we are making policies. We are providers of a frontend, where I see us responsible for the proper functioning of it. This means, the frontend needs to be up, AND we need agents who are willing to provide the service to the users. We are currently making the policies how users and agents find each other and agents agree or disagree to the terms.

Nevertheless, thinking fast forward into the future, the Beamer protocol is not meant to be "the frontend" + some smart contracts in the backend. We need to split this. The beamer contracts are an infrastructure protocol for the whole world to bridge tokens securely. In my eyes, the contracts are more a technology to use instead of a specific app. The Beamer dApp is built on top. This is where all the policy should happen IMO.

And additionally, there could be multiple apps on top of the same policy.

app
--------------
policy
--------------
infrastructure

By separating it in this way, policy makers could create their own policy, which lives next to our policy. I.e. If an app wants to create a market for agents competing with each other, they can do it, if we as the Beamer team want to have a different approach for our services, we can do so. It is an open protocol to build on.

After having read the text in its entirety, I think it is an appealing idea. I expect there to be many details to sorted out, though.

One thing that comes to my mind is the question of feasibility of implementing certain fee policies in such a split approach, where we have the proxy contract and the core Beamer contracts. To give an example, suppose I want to build on top of Beamer and provide my own frontend and proxy contract. Additionally, suppose the proxy contract maintains a set of agents eligible to fill and any time there is a request, the proxy contract chooses one filler and provider that information to Beamer's request manager. Suppose now that for some reason the fill fails and now the proxy wants to penalize the agent that was chosen as the filler. How would the proxy contract get that information? Suppose I do not want to remove the agent from the agent set, but I want to apply a financial penalty. How would I go about that?

After having read the text in its entirety, I think it is an appealing idea. I expect there to be many details to sorted out, though.

One thing that comes to my mind is the question of feasibility of implementing certain fee policies in such a split approach, where we have the proxy contract and the core Beamer contracts. To give an example, suppose I want to build on top of Beamer and provide my own frontend and proxy contract. Additionally, suppose the proxy contract maintains a set of agents eligible to fill and any time there is a request, the proxy contract chooses one filler and provider that information to Beamer's request manager. Suppose now that for some reason the fill fails and now the proxy wants to penalize the agent that was chosen as the filler. How would the proxy contract get that information? Suppose I do not want to remove the agent from the agent set, but I want to apply a financial penalty. How would I go about that?

Interesting question. I think the main question is when can the outcome of a request (filled/not filled) be seen as final. From the request managers code, ultimate finality happens when a participant withdraws the token. IOW, once the user withdraws an expired request, the proxy contract can read this state (or there could be a callback to the proxy) which triggers financial penalties.

I aggree however that there are quite some things which need to be sorted out, or which will improve over time depending on user demand.

Nevertheless, thinking fast forward into the future, the Beamer protocol is not meant to be "the frontend" + some smart contracts in the backend. We need to split this. The beamer contracts are an infrastructure protocol for the whole world to bridge tokens securely. In my eyes, the contracts are more a technology to use instead of a specific app. The Beamer dApp is built on top. This is where all the policy should happen IMO.

And additionally, there could be multiple apps on top of the same policy.
app
--------------
policy
--------------
infrastructure
By separating it in this way, policy makers could create their own policy, which lives next to our policy. I.e. If an app wants to create a market for agents competing with each other, they can do it, if we as the Beamer team want to have a different approach for our services, we can do so. It is an open protocol to build on.

Yeah, I see, we're talking about Beamer both as a protocol, but also as a protocol framework, that one could use to implement other protocols (in a somewhat wider sense). In general, I find that quite nice and elegant, and from a technical level also, it definitely has some advantages.

I just wanted to make the point that each choice we make here is a political one, in certain ways. But I also agree that we can do both: turn Beamer into a protocol infrastructure and provide our own implementation on top of it, as we see fit (basically what we have now with v1, the current frontend and agents).

Thanks for expanding!

I just wanted to make the point that each choice we make here is a political one, in certain ways

totally agree. It was bad wording.

Interesting question. I think the main question is when can the outcome of a request (filled/not filled) be seen as final. From the request managers code, ultimate finality happens when a participant withdraws the token.

Right, but this is somewhat limiting because it then basically prevents ideas that could be built on top of "accumulated funds" in the contracts. I think we mentioned this a couple of times, and also there's the idea of partial/fractional fills...

I'm not sure what the best finality criteria would be, but I think we should choose it carefully in order to keep the doors open for future features.

I'm not sure whether I can follow this thought, but we should maybe postpone this discussion as it seems to be one of the details. However, a proxy can choose on its own what criteria it chooses for finality. It can also choose how agents should be penalized or even if.

beamer-bridge / beamer

The Agent's inefficiency dilemma #1501