feat: add 7683 + intents framework discussion doc #15
Conversation
| ## Goals | ||
| Are we all in agreement on the high level goals of the open intents framework (OIF)? | ||
|
|
||
| * Should the generic solver implementation in the OIF work out of the box for any 7683 intents protocol (w/ no additional changes required)? |
There was a problem hiding this comment.
I don't think that is realistic (and also so far not a goal I have heard). Like we discussed on TG, it is likely that orderTypes and settlement is going to be diverse, so IMO the solver OIF implementation should be flexible enough to support different flavors. It already supports non-7683 intents like Eco's Routes, we have chatted with Jack about 7755 support, and there is a PR open to support the Compact
| Are we all in agreement on the high level goals of the open intents framework (OIF)? | ||
|
|
||
| * Should the generic solver implementation in the OIF work out of the box for any 7683 intents protocol (w/ no additional changes required)? | ||
| * Should the Base7683 implementation work out of the box for any intents protocol to make them 7683 compliant? |
There was a problem hiding this comment.
Would be curious to hear what this means in your view @notbdu
|
|
||
| * Should the generic solver implementation in the OIF work out of the box for any 7683 intents protocol (w/ no additional changes required)? | ||
| * Should the Base7683 implementation work out of the box for any intents protocol to make them 7683 compliant? | ||
| * Is the end goal to have a single 7683 contract impl deployed to each chain that protocols can plug into or is it to have each intent protocol inherit from the Base7683 contract and create/deploy their own implementations? |
There was a problem hiding this comment.
Long term speaking maybe, but I suspect in the short-term, people will have different requirements which is why even something like BasicSwap7683 exists. Things like refunds, duction auction order types, etc. feel hard to standardize without bloating and a lot of bikeshedding
There was a problem hiding this comment.
The current implementation is inheritance based. This scales poorly with proof systems and order types.
There was a problem hiding this comment.
Can you share what you were imagining? Again want to emphasize that this is not meant as anything close to final. Totally down discuss a different composition method to allow order types and proof systems to be composed without inheritance. It did seem like the simpler thing to start with? Like you could imagine a BaseDuctchAuction and then yes I contend that as a proof system provider, you have to now create ProofSystemSwap7683 and ProofSystemDutchAuction, but not super obvious to me how to avoid that?
There was a problem hiding this comment.
- Settlement contract that has logic for how to manage deposits
- Proof/oracle contracts that can validate that a delivery(ies) has taken place.
- Fill contract that allows custom order types independent of the other components.
Not to hoot my own horn but this is how Catalyst is designed. My reason isn't to make a standard but because I am lazy and I don't want to redeploy the entire stack if we add a messaging protocol or new order type.
There was a problem hiding this comment.
Can you share the implementation by any chance? I'm still not super clear how to split up the order type from the settlement of it
| * ERC7683OrderDepositorExternal translates the `_callDeposit()` call into an Across’s own deposit impl in their “spoke pool”. | ||
| * `_callDeposit` API exposes Across specific params such as exclusivityPeriod that are not defined in the 7683 spec. | ||
| * OIF implementation: | ||
| * Open methods implement the deposit logic. This means that protocol specific deposit logic is currently not supported. |
| * Resource lock impls generally require deposits to be made within the resource lock itself. This makes them incompatible with OIF’s current impl. | ||
| * Order data encoding. | ||
| * Across’s impl has many Across specific fields in their order data. The OIF impl does leave _fillOrder up to the inheriting contract to impl. | ||
| * This means that we’ll need a separate solver impl per intents protocol. Is this okay? Do we want to standardize some of the order data fields? |
There was a problem hiding this comment.
I think it is easier to have reference solver modules that abstract some of these differences than to try to standardize everything up front. The nice thing about 7683 contracts is that they can be stateless, so the interface can be additive over time
| * `_callDeposit` API exposes Across specific params such as exclusivityPeriod that are not defined in the 7683 spec. | ||
| * OIF implementation: | ||
| * Open methods implement the deposit logic. This means that protocol specific deposit logic is currently not supported. | ||
| * Resource lock impls generally require deposits to be made within the resource lock itself. This makes them incompatible with OIF’s current impl. |
There was a problem hiding this comment.
Couldn't the 7683 contract just forward the tokens to the resource lock?
There was a problem hiding this comment.
The Compact does not support deposits on behalf of along with registration of claims. It requires logic like: Uniswap/the-compact#37
Personally, I am also against forwarding funds if not needed since it wastes gas.
There was a problem hiding this comment.
I read the PR, but I'm not sure I understand, but also not an expert in resource locks. Why is it not possible to deposit on behalf of different account into the resource lock.
Alternatively, what would be your suggested change?
There was a problem hiding this comment.
Generally deposit and registration of claims are 2 different flows. This is mostly for security reasons.
You can deposit on behalf of someone else but you can't also register a claim (without the PR). This means that suddenly the Open interface makes a deposit but doesn't initiate the swap. You still need the claim registration. (Which needs to be another signed message or a call from the origin account)
The important aspect here is to make the interface broad enough to support arbitrary flows.
As a result, my recommendations are (as written in the documentation): Componentize the elementary elements such that they become LEGO pieces that can be arbitrarily used together.
| * Goal: To clear up confusion regarding who the depositor is. (Tokens should still be collected from msg.sender) | ||
| * Convert the open event into event Open(bytes32 indexed orderId, bytes resolveContext) and add resolve functions taking the original order and resolveContext to accurately produce the ResolvedCrossChainOrder from an off-chain view call. | ||
| * Goal: To reduce the cost of emitting the Open event. | ||
| * Make function open(...), openFor(...) optional. |
There was a problem hiding this comment.
As per above, totally possible to make the open semantics more generic
| Additionally, the specification should contain a description of how to integrate the lock flow: Outputs first, inputs second. | ||
|
|
||
| ## Open Intents Framework (Most severe to least severe) | ||
| * Does not support resource locks. |
There was a problem hiding this comment.
There is a PR for solver support of the compact :) BootNodeDev/intents-framework#48
There was a problem hiding this comment.
This is not criticism of the solver. A solver can support anything.
This is specifically a comment for the proposed intent framework.
The PR contains no smart contract logic.
There was a problem hiding this comment.
Then I would recommend being specific in your feedback :)
Yes the OIF today does not have a smart contract implementation of a resource lock. I don't think it has made a claim that it does, nor that it will or will not have one in the future. Is the criticism (notably "most severe"), that it doesn't have one? I dont know if I have to emphasize again that the OIF is not meant to be complete by any means, it's meant to be a starting point for people to contribute all kinds of different implementations and hopefully share abstractions and tooling.
There was a problem hiding this comment.
I am sorry on that oversight of mine. I acknowledge and will be more precise going forward.
I am a smart contract developer. When I see Intents Framework I think of a framework for building intents. Not a framework for solving intents.
These comments are made on the building side, not on solving.
|
|
||
| ## Open Intents Framework (Most severe to least severe) | ||
| * Does not support resource locks. | ||
| * Does not support deposit on behalf of. ERC-7683 flaw though. (aggregation breaker) |
There was a problem hiding this comment.
I read more deeply into this and I will admit I was wrong:
https://github.com/BootNodeDev/intents-framework/blob/main/solidity/src/BasicSwap7683.sol#L168
However, this doesn't work for smart accounts so there is that.
There was a problem hiding this comment.
I'm still not sure I understand what doesn't work, would you mind expanding?
There was a problem hiding this comment.
The refund account is set on the order data as the destination. (Correct me if I am wrong)
So if the destination account is a smart account that has a different address than the origin, a failure/refund will result in lost funds.
There was a problem hiding this comment.
What I want to, is to support 2 flows:
- Deposit for someone else using funds that YOU have right now. Importantly, the "someone else" could be yourself.
- Deposit for someone else using their funds via a permit.
This is mostly an ERC-7683 concern of mine and not specific to this framework.
| ## Open Intents Framework (Most severe to least severe) | ||
| * Does not support resource locks. | ||
| * Does not support deposit on behalf of. ERC-7683 flaw though. (aggregation breaker) | ||
| * You store bytes on-chain; Can't support complex order types as it would balloon the cost. |
There was a problem hiding this comment.
Agreed, that was actually active discussion at https://t.me/c/2307200913/7/238
There was a problem hiding this comment.
I generally agree with the discussion though I disagree thst the orderdata needs to be recoverable post order initiation.
The entitty required to resolve the order should already be known (either emitted or by the existence of the order itself)
There was a problem hiding this comment.
You also need this at settlement for repayment for the solver, yeah?
There was a problem hiding this comment.
That is true.
Though in which case maybe there needs to be 2 order data types?
A resolved packed structure and the raw initiation?
I don't know what the best method is but I don't think it should be made available on-chain by itself.
There was a problem hiding this comment.
I like the discussion this document is fostering! I believe however the document could be made more approachable (so more people can onboard themselves to the discussion and contribute) and more neutral (so it's easeier to merge & potentially finalize the discussion)
On neutrality:
- When proposing an approach (eg: consensus on 7683 being the way forward for cross-chain intents), try to do so by contrasting it against the other available alternatives and justifying it better implements the system's desireable properties
On approachability:
- Define concepts when introducing them (eg: Open Intents Framework), and link to its official definition if there is one. Ideally, we should have all concepts separated into a glossary document (I believe @Joxess is working on it in feat: add Nomenclature doc #17), so we use the same term to refer to the same concept across different discussions. Simply describing them within this document is enough for now.
- Try to explicitly separate the cross-chain-intents desired properties from what ERC7683 proposes, to make it clearer on what is left to standardize
- I believe it's currently only on gh discussions and not on the document itself, but be clear on when you're talking about a particular implementation (eg: BaseERC7683) versus an implementation-agnostic interface
| # 7683 (Open Intents Framework) - Goals & Issues | ||
|
|
||
| ## Context | ||
| There’s general consensus around pushing 7683 as an generic intents standard. In this document, we’ll attempt to clarify some of the goals of the effort and questions around the interface. Feel free to add your team’s POV to the doc! |
There was a problem hiding this comment.
There’s general consensus around pushing 7683 as an generic intents standard
While I'm not personally arguing against or in favor of this sentence, I'd prefer an introduction where more context (especially alternatives) are laid out, with the above as a logical conclusion. That'd prove less contentious to actors pushing competing standards, since they could dispute the reasoning or the data behind it instead of an authoritative claim.
| There’s general consensus around pushing 7683 as an generic intents standard. In this document, we’ll attempt to clarify some of the goals of the effort and questions around the interface. Feel free to add your team’s POV to the doc! | ||
|
|
||
| ## Goals | ||
| Are we all in agreement on the high level goals of the open intents framework (OIF)? |
There was a problem hiding this comment.
Please include a short explaination on what the open intents framework is, linking to where it is more formally defined. It'll make the discussion more approachable, especially since it's a niche concept and therefore not easily google-able
There was a problem hiding this comment.
link this file from docs/README.md and wherever else you think it'd apply
Adding a discussion doc around the goals of the open intents framework and discussion around how generalizable 7683 is across impls.