[Proposal idea] Non-custodial conditional orders and wallet-level automation limits for Canton — feedback and a champion wanted
grants-discuss0 messages
- Hi everyone,
I'm Dmytro Plavutskyi, founder of Ryntra (https://ryntra.io), a non-custodial trading app live on Solana mainnet. Amanda Martin from the Canton Foundation suggested I bring this idea here for feedback and to look for a champion.
THE PROBLEM
People who trade on Canton need price-triggered orders — limit, stop-loss and take-profit — that don't require custody, don't depend on a single venue and stay within limits the user set. And as automation grows (recurring buys, scheduled execution, delegated actions), a user needs one place to see every automation acting for their party, cap it and switch all of it off at once.
HOW IT RELATES TO #627, #812 AND #685
- #627 (Delegated Automation Capability) is a general authorization layer for bounded, typed automated actions. If it is accepted, we would build on it rather than define our own permission model: conditional orders and wallet limits become concrete uses of it.
- #812 (Pinnaccle DCA) triggers on time within a budget. Ours triggers on price. A DCA plan and a stop-loss can sit under the same wallet limits.
- #685 (Private Scheduled Execution) splits a large order over time. Ours executes a whole order once a price condition holds. We would reuse the same Token Standard allocation-and-settlement pattern.
ARCHITECTURE (DRAFT)
- Conditional order (Daml): created by the owner; holds the side, the amount, the trigger (limit, stop or take-profit), an on-ledger floor (the minimum amount received), an expiry and the allowed venues, backed by a bounded Token Standard allocation. The owner can cancel at any time; proceeds settle only to the owner's party.
- Executor (TypeScript reference runner): watches venue quotes off-ledger and submits the settlement when the trigger holds. Safety stays on-ledger: the contract rejects any fill below the owner's floor or after the expiry, so a faulty executor can at worst fail to execute — never fill below the floor or send funds anywhere else.
- Wallet-level limits (Daml): one contract per party with caps — order size, daily volume, maximum slippage, allowed assets and venues — and a "revoke all" choice that cancels every active order and allocation in one action. Other automation (for example #812, #685 or #627 grants) can check the same limits before acting.
- Venue adapters: Cantex first (public quote API), Temple next.
OPEN-SOURCE SCOPE (Apache-2.0)
Daml packages, the TypeScript executor, a TypeScript SDK for wallets and apps, venue adapters, tests and docs. Ryntra would be the first app to integrate it; the infrastructure is not tied to Ryntra.
DRAFT MILESTONES (durations and budget in the formal proposal)
1. Daml models on LocalNet — conditional orders (limit, stop-loss, take-profit) with floor, expiry and cancel; wallet limits with "revoke all"; public tests.
2. Reference executor and the Cantex integration on DevNet — triggered fills, restart recovery, ledger-based reconciliation; a public demo.
3. The Temple integration, the TypeScript SDK and the limits interface for other automation; docs.
4. TestNet validation, an independent security review, the first production integration and maintenance.
LINKS
- App, live on Solana mainnet: https://ryntra.io
- Product demo (September 2026): https://youtu.be/cZ9gwis5fBA
- Public code (Apache-2.0; TypeScript SDK, MCP server and CLI used in production by Ryntra): https://github.com/ryntra-io/ryntra-solana-evidence
QUESTIONS
- Would anyone from Tech & Ops, the DeFi Protocols & Liquidity SIG or the dApp Integration SIG be open to championing this?
- Would the #627 team be open to us building on their capability?
- We plan to prototype on LocalNet and then DevNet — pointers to the recommended DevNet onboarding route are welcome.
Thanks,
Dmytro Plavutskyi
Founder, Ryntra Hi Dmytro,
Thanks for referencing #812. Just to add some context on Pinnaccle: limit orders and stop-loss orders are also part of our product, as outlined on our website and in our public Featured App application submitted in June. Our codebase already includes order contracts and backend trigger logic for these features, which are undergoing internal testing ahead of public availability.
Our market swaps and automated DCA are already live on Canton MainNet, with execution evidence included in #812. Our proposal builds on that existing implementation to make the recurring-execution infrastructure independently reusable and open source. Its scope includes bounded authorization, price protection, expiry, settlement reconciliation and recovery, rather than every trading feature in Pinnaccle.
Cantex is also one of the venues we’re evaluating for our reference integration, so there may be useful common ground on the adapter side.
Best,
Ecem
Co-Founder of Pinnaccle- Hi Ecem,
Thanks for the context — that's helpful, and congratulations on having swaps and DCA live on MainNet. Since Pinnaccle already covers limit and stop-loss orders, we won't propose a parallel order implementation.
The piece we think nobody covers yet sits one level up: a wallet-level view of every automation acting for a party — Pinnaccle's, #627 grants, #812 plans, #685 schedules — with shared caps and a single "revoke all". It would sit next to existing apps rather than compete with them. If that's useful to Pinnaccle or the #627 team as an integration point, we'd be glad to shape it with you; if the community doesn't see a need, we'll leave it here.
Best,
Dmytroпт, 9 окт. 2026 г. в 14:57, Ecem K via lists.sync.global <ecem=pinnaccle.xyz@...>: