[SPIKE][Document] Utility (M3) Specification - AATs

[jessicadaugherty]

Objective

Define and update specifications of M3 - MVP (initial launch) of AAT Pocket-specific utility.

This includes, but is not necessarily limited to:

• Do we need a new protocol actor?
  • If so, what is the name of the protocol actor?
  • If so, is it optional or not?
  • If it is optional, how are optional protocol actors managed w.r.t to other actors?
• Does the protocol actor manage AATs?
  • If so, how does the protocol actor manage AATs?
• Does the protocol manage correctness of RPC data?
  • If so, how does it do it?
  • If not, what are the alternatives or next steps?
• Which flows in the utility spec will the AAT specification impact?
• Which actors in the utility spec will the AAT specification touch?
  • Applications (with and without Gateway Actor)
  • Sessions
  • ServiceNodes
  • Fisherman
• What economic models need to be taken into consideration with respect to the AAT spec changes?

The goal is to update the V1 roadmap, timelines, documentation, etc. accordingly.

Origin Document

AATs are referenced but non-defined in: Utility Specification

Goals

• Create an AAT specification in pocket-network-protocol which will inform updates and changes to other M3 Protocols

Deliverable

• [ ] Updated spec doc
  • [ ] Note which other specs are impacted by these additions and document any outstanding questions
• [ ] New mermaid diagrams, where applicable, to improve readability and understanding
• [ ] Updated milestones, if applicable

Non-goals / Non-deliverables

• Documenting or Implementing AAT or any other M3 Protocols

General issue deliverables

• [ ] Update the appropriate CHANGELOG
• [ ] Update any relevant READMEs (local and/or global)
• [ ] Update any relevant global documentation & references
• [ ] If applicable, update the source code tree explanation
• [ ] If applicable, add or update a state, sequence or flowchart diagram using mermaid

---

Creator: @jessicadaugherty

[Olshansk]

Wanted to provide a quick update. I've increased the of this PR to also clarify other parts of the spec so it is easier to read & understand.

The WIP PR is available here: https://github.com/pokt-network/pocket-network-protocol/pull/25

The formatted markdown can be viewed here: https://github.com/pokt-network/pocket-network-protocol/blob/issues/23/aat/utility/README.md

It is not yet ready for review but I'll follow up once it is.

[Olshansk]

@jessicadaugherty Could you take a preliminary look at 3.5 Gateway Protocol and let me know if it you'd be interested in more details.

In isolation, it doesn't cover all the questions outlined in the issue but I do believe it does provide a good amount of context.

[jessicadaugherty]

Thanks @Olshansk I've read it through a few times and overall it makes sense. Some questions/comments:

1. Registration: How does a gateway actor register based off of their stake? Like does any other additional information need to be provided? What stake amount then returns a gateway ID/key? Any met minimum of StakePerAppDelegation?

2. It may be heavy-handed to explicitly say “Note that an Applications that requires just-in-time guarantees and full integrity of the data…”. I would focus more on the value prop outlined below in 3.5.4: “As shown in the section above, delegation enables free market off-chain economics where additional features, guarantees or payments can be made.”

3. “For example, this includes but is not limited to a contractual agreement between Applications and Gateways to execute Client Side Validation with every Nth request.” - If CSCs are an on-chain mechanism, why are they highlighted here as an off-chain benefit? Should it be noted that CSCs are an alternative for non-gateway actors to enforce correctness without building a gateway UI or any additional bells and whistles?

4. “An Application that chooses to delegate trust to a Gateway will need to submit a one-time DelegateMsg transaction to delegate trust from the Application to the Gateway.” - is this assumed done by default if gateway access is granted via a UI? Otherwise through a CLI an app could delegate to a specific gateway without ever touching the gateway? Or is that a per gateway design decision?

5. “4.2 Castaway: PNI will need to operate the first live Gateway” - how are we preventing others from operating gateways if it is an optional permissionless actor?

6. Can you un-delegate and delegate to a different gateway if this is a 1x command? Does delegation require App Stake? (Don't want situations where I delegate 10 apps but never actually send relays, right?)

7. The gateway actor does not return an access token by default, as that is an off-chain mechanism, so it must be built separately by the gateway operator?

I'll add any more questions as/if they come up!

[Olshansk]

1. Registration: How does a gateway actor register based off of their stake? Like does any other additional information need to be provided? What stake amount then returns a gateway ID/key? Any met minimum of StakePerAppDelegation?

Does section 3.5.5 answer your question or should I add more details?

---

2. It may be heavy-handed to explicitly say “Note that an Applications that requires just-in-time guarantees and full integrity of the data…”. I would focus more on the value prop outlined below in 3.5.4: “As shown in the section above, delegation enables free market off-chain economics where additional features, guarantees or payments can be made.”

2. Noted. Will update.

---

3. “For example, this includes but is not limited to a contractual agreement between Applications and Gateways to execute Client Side Validation with every Nth request.” - If CSCs are an on-chain mechanism, why are they highlighted here as an off-chain benefit? Should it be noted that CSCs are an alternative for non-gateway actors to enforce correctness without building a gateway UI or any additional bells and whistles?

Things of everyday laws as an analogy:

Stealing is written and enforced (i.e. on-chain) as illegal when you go to court per United States Statutes at Large. However, you trust the police (i.e. off-chain, the gateway) to enforce it.

There is a whole slew of cool ideas we can have for on-chain penalties & incentives w.r.t to gateways (e.g. using tokenomics to enforce submitting a CSC from a gateway every N requests), but I'm keeping it simple for now.

---

4. “An Application that chooses to delegate trust to a Gateway will need to submit a one-time DelegateMsg transaction to delegate trust from the Application to the Gateway.” - is this assumed done by default if gateway access is granted via a UI? Otherwise through a CLI an app could delegate to a specific gateway without ever touching the gateway? Or is that a per gateway design decision?

It is a per-gateway decision decision.

---

5. “4.2 Castaway: PNI will need to operate the first live Gateway” - how are we preventing others from operating gateways if it is an optional permissionless actor?

The goal here was not to prevent others but to guarantee there is at least one in the genesis file: i.e. PNI

---

6. Can you un-delegate and delegate to a different gateway if this is a 1x command?

Yes, you can un-delegate. We can potentially build it to enable multi-gateway delegation but I am limiting to 1 for the initial spec to keep it simpler (e.g. more questions around rate limit distribution).

Does delegation require App Stake? (Don't want situations where I delegate 10 apps but never actually send relays, right?)

Yes it does.

---

7. The gateway actor does not return an access token by default, as that is an off-chain mechanism, so it must be built separately by the gateway operator?

Yes, it's just an example. It is up to the gateway to decide to monitor/manage sessions with the application. They can use the on-chain mechanism to see that the app delegated to it.

[jessicadaugherty]

Does section 3.5.5 answer your question or should I add more details?

@Olshansk I think the level of detail is good, I was just wondering for my own understanding of how that stake is tied to a public key. Like for a node stake command it's pocket node stake <operatorAddress> <serviceURI>, etc. so was curious if we identify the gateway by more than just the stake amount and a returned public key.

But yes meeting the minimum StakePerAppDelegation = 1 application can delegate to this actor makes sense.

Thanks for the quick replies!

[Olshansk]

. so was curious if we identify the gateway by more than just the stake amount and a returned public key.

tl;dr Will also include serviceURI

Longer answer:

message Actor {
  ActorType actor_type = 1; // GATEWAY
  string address = 2; // Gateway address
  string public_key = 3; // Gateway key
  string staked_amount = 4; // staked amount
  string serviceURI = 5; // Where the gateway provides its services
}

@Olshansk I think the level of detail is good, I was just wondering for my own understanding of how that stake is tied to a public key. Like for a node stake command it's pocket node stake , etc

tl;dr It's part of the stake command and is verified via the signature

In the [iteration 3 demo[(https://github.com/pokt-network/pocket/blob/main/docs/demos/iteration_3_end_to_end_tx.md), the commands are: go run app/client/*.go --path_to_private_key_file=/tmp/val1.json Account Send ...

1. Whoever runs the stake command must have access to the privKey
2. Locally (whoever owns the privKey) signs the message before sending it to the network (i.e. the mempool)
3. When the messages is validated and included in the block, the following happens: 3.1 Get pubKey from message 3.2 Verify that signature corresponds to pubKey 3.3 Include transaction in the block
4. App can use the gateway on the subsequent block

But yes meeting the minimum StakePerAppDelegation = 1 application can delegate to this actor makes sense.

👍

Nothing, from an offline convo, that this "gateway deposit/rent" is really just the "bare minimum" I plan on adding in this iteration of the spec. There's a ton of opportunity to create additional; penalties and incentives for the gateway (discussed in #14), for on-chain gateways. TBD if some of them can be implemented pre-v1-launch, but it could very well be the case.

[jessicadaugherty]

> message Actor {
>   ActorType actor_type = 1; // GATEWAY
>   string address = 2; // Gateway address
>   string public_key = 3; // Gateway key
>   string staked_amount = 4; // staked amount
>   string serviceURI = 5; // Where the gateway provides its services
> }

chefs kiss

When the messages is validated and included in the block, the following happens: 3.1 Get pubKey from message 3.2 Verify that signature corresponds to pubKey 3.3 Include transaction in the block

Cool, makes sense!

App can use the gateway on the subsequent block

As long as they are staked for service. Not sure if that should be addressed in the Application Protocol but I think it's worth at least a line or even a "gateway activation" section post-registration to outline if the gateway determines a minimum ante for the apps to claim a spot from their StakePerAppDelegation to tie it all together.

[msa6867]

Hello, I am reviewing this thread as a redirect from "ADR-002 Tokenized Gateways" As I tend to be involved more at the governance level than within Github, there are several acronyms here that are new to me without much documentation to help decipher: SPIKE, M3, AAT, MVP. Please forgive my ignorance. In any case, let me copy/past my comment I left on Tokenized Gateway proposal and see where that leads us.

"_What is the status of this proposal?

My apologies for being 6 months late to the game, but I was just recently made aware of this proposal. I strongly oppose the idea of tokenized gateways. tl;dr it is a bad architecture choice, confuses the demand side and the supply side of the protocol and could jeopardize the censorship-resistance of the protocol. I will add more detail in a Forum post and paste link here when ready. If work has not begun, it should not go forward. If the code change has already been accomplished, it should be scrubbed and code reverted to previous version without this token pathway (I can create a new proposal to initiate the rollback if need be.)_"

It seems like a tremendous amount of work has gone into this already. I'm not saying it is wasted effort. Much if not most of it may prove useful for helping potential gateway providers with best-practice in interacting with their clients, etc.... but this should be kept completely separate from the supply-side of the protocol, as is the case with the PNI portal today. Carving a piece of the emission pie for gateway actors causes them to be supply-side actors instead of the demand-side actors that they naturally are, with potentially negative consequences including loss of censorship resistance at the protocol level.

At the end of the day Gateway builders ought to be able to ignore everything here specified and be free to develop their own specification. The protocol would be unable to distinguish between them and any other DAPP self-staker. That the demand they present to the network happens to represent an aggregation of demand from a set of subclients would be undiscoverable to the network.

[jessicadaugherty]

Hey @msa6867! Thanks for chiming in on the specification in regards to "ADR-002 Tokenized Gateways".

SPIKE, M3, AAT, MVP

"spike" = research spike; non-coded ticket and capitalized for EMPHASIS. Similar to CHORE (no business benefit work) and TECHDEBT to differentiate at a glance between core feature work and research/maintenance. M3 = Milestone 3 = RoS = RelayOrSlash = the Utility Module AAT = Application Authentication Token MVP = Minimum Viable Product (or, Pocket)

What is the status of this proposal?

Elements of "ADR-002 Tokenized Gateways" are included in this updated specification, specifically the permissionless Portal Actor. There are no incentivization mechanisms for Portal Actors included in this specification but instead details about the ability of an application to delegate AATs to Portal Actors and for Portal Actors to stake $POKT in exchange for app stake slots (e.g. 1 app stake slot = 100 $POKT. 1000 $POKT Portal Actor stake = 10 app slots).

Rewarding gateways that will be responsible for their own monetization strategies is not a goal for V1 launch and will require more sustainable economies of scale. I'd probably prefer to see the reverse: portals paying a percentage revenue share/service fee to the DAO to increase the DAOs income from and for federated portals who participate in governance and build public goods. Portals should be self-sustaining and can use variable USDRelayTargetRange or value-added services to seek margin against compute served for application stakes.

This specification has been merged and is the current guideline for all Utility Module interface design and implementation in V1. No code has been completed.

I strongly oppose the idea of tokenized gateways. tl;dr it is a bad architecture choice, confuses the demand side and the supply side of the protocol and could jeopardize the censorship-resistance of the protocol.

Can you expand on your concerns re: censorship resistance? I had not thought of that and would like to know more.

This specification will be updated as we design the interfaces in the upcoming months. Keep an eye out for the Application and Portal Protocol so we can continue to collaborate on these economies. Thank you!

[msa6867]

Thank you @jessicadaugherty for your prompt reply and providing acronym definitions.

My first concern is creating a very clean firewall between demand-side actors and supply-side actors. Anything that comingles or creates confusion and/or duality as to which side of the protocol an actor sits is problematic. Gateways are demand-side actors. It is good to know that no protocol-level compensation to Gateways is planned as this would blur the demand/supply "firewall." It looks like my statement "I strongly oppose the idea of tokenized gateways" may have been misguided as I thought the word "token" was in reference to the $POKT token as opposed to an authentication token. But confusion remains in terms of your response, "Portal Actors to stake $POKT in exchange for app stake slots (e.g. 1 app stake slot = 100 $POKT. 1000 $POKT Portal Actor stake = 10 app slots)." as this does now reference the usage of $POKT in a manner different than that of dAPPs themselves. I do not understand the architecture well enough yet, but can you please confirm there is nothing in this specification that could cause the Gateway to have the appearance of a supply-side actor.

My second concern remains even if the first is resolved, which is creating a demand-side "Gateway" actor which is distinguishable (at the protocol level) from dAPP actors. Before I elaborate, could you please answer a very fundamental question. Are dAPPs required to go through a gateway/portal in order to submit a RPC request to the Pocket network and receive a response from a Servicer? My understanding was that in v1 dAPPs can self-stake and receive service without needing to connect via a gateway/portal. A lot hinges on the answer to this question.

[jessicadaugherty]

confusion remains in terms of your response, "Portal Actors to stake $POKT in exchange for app stake slots (e.g. 1 app stake slot = 100 $POKT. 1000 $POKT Portal Actor stake = 10 app slots)." as this does now reference the usage of $POKT in a manner different than that of dAPPs themselves. I do not understand the architecture well enough yet, but can you please confirm there is nothing in this specification that could cause the Gateway to have the appearance of a supply-side actor.

Correct, the Portal Actor does buy and stake $POKT as a form of escrow for "renting" application slots. These are separate from an application stake which is used to ensure a certain amount of availability.

The same logic that applies to node staking applies here: this locked value incentivizes Portal Actors to act rationally to avoid instances of self-dealing, DDoS, etc. attacks. However, Portal Actors are not rewarded for their "work" in this iteration of the specification. Portal economies are a TODO noted to explore in utility/ideas.md

could you please answer a very fundamental question. Are dAPPs required to go through a gateway/portal in order to submit a RPC request to the Pocket network and receive a response from a Servicer? My understanding was that in v1 dAPPs can self-stake and receive service without needing to connect via a gateway/portal.

Applications can choose to use a Portal to delegate their AATs to handle dispatching and other services. Applications will be able to stake and transmit relays permissionelssly, assuming the usage of a dispatcher full or light pocket node per the utility specification:

However, even with delegation, an Application would be able to continue operating permissionlessly (via a full or light node) as the two are not mutually exclusive.

[msa6867]

Here is the censorship vulnerability I see. Say the US govt demands service to be denied to some app (say tornado cash) and gets ahold of US based PNF directors and threatens jail if they do not comply. With direct dAPP staking the DAO/PNF has complete cover under impossibility of compliance - the dAPP is permissionless and the network providers number in the tens of thousands spread over 40 countries with no visibility into whose where or whose going to service requests coming from the dAPP. Suppose on the other hand there is only one gateway in the system (as is the case today and is likely to continue for some time) and the censored dAPP goes through this gateway. Suppose further the gateway refuses the government's censorship demand and in turn the govt demands service to be denied to the gateway to punish it for its noncompliance. If, at the protocol level, the gateway is indistinguishable from any other dAPP, the gateway itself is completely permissionless and the impossibility to comply remains intact. But if the gateway actor is a different kind of actor than dAPP actors with knobs that can be turned that result in denying service, then no cover under impossibility of compliance remains and the directors face being forced to comply or face incarceration.

I'm not really familiar yet with the role of the dispatcher. It could be that there is a censorship vulnerability at that point.

The bottom line is that there will always be censorship vulnerabilities in the ecosystem, but the goal must be to drive all such vulnerabilities out of the protocol itself and into the peripheries.

[msa6867]

Is there any rationale for staking $POKT in exchange for "dAPP slots" other than threat of slash? Is dAPP slots a scarce resource that must be managed and rationed? The threat of slashing 100$POKT per dAPP slot hardly creates a disincentive for bad acting. Self-dealing is a non-issue for gateways in contrast to network providers, since gateways pay protocol fees (via AppBurnPerRelay) rather than receive protocol fees. DDoS also should be a non issue due again to having to pay a protocol fee for every RPC request.

More importantly, and to my previous points, why is the protocol trying to get into the business of policing gateways into being rational actors? A Gateway provider's business case depends on being rational actors and should exist completely outside the purview of the protocol. Once Gateways are understood to be demand-side actors and not supply-side actors, the protocol simplifies significantly. It is fine for PNI to spec, build and open-source an instantiation of a gateway, but this should be kept separate from the protocol as is the case today.

[jessicadaugherty]

Suppose on the other hand there is only one gateway in the system (as is the case today and is likely to continue for some time) and the censored dAPP goes through this gateway. Suppose further the gateway refuses the government's censorship demand and in turn the govt demands service to be denied to the gateway to punish it for its noncompliance

Yup, good points! You're correct that any gateway operated in a jurisdiction that had sanctions would likely be subjected to those penalties and would have to determine its level of compliance on a case-by-case basis. Portal actors could also operate independently of any application UI entry point as they are permissionless so it could get grey there.

Is there any rationale for staking $POKT in exchange for "dAPP slots" other than threat of slash? Is dAPP slots a scarce resource that must be managed and rationed?

The threat is not slashing - it's malicious behavior as noted above. Removing the limited accountability of a stake can create a situation where a portal can operate an app, nodes, fisherman, and portal to self-deal or a variety of other nefarious activities. Staking is the lowest level of accountability and I hope to see more as we iterate.

And to answer your last question, limited app slots are a V0 concern but will not be in V1.

The threat of slashing 100$POKT per dAPP slot hardly creates a disincentive for bad acting. Self-dealing is a non-issue for gateways in contrast to network providers, since gateways pay protocol fees (via AppBurnPerRelay) rather than receive protocol fees. DDoS also should be a non issue due again to having to pay a protocol fee for every RPC request.

I'm not fully following this, sorry. There is no slash at the application level here or any slashing for portals included in the specification today. There are also no fees involved. The app burn applies to the application stake, a separate fund from a reserved portal actor app slot that is burned proportional to their consumption. To your point, though, this is one reason I am advocating for portals to pay fees to the DAO/protocol on a per tx basis similar to the model of Stripe. Resources that are consumed should be paid for. Hope that helps and let me know what I'm missing.

I'd also like to add that the "100 POKT" per slot is an example and not the actual parameter value which is currently set to 0 and needs to be evaluated with a model.

why is the protocol trying to get into the business of policing gateways into being rational actors?

Hopefully my comment above answers this. I will add that the protocol's primary responsibility is securing the network for actors and designing sustainable economies against that, not purely enabling the monetization of portals/demand or other actors. It's a different kind of design thinking than in a SaaS business, which is why we have separate functions for demand, supply and protocol.

[msa6867]

Portal actors could also operate independently of any application UI entry point as they are permissionless so it could get grey there.

Sorry for my ignorance... can you explain (or better yet send me a pointer to a write up) the difference between a portal and a gateway if there is one?

The threat is not slashing - it's malicious behavior as noted above.

You misread my comment. In context slashing is not the problem but the enforcement threat against malicious behavior. If the $POKT per slot is not there to be slashed in case of malicious behavior, and it is not there to ration a scarce resource, then it has zero purpose and should be be removed as worthless complexity.

Removing the limited accountability of a stake can create a situation where a portal can operate an app, nodes, fisherman, and portal to self-deal or a variety of other nefarious activities.

Again, I challenge this statement. I've already dispositioned DDoS as a non issue due to app burn. Regarding self dealing, two thoughts: (1) In maturity (when emissions<=app burn) there is no form of self-dealing a gateway could engage in that would be harmful to the system; one might even say that it should be the prerogative of a gateway to self-deal and a potentially useful business model to attract new gateway providers; (2) in the meantime (while emissions > app burn) care must be taken to avoid self-dealing initiating from demand-side actors; however, I see nothing special about gateways in this regard, the same principle applies to dAPPs who self-stake; there is no difference as far as I can tell in that regard. [note that need to prevent supply-side actors from self-dealing always remains, even in maturity]

To your point, though, this is one reason I am advocating for portals to pay fees to the DAO/protocol on a per tx basis similar to the model of Stripe. Resources that are consumed should be paid for.

I do not follow. While I agree that "Resources that are consumed should be paid for" I cannot see any resource that is being consumed by the portal (separate from its dAPP clients), unless you are counting a "slot" as a resource (which I am not convinced is the case seeing that (1) it is not scarce such as needs to be managed (2) it does not incur cost to provide, such as needs imbursing). Again the idea is to not create complexity when it is not needed. I view the portal/gateway as completely passive in this regard, neither receiving funds from the protocol or paying fees to the protocol. The fees collected by the protocol from the clients of the gateway are sufficient payment for protocol usage without charging a separate fee to the portal.

To recap: I am challenging the protocol team to remove gateways as a separate class of protocol actors due to their being an unnecessary protocol complexity and due to their breaking the basic principle of only having permissionless demand-side actors. Else explain why this class of actor is essential to the protocol .

I envision two types of gateways existing: (1) gateway-as-a-service, in which case the protocol does not even know that the gateway exists - for all it knows, all of the dAPP clients of the gateway appear to the protocol to be self-staked, and (2) aggregators, in which case the gateway appears to the protocol to be a dAPP and the protocol has no knowledge of the dAPP clients who sit behind the gateway. In either case, gateway builders are free to copy and paste a PNI-provided open-source instantiation or else ignore this and build their gateway according to their own best practices and market niche

[jessicadaugherty]

Sorry for my ignorance... can you explain (or better yet send me a pointer to a write up) the difference between a portal and a gateway if there is one?

They are synonymous. Sorry for any confusion!

I cannot see any resource that is being consumed by the portal (separate from its dAPP clients)

Bandwidth, storage, and compute.

The fees collected by the protocol from the clients of the gateway are sufficient payment for protocol usage without charging a separate fee to the portal.

Perhaps! These are just ideas. Network fees between intermediaries are pretty standard so I don't think this would create a barrier of entry for portal operators regardless of if they are built for a specific use case or are an aggregator. I'd recommend looking into Lightning Network for a cool example of fees paid to transaction facilitators (channel operators, in their case).

[msa6867]

I'd recommend looking into Lightning Network for a cool example of fees paid to transaction facilitators

Thank you! I will take a look

Bandwidth, storage, and compute.

I think this is another case of reading my question backward from my intention. bandwidth/storage/compute are all resources a gateway provides in service to its clients and therefore its business model must include collecting gateway usage fees from its clients. This is entirely outside the scope or concern of the protocol but rather is a private matter between gateways and their clients.

The protocol obviously does not provide bandwidth/storage or compute to gateways, nor does any of the network suppliers (servicers/fishermen/validators). Contrast this to the case of dAPPs. bandwidth/storage/compute resources provided by network suppliers are consumed each time an RPC request is tendered to and fulfilled by the network. Therefore network suppliers should be compensated for this consumption and the protocol oversees the transfer of value from dAPPs to network providers through the burn and emission mechanisms. There is no analogous supply-side resource consumption for gateways.

Anything that is not essential to the protocol should not be specified in the protocol. I think this is a very basic design principle. I have already shown that dAPP gateways can exist outside the protocol (either invisible to the protocol or indistinguishable from a self-staked dAPP). Therefore gateways are not essential to the protocol and by corollary should not be specified in the protocol. Rather 3rd parties should be allowed to build gateways to serve their client base as they see fit and let the best solution win.

This is analogous to the community chain gateways that Decentralized Authority is building for chain pooling among node runners. It would be a gross inefficiency and waste of resources for protocol developers to try to spec out a "community chain gateway" and create new DAO-controlled parameters to determine the reward split between node runners, community chain providers and community chain gateways. This is a private matter between various 3rd-party entities who have the ability to adapt quickly to changing market dynamics and code up a build that meets their needs completely outside the purview of the protocol. Why can't the same be done in the case of dAPP gateways?