Elastic Labs - Polkadot Agent Kit - Milestone 1 #1270
Conversation
chungquantin
changed the title
|
Dear reviewers / curators. In the official pull request of the application w3f/Grants-Program#2549, I requested to receive the payment onchain, however, I would love to change to receive fiat for the first proposal (10k$) and receive the rest payment of the proposal in DOT and USDC as we had some changes in our company's operational plan. May I know the proper process to make the changes? |
|
Hey @chungquantin , Since this PR is now ready for review we'll get to evaluating. |
|
Hi @PieWol, thanks for letting me know, I was clarified in the main proposal PR and I'm happy with receiving stablecoins. |
|
Hi @PieWol may I know the status of the submission? It has been here for nearly a month. |
There was a problem hiding this comment.
Hello @chungquantin, apologies for the wait.
Thanks for delivering the first milestone - I've started review of your submission.
Your unit/e2e test suite passes on my side, and the integration tests pass on an M2's GPU and an RTX5090. I have not studied the test suite in detail yet though, so may have more feedback here.
In my review, I've focused on your instructions for client side, see my instantiation here: https://github.com/Lederstrumpf/polkadot-agent-kit-testing
This does unfortunately not work yet:
/> pnpm install dist/src/quickstart.js
/> tsc
/> node dist/src/quickstart.js
node:internal/modules/cjs/loader:664
throw e;
^
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './src/api/client' is not defined by "exports" in /home/lederstrumpf/polkadot/w3f-grants/evaluation-repos/polkadot-agent-kit-2549/polkadot-agent-kit-testing/node_modules/.pnpm/@[email protected]_@[email protected]_@[email protected]__89468b8fe91534884d194ff6c58c1ff8/node_modules/@polkadot-agent-kit/core/package.json
at exportsNotFound (node:internal/modules/esm/resolve:314:10)
at packageExportsResolve (node:internal/modules/esm/resolve:661:9)
at resolveExports (node:internal/modules/cjs/loader:657:36)
at Function._findPath (node:internal/modules/cjs/loader:749:31)
at Function._resolveFilename (node:internal/modules/cjs/loader:1387:27)
at defaultResolveImpl (node:internal/modules/cjs/loader:1057:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1062:22)
at Function._load (node:internal/modules/cjs/loader:1211:37)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24) {
code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}
Node.js v22.17.0
Adding your other @polkadot-agent-kit packages published via https://www.npmjs.com/~cqtin0903 did not address this issue.
If you have any changes to the sdk that are not published yet and fix this, please publish them.
Notwithstanding, please find below my preliminary concerns, in my subjective descending order of priority, tagged by applicable sub-milestone:
M1.2: transferNativeTool only supports polkadot & westend relay chains
The published version:
type DescriptorsRelayType = {
polkadot: typeof polkadot;
west: typeof west;
};Very easy fixes: Please add kusama and paseo too. I see you have added paseo relay to your repo's implementation, but not published this, yet kusama is certainly still missing there too, as are both kusama & paseo asset hubs.
I also note that, of the parachains, only bifrost (DOT), hydra, and paseo's people chain are supported. Is there a material technical reason you've omitted the others? To my understanding, your grant proposal's milestones are for a general XCM agent solution (in particular here M1.1b&c).
Unspecific: Agent can only be instantiated by providing private key
This isn't specific to a particular M1 sub-milestone, but the grant application specified that the sdk would support agent creation using mnemonics. However, it seems that the interface currently only takes raw private keys as the first (non-optional) argument to the PolkadotAgentKit constructor. Please add support for instantiation using mnemonics.
M1.1b&c: incorrect/outdate transferNativeTool usage in quickstart & missing xcmTransferNativeTool call.
The transferNativeTool call requires a KnowChainId type arg, which doesn't reflect in the quickstart instructions. Likewise, the published version only has transferNativeTool and no xcmTransferNativeTool. Please address.
M1.0b: unclear/fragmented quickstart instructions
Please spell out the configuration steps for testers & users of your sdk fully.
For instance, a short stub on setting up ollama would be helpful so users unfamiliar with this process don't spend time troubleshooting unnecessarily.
It would be nice if you could create a template repo for instantiating polkadot agents that future users of your sdk could use as a starting point. Apologies if this already exists, and I missed it in your sdk/docs.
M1.0c: CI doesn't cover e2e nor integration tests
Only the unit tests are within your CI suite, at least on GH.
M1.0c: integration tests fail when running on CPU
Please a timeout bypass, or set a reasonable timeout for slow ollama instances, in particular when running the model outside a GPU.
This isn't just a nit: I don't imagine that unless you get GPU instances for the pnpm test:integration, you'll be able to add these tests (successfully) in GH CI without increasing the timeout bound.
I'll review further once you have addressed the above issues.
For future deliveries:
Please test your setup & testing instructions fully before sending them in for evaluation.
Look forward to receiving your updates - I think this could be an exciting tool for users :)
|
Hi @chungquantin, please see my initial evaluation here - it largely overlaps with my comment above.
I've looked a bit into the details of your e2e/integration tests now. For instance, your integration test
Point 3. might seem pedantic, but since the ollama agent could also be initiating transacts other than intended by the user query Likewise, as mentioned in my M1.2 eval notes, I feel the scope of your xcm tests is currently too narrow. If I misunderstood the testing harness or missed some key code, then apologies for raising this comment's concerns. |
|
HI @Lederstrumpf, below is our report for the issues you mentioned above: M1.0a – Unable to run
|
Co-authored-by: Robert Hambrock <[email protected]>
|
HI @Lederstrumpf we have submitted our response for the evaluation report 0b. Instructions for client integration do not work yet, perhaps some will once latest sdk changes are published.Done: This is template testing for polkadot agent kit - Client Integration https://github.com/CocDap/polkadot-agent-kit-testing 0c. E2E & integration tests not part of CI pipeline yetWe have added the E2E on CI pipeline, because we have perfomed some integration tests on mainnet , then we dont add it into CI 1b. Firstly: Integration tests don't test constrain test outcome by any criteria; see 2. Secondly: No parachain->parachain tests in E2E or integration tests. Thirdly want to test client integration before approving; see 0b. PR for adding parachain and parachain testing: elasticlabs-org/polkadot-agent-kit#85 1c. Cannot assess this with certainty while E2E tests only assert that something™ happened - only checks for "success" & return of mock resultsPR for clear assertion: make sure the agent call correct tool call : elasticlabs-org/polkadot-agent-kit#85 2. Firstly: Doesn't seem the integration test suite actually checks for successful results - only that something™ happened - ein nischt-nischt. Secondly: Missing both paseo & kusama relay & asset hub chains, as well as most parachains. Thirdly: Only three xcm test queries in integration test suite; these should at least be supplemented by equivalent tests for other parachain/relaychain pairings.We have replied you on this comment #1270 (comment) |
|
Hi reviewers, cc @Lederstrumpf can you please let us know the next step? The submission has been in the review stage for more than a month and a half. |
|
Hi @chungquantin, Thank you for the updates to the delivery. 0c. Unit tests + E2E tests guide + CI pipeline
Thanks, note that even with the timeout increase, it still times out on an M2 Max CPU, so imagine it will likely do the same once in your CI, lest you get some GPU instances for the CI.
Noted, and understand the mainnet concern. In this case, could you please separate out the mainnet integration tests and only run the testnet integration tests within CI by default? 2. Thorough test coverage for XCM functionalities expect(result.output).toBeDefined();
expect(result.intermediateSteps).toBeDefined();
expect(result.intermediateSteps.length).toBeGreaterThan(0);
const xcmTransferCall = result.intermediateSteps.find((step: any) =>
step.action?.tool === 'xcm_transfer_native_asset'
);
expect(xcmTransferCall).toBeDefined();
expect(xcmTransferCall.action.toolInput).toMatchObject({
amount: '0.001',
to: RECIPIENT,
sourceChain: 'AssetHubWestend',
destChain: 'Westend'
});While checking that your tool receives the correct inputs is clearly a marked improvement over the prior test structure, I still deem it crucial though that you test for the on-chain result - this is a financial tool moving real value, after all.
To spell the above out: please check the onchain outcome of the tests. In the above example, this would be checking that
Note also that 3 of 7 integration tests fail, see attached logs from both nixos & ubuntu testing (with an RTX5090); logs below: For example: @polkadot-agent-kit/sdk:test:integration: AssertionError: expected undefined to be defined
@polkadot-agent-kit/sdk:test:integration: ❯ tests/integration-tests/sdk.itest.ts:161:22
@polkadot-agent-kit/sdk:test:integration: 159| expect(checkBalanceCalls.length).toBeGreaterThanOrEqual(1);
@polkadot-agent-kit/sdk:test:integration: 160|
@polkadot-agent-kit/sdk:test:integration: 161| expect(initCall).toBeDefined();
@polkadot-agent-kit/sdk:test:integration: | ^
@polkadot-agent-kit/sdk:test:integration: 162| expect(initCall.action.toolInput).toEqual({
@polkadot-agent-kit/sdk:test:integration: 163| chainId: 'polkadot'
Reiterating this: please test your instructions on a clean system (and run all tests) before sending in for evaluation. |
Without this `npm run build` fails. Required for w3f/Grant-Milestone-Delivery#1270.
PR: elasticlabs-org/polkadot-agent-kit#93 This change introduces pre- and post-execution balance assertions The test suite was executed successfully over times to validate
Setting up integration tests with Ollama in our CI pipeline is not feasible at the moment. My testing with an Ollama GitHub Action showed that large models like Llama 3.2 cause fetch failed errors and consume excessive CI resources. We have two options:
For now, we will proceed with Option 2: integration tests involving Ollama will be performed locally and will not run in the CI pipeline. 
|
|
Hi @Lederstrumpf, can you test it again? |
Lederstrumpf
left a comment
Lederstrumpf
left a comment
There was a problem hiding this comment.
Hi @CocDap and @chungquantin,
Thanks for the updates. I appreciate that you followed through on my suggestions - especially the segregation into testnet and mainnet tests.
On a high level review of the changes from elasticlabs-org/polkadot-agent-kit#93, your changes look plausible in spirit.
The rest of my feedback is unfortunately not as positive; hopefully Thom Yorke will mellow it:
A. The Bends
The integration:testnet tests fail for me:
1.
✓ PolkadotAgentKit Integration with OllamaAgent > should call check_balance tool with correct chain parameter 51262ms
× PolkadotAgentKit Integration with OllamaAgent > should call transfer_native tool with correct parameters 65403ms
→ expected 13892884555414 to be less than 13892884555414
× PolkadotAgentKit Integration with OllamaAgent > should call xcm_transfer_native_asset tool for Westend to Asset Hub transfer 209811ms
→ expected 13892884555414 to be less than 13808401819036
✓ PolkadotAgentKit Integration with OllamaAgent > should call xcm_transfer_native_asset tool for Asset Hub to Westend transfer 575902ms
✓ PolkadotAgentKit Integration with OllamaAgent > should call xcm_transfer_native_asset tool for West Asset Hub to West People Chain transfer 257335msFAIL tests/integration-tests/sdk.itest.ts > PolkadotAgentKit Integration with OllamaAgent > should call xcm_transfer_native_asset tool for Westend to Asset Hub transfer
AssertionError: expected { amount: '0.1', …(3) } to match object { amount: '0.1', …(3) }
- Expected
+ Received
{
"amount": "0.1",
- "destChain": "AssetHubWestend",
+ "destChain": "WestendAssetHub",
"sourceChain": "Westend",
"to": "5D7jcv6aYbhbYGVY8k65oemM6FVNoyBfoVkuJ5cbFvbefftr",
}
❯ tests/integration-tests/sdk.itest.ts:111:46
109|
110| expect(xcmTransferCall).toBeDefined();
111| expect(xcmTransferCall.action.toolInput).toMatchObject({
| ^
112| amount: '0.1',
113| to: RECIPIENT2,I could "fix" these failures by changing:
s/toBeLessThan/toBeLessThanOrEqual/gin sdk.itest.ts- sdk.itest.ts#L91 to:
- const userQuery = `transfer 0.1 WND to ${RECIPIENT2} from Westend to Westend Asset Hub`;
+ const userQuery = `transfer 0.1 WND to ${RECIPIENT2} from Westend to Asset Hub Westend`;Please address failure 1. correctly, since I'm sure my hack isn't applicable to all cases.
For failure 2. I note that @CocDap has earlier today pushed a similar "fix" elasticlabs-org/polkadot-agent-kit@1233a39 that might get your test to pass.
But I'll insist here that
👏 massaging semantically valid user prompts to mirror the code is NOT an appropriate approach for building an LLM tool intended to turn natural language prompts into valid xcm👏:
B: The words are coming out all weird
The queries
- "transfer 0.1 WND to ${RECIPIENT2} from Westend to Westend Asset Hub"
- "transfer 0.1 WND to ${RECIPIENT2} from Westend to Asset Hub Westend"
- "transfer 0.1 WND to ${RECIPIENT2} from Westend's relay chain to Westend's Asset Hub"
...
are all semantically equivalent; all these queries align on the user's intent, and are expressed clearly.
In fact: The "fix" pushed today (changing the user prompt to "transfer 0.1 WND to ${RECIPIENT2} from Westend to Asset Hub") is strictly speaking not even equivalent to these, since it is ambiguous which Asset Hub is getting referred to:
- Westend's Asset Hub?
- Polkadot's Asset Hub?
- Kusama's Asset Hub?
- Paseo's Asset Hub?
It's most likely Westend's Asset Hub since the other options would require bridging, but this is not unambiguously clear, and we certainly can't assume it's clear for the user.
The failure of parsing the test prompt correctly should tell you that your system prompt for xcm transfer rules is not doing its job, and hence that should be fixed instead of massaging a very reasonable user prompt into a semantically equivalent form that your LLM backend.
If the expectation is that users feed in "natural language" that matches the word ordering of your prompts exactly, then what's the gain for them against simply writing the xcm on their own / using polkadot.js?
C. Where do we go from here?
Note: I have not run your mainnet tests yet since the testnet ones already had issues. So far, I've specifically spelled out the issues I found in your code, but especially given the time put into the evaluation on my part so far, I cannot continue doing so. Generally, it concerns me that W3F is requested to evaluate submissions where the tests don't pass yet.
Important note: I expect that, from now on, all tests pass straight away on my system.
If they do not, then subject to the severity of the issue, I may either
- respond with something like "does not work" without providing further context
- close the PR
To avoid any false alarms in my next evaluation, I suggest that you
- when asking me to review again, also link the exact git revisions of the repos you tested with. Having said that, it is also reasonable to expect that the integration tests continue to pass after said revision on the
mainbranch. If they do not, I will probably assume you're not running the integration tests before pushing changes to themain. - run your tests not only on a MacBook, but also other reasonable LLM hosts (Nvidia/AMD GPUs and CPU Ollama) to have some degree of confidence that your users won't run into significant issues.
1. Problem: Root Cause of Test Case FailureI've identified the root cause for the failure of the The issue stems from the 2. Solution: Specialized PromptsTo resolve this, I have refactored the prompts. Instead of a single, large prompt for all tools, I have created smaller, specialized prompts for each distinct task (e.g., 3. Evidence: Model Performance ComparisonLink Testing: https://github.com/CocDap/polkadot-agent-kit-testing To demonstrate the reasoning limitations of
This confirms that while the user's query is correct, a less capable model can produce an incorrect outcome. The solution for these models is to use more specific, less complex prompts. 4. Additional Improvements
Link PR: elasticlabs-org/polkadot-agent-kit#109
5. Noted:Kindly checking the integration tests on this PR (elasticlabs-org/polkadot-agent-kit#109) Command to run : 6. ConclusionI've spammed the tests a lot, and all were successful. You can check the results on Subscan with this wallet: 
CC: @chungquantin @Lederstrumpf PS: Thank you for your careful review and thoughtful suggestion |
Without this `npm run build` fails. Required for w3f/Grant-Milestone-Delivery#1270.
|
Hi @Lederstrumpf, I understand the situation but our team has pushed this proposal so hard and also covered parts that was not in our declared approved proposal. This took us more 2 months for the very first milestone. Could you please take a quick look and see if what is the best way to unblock this? Because this takes time for both curator and developer. And we seriously want to push this project ahead not just blocked by the integration test - which is already covered as can be seen. |
There was a problem hiding this comment.
Hi @CocDap (cc. @chungquantin),
Thank you for the updates, and apologies for my delayed re-review.
I appreciate the detailed explanation+justification you provided, the increased testing scope of phrasing variations, and that the instructions for review in your latest comment were much clearer.
The new submission unfortunately also doesn't work: wrt testnet tests, potentially for me, but for the mainnet test, certainly in general too.
Given my delay in responding, I'll give more details as to what's failing than I intended to:
-
I recognize that the testnet integration tests must have passed for you (assuming on elasticlabs-org/polkadot-agent-kit#109 / elasticlabs-org/polkadot-agent-kit@ca8ba58 based on the test count in the screenshot), but they don't for me, either on elasticlabs-org/polkadot-agent-kit@ca8ba58 or its two followup commits. Please find below logs of all the failures I encountered in said revisions at the bottom of this comment. When exactly did you run the tests again? Asset Hub migration for Paseo was ~ a month before your resubmission (https://forum.polkadot.network/t/asset-hub-migration-2025/11129/71), so I don't believe this is related.
-
More critical than the testnet integration test failure, the mainnet test doesn't work, and given the changes made in elasticlabs-org/polkadot-agent-kit#109, I must assume you did not run this test again before requesting my re-review.
-
The correction I pushed for 2. is only the first step. Please also test the observation of that test: the observation
observation: {"content":"{\\"success\\":true,\\"data\\":\\"Cross-chain swap failed: 0.1 DOT to USDt from polkadot to polkadot_asset_hub. Error: Cannot read properties of undefined (reading 'otherAssets')\\",\\"tool\\":\\"swap_tokens\\",\\"timestamp\\":\\"2025-10-15T21:11:57.842Z\\"}","tool_call_id":"swap_tokens_1760562717842"}is currently passing and obviously should not. -
Please also extend the testing for mainnet operation - that single DOT/USDt swap test is not sufficient (very narrow scope) - I'd expect something comparable to the testnet scope - especially given your recent move to a more "handwired" solution with context-specialized prompts, as you noted in #1270 (comment).
Test logs of 1.:
- testnet-aba3953f4f45f385b4617af348e1fc2df7d88f22.log (current
main) - testnet-cbb7e92a484be65df1f2467371bf0e74fad043f3.log (current
main~1) - testnet-ca8ba5843f6c89084318f6f00d5b01d3a80aab23.log (current
main~2, i.e. elasticlabs-org/polkadot-agent-kit#109)
|
Hi @chungquantin @Lederstrumpf , Thank you for the detailed review and for running the integration tests. I've investigated the failures and would like to provide some context and clarification on the issues you've encountered. 1. Integration Test Failures on PR-109 (elasticlabs-org/polkadot-agent-kit#109)I believe the test failures you observed are not related to the code in this PR but are due to external factors.
Action Requested: Could you please try running the integration tests for PR #109 again? It is likely the network is stable now. If the // utils.ts
export const RECIPIENT7 = '5HWWpa7SnP81UdxKGD5neyqMbjRdi324txAFZ2z4LgcBpC21';
export const RECIPIENT8 = '5G8uJUCZMhihBdBMooxBE1pWhmvvyr2nWvaJNUKb6dNiuEjS';
...
describe('2. Parachain to Relay Chain Transfers', () => {
const parachainToRelayCases = [
{
name: 'Westend Asset Hub to Paseo 1 ',
query: `transfer 0.1 WND to ${RECIPIENT7} from Westend Asset Hub to Westend`,
recipient: RECIPIENT78,
sourceChainId: 'west_asset_hub',
destChainId: 'west',
expectedSourceChain: 'AssetHubWestend',
expectedDestChain: 'Westend'
},
{
name: 'Paseo Asset Hub to Paseo 2',
query: `transfer 0.1 WND to ${RECIPIENT8} from Asset Hub Westend to Westend`,
recipient: RECIPIENT8,
sourceChainId: 'west_asset_hub',
destChainId: 'west',
expectedSourceChain: 'AssetHubWestend',
expectedDestChain: 'Westend'
}
];
parachainToRelayCases.forEach(({ name, query, recipient, sourceChainId, destChainId, expectedSourceChain, expectedDestChain }) => {
it(`should call xcm_transfer_native_asset tool for "${name}"`, async () => {
await testXcmTransfer(name, query, recipient, sourceChainId, destChainId, expectedSourceChain, expectedDestChain);
}, 3500000);
});
});2. Clarification on Mainnet Swap TestsI saw your notes on the mainnet swap tests failing. I am aware of this issue. However, please note that this functionality is explicitly a requirement for Milestone 2, not Milestone 1. I will address these swap-related issues in a separate PR as part of the work for the next milestone. 3. Clarification on Failures in the
|
|
To provide proof for my assertion, I manually observed the balances, and they correctly match the asserted expect(balanceRecipientAfter.data.free).toBeLessThan(balanceRecipientBefore.data.free + amountParsed);
expect(balanceAgentAfter.data.free).toBeLessThan(balanceAgentBefore.data.free - amountParsed - feeXCM.fee);My manual check: I trust that the core Parity team has already thoroughly tested the before-and-after balance logic also |
|
Hi @CocDap, Thank you for your detailed investigation.
Thanks - I have tried your commit #109 on Paseo again today and it worked, so I agree with you this must have been a network over the last week (the tests added after said commit still fail for me). I'll review the rest of your update the coming days - just sharing this quick followup to avoid that you unnecessarily fret about the Paseo test failures anymore. Thanks again for looking into it. |
|
Hi @CocDap, Hopefully my at-most penultimate followup here ;)
Milestone 2 does not mention mainnet tests anywhere and M1.2 promises integration tests with "Thorough test coverage for XCM functionalities" already. So I really read this as being part of milestone 1.
Acknowledged - and the nomination pools are indeed only part of milestone 2. Please find my updated evaluation over here:
Unfortunately, the docs linked in your PR (https://cocdap.github.io/agent-docs/quickstart.html) have still not been updated - the latest state is still from July: elasticlabs-org/polkadot-agent-kit-docs@a97343d And your interfaces have changed quite a bit in the meantime - you'll see this once you try running those instructions. Once you update the quickstart instructions and they all work smoothly in my review, I'm happy to approve your PR. |
|
Hi @Lederstrumpf , I'm hoping this will be the final round of feedback and fixes for this milestone 😃 I've made several updates based on your feedback. 1. Documentation Updates
Link Docs : elasticlabs-org/polkadot-agent-kit-docs@97dd0f5
2. Mainnet Integration TestI have successfully updated and run the mainnet integration tests, including the changes from PR #114. 
3. How to Run the TestsTo ensure the tests run correctly on your end, please note these two critical requirements:
Thanks again for your careful review. Your feedback is helping us build a more stable and approachable SDK for all developers. 🏆 |
|
That's great news, thank you for the approval! We just wanted to add a special thanks for the high-quality review. Your @Lederstrumpf feedback was clear, fair, and has definitely helped us improve. |
Lederstrumpf
left a comment
Lederstrumpf
left a comment
There was a problem hiding this comment.
Hello @CocDap,
Thanks for the final fixes & instructions for them.
As noted in the update of my evaluation, I think the quickstart tutorial should still be improved since it doesn't document how to actually use the tools, neither in the snippet https://cocdap.github.io/agent-docs/quickstart.html#basic-usage, nor in the API navigation https://cocdap.github.io/agent-docs/quickstart.html#tools-call-api-navigation. Both only show how to instantiate them.
I understand that, for this purpose, you added the examples https://cocdap.github.io/agent-docs/examples/. Those are sufficient for me, but in general, the quickstart should actually get the dev from a blank slate to a working environment for building their own tool.
In any case, as noted in the evaluation, I'm fine to defer this to the milestone 2 evaluation, which you have already opened #1299 for.
So, luckily this is my last update on this specific PR - thanks for bearing with me - I'm sure this also felt like pulling teeth for you ;)
I'm confident this will be simpler in future.
|
🪙 Please fill out the invoice form in order to initiate the payment process. Please make sure that you follow the instructions and requirements as laid out in the form as well as our Terms & Conditions. Thank you! |
|
Congratulations on completing the first milestone of this grant! As part of the Grants Program, we want to help grant recipients acknowledge their grants publicly. To that end, we've created a badge for projects that successfully deliver their first milestone. Please use the badge only in reference to the work that has been completed as part of this grant, so please do not display it on your team or project's homepage unless accompanied by a short description of the grant. Furthermore, you're now welcome to announce the grant publicly. Please remember to observe the foundation's guidelines in doing so. If you haven't already, reach out to [email protected] for feedback on your announcement and cross-promotion. |
|
I really appreciate your detailed feedback. The SDK has become significantly more user-friendly and maintainable |
5 participants
Milestone Delivery Checklist
Link to the application pull request: w3f/Grants-Program#2549 < please fill this in with the PR number of your application.