DEV Community: SSS DeFi

Building an AI-Ready On-Chain Trading Layer on ICP: SSS Agent Kit v1.2

SSS DeFi — Fri, 29 May 2026 06:27:30 +0000

SSS Public Beta has recently gone through a major infrastructure upgrade.

While the full announcement covers Ethereum funding, canonical stablecoin markets, reserve safety, Wallet Swap Flow v2 and Growth Room, this post focuses on the developer side:

SSS Agent Kit v1.2.

The core idea is simple:

AI plans. SSS executes on-chain.

SSS is not launching a hosted AI trading bot.

SSS does not run the AI model.

SSS does not store user LLM keys.

SSS does not custody user private keys.

Instead, SSS provides deterministic on-chain trading interfaces that external agents, wallets, bots and OpenClaw-style systems can call.

Why Agent Kit?

Most AI trading discussions focus on the “AI brain”.

But for real trading, agents also need a safe execution layer.

They need to:

read market context;
check balances;
preview trades;
submit actions;
handle retries safely;
track execution status;
avoid exposing the user’s main wallet.

That is what SSS Agent Kit is designed for.

Account model: dedicated Agent Principal

The recommended model is to use a dedicated ICP Principal for the agent.

A user can create an Agent Principal, fund it with only the intended SSS internal trading balance, and let an external agent interact with SSS through that Principal.

This means:

the agent does not need the user’s main wallet;
risk is isolated to the Agent Principal’s balance;
SSS does not store PEM files or LLM keys;
withdrawals are disabled for agents in v1.2.

This is closer to a controlled sub-account model than a full wallet delegation model.

What Agent Kit v1.2 supports

Agent Kit v1.2 currently supports:

market context;
portfolio read;
swap preview;
limit order draft preview;
self-account swap submit;
action status by client_tx_id;
recent action history.

The currently supported flow is:

Agent / Bot / Wallet
  → get market context
  → get own portfolio
  → preview swap
  → submit self-account swap
  → query status by client_tx_id

Safety boundaries

Agent Kit v1.2 does not support:

agent withdrawals;
delegated trading;
proxy trading from a user’s main account;
limit-order submit;
SSS-hosted AI inference;
SSS-hosted LLM keys.

These limits are intentional.

The first version focuses on self-account trading for external agents, with a clear security boundary.

client_tx_id and idempotency

One important part of the design is client_tx_id.

Agents and bots often retry requests.

Without idempotency, retries can become dangerous.

With client_tx_id, an agent can submit a swap and later query its status. If the same submit is retried, the system can return the existing result instead of executing the trade again.

This is critical for safer automation.

Agent-readable docs

SSS provides several agent-readable entry points:

Agent Kit docs:https://docs.sssdefi.ai/ai-agent-kit
Agent Manifest:https://docs.sssdefi.ai/agent-manifest.json
OpenClaw Quickstart:https://docs.sssdefi.ai/ai/openclaw-skill/QUICKSTART.md
Full public beta upgrade:https://www.sssdefi.ai/blog/sss-public-beta-major-infrastructure-upgrade-en

Part of a larger trading infrastructure upgrade

Agent Kit is only one part of the latest SSS Public Beta upgrade.

SSS is also moving toward:

Ethereum funding routes;
canonical USDT / USDC balances;
CEX-style public markets;
stronger reserve and route safety;
Wallet Swap Flow v2 for wallet integrations.

The broader direction is:

Private Stablecoin Trading on ICP

CEX Experience · DEX Trust

Conclusion

The first step toward AI-ready trading is not to give an AI full control of a user’s wallet.

A safer path is to give external agents a deterministic, permission-aware execution layer.

SSS Agent Kit v1.2 is the first public beta step in that direction.

AI plans.

SSS executes on-chain.

Learn more:

https://docs.sssdefi.ai/ai-agent-kit

Full announcement:

https://www.sssdefi.ai/blog/sss-public-beta-major-infrastructure-upgrade-en

What We Learned from KongSwap: Product, Governance, Trust, and Exit Design in DeFi

SSS DeFi — Sun, 12 Apr 2026 11:02:18 +0000

This is not an attack on KongSwap or on any individual. It is a builder-focused postmortem.

Kong is worth studying precisely because it was not a trivial project. It had real product ambition, a strong speed narrative, visible ecosystem thinking, and for a time it looked much closer to success than many failed projects ever do.

In crypto, failed projects are common.

What is rare is a calm, systematic, product-level review of why something that looked promising still failed to earn durable trust.

That is why KongSwap matters.

It publicly promoted 2.5-second average swaps, 99.9% success rate, zero gas, and a bridgeless multichain vision on its homepage. In its own comparison article, it highlighted metrics such as 8-second average swaps, roughly $6.07M TVL, roughly $488.7K in 24-hour volume, around 7,800 holders, and about $2M raised via SNS.

This was not a project with no product.

It was a project that looked, for a time, as if it might work.

And that is exactly why its sunset is instructive.

What Kong got right

Before talking about failure, it is important to acknowledge what Kong actually did well.

1. It built a strong product perception around speed

Kong understood something many DeFi teams still underestimate:

Perceived speed is itself a product feature.

Users rarely care about architectural elegance. They care whether the interaction feels fast, smooth, and credible. Kong made speed part of its identity, and that gave it a real edge in user perception.

2. It leaned into ICP-native differentiation

Kong did not simply try to be “another DEX.”

It positioned itself around themes like:

fast on-chain UX
multichain reach
zero-gas interaction
chain-fusion-style infrastructure narratives

That mattered, because good products are often built by aligning with what the underlying platform does uniquely well.

3. It had broader ecosystem ambition

Public materials show that Kong extended beyond swapping into pools, staking, APIs, governance narratives, and ecosystem-adjacent tools such as Kong Locker.

That does not mean all those extensions were equally mature.

But it does show that Kong was not a one-page app with no depth.

Why Kong looked close to success

Many projects fail because they never achieve traction at all.

Kong looked different.

At one stage, it had most of the visible ingredients that make a DeFi project look promising:

a clear narrative
visible performance claims
some product-market traction
ecosystem ambition
enough public metrics to support the story

Its whitepaper described a single-backend-canister architecture, using stable memory to manage pools, trades, user accounts, staking, and claims.

That detail matters.

Kong’s speed story does not appear to have come from a unified internal ledger model of the kind some newer trading systems are pursuing. Instead, it appears to have come from a different philosophy:

concentrate core state
shorten the processing path
reduce cross-module overhead
optimize for perceived speed
rely on rollback / claims logic to handle exceptions

That approach can absolutely produce a fast, impressive product experience.

But it also creates a different risk profile:

when value movement, state transitions, and exception handling are heavily concentrated in a central backend path, any weakness there can become system-wide.

Where Kong really lost

The official sunset announcement said the problem was product-market fit.

That may well be true.

Projects do shut down because PMF is not strong enough. Teams do run out of conviction. Markets do cool off.

But PMF alone does not explain why the shutdown hit such a nerve.

The community reaction quickly moved beyond “the product didn’t work” to harder questions:

Who actually has the authority to shut down a DAO-branded project?
What happens to treasury and code?
How should users think about responsibility boundaries?
What does a credible exit path look like?
What is the relationship between technical shutdown and governance legitimacy?

That is where this stopped being just a product story.

It became a trust story.

Security made the trust problem worse

The public bounty disclosure thread pushed that even further.

According to that disclosure, a critical, permissionless, full-drain vulnerability affecting Kong’s backend canister had been reported, with roughly $1.5M at risk in ICP and ckUSDT.

Whether one agrees with every part of the subsequent dispute is not the point.

The important lesson is this:

Once a project is already under pressure, a serious security issue is no longer just a security issue.

It becomes a governance issue.

Then a legitimacy issue.

Then a trust issue.

That sequence matters for every DeFi builder.

If your security response path, bounty logic, treasury handling, and public communication are not mature before a crisis, you will end up improvising exactly when trust is most fragile.

What this teaches us about DAOs

The lesson is not “DAOs do not work.”

The lesson is:

DAO language often matures faster than DAO institutions.

The official SNS model is compelling in theory: the dapp is governed by the community through proposals covering upgrades, treasury flows, and governance rules.

But reality is harder.

A DAO is not automatically credible because it has:

a token
proposals
treasury
voting mechanics
decentralization rhetoric

It becomes credible only when critical questions are already designed in advance:

Who controls emergency actions?
Are user exit rights independent from political disputes?
Can treasury decisions be made responsibly under pressure?
Can the codebase and docs survive the founding team stepping back?
Is there a real shutdown and takeover process?
Is security response actionable before consensus politics slows everything down?

Those are not abstract governance questions.

They are product questions, institutional questions, and operational questions.

And they matter more in DeFi than in most other software categories because users do not just trust your roadmap. They trust you with assets.

A note on ecosystem extensions and responsibility boundaries

One subtle but important lesson from Kong is that formal ownership boundaries are not the same as user trust boundaries.

For example, Kong Locker should not simply be described as an official KongSwap core product. Public materials indicate it was part of the broader Alexandria ecosystem, not the formal core product.

That distinction matters legally and organizationally.

But users do not naturally think in those layers when assets, liquidity, and governance assumptions are tightly connected.

From a product perspective, this means:

if your system has tightly coupled extensions, third-party tooling, or ecosystem layers that shape user decisions, then your responsibility surface is often broader than your official ownership surface.

That is uncomfortable — but important.

Five lessons builders should take seriously

1. A good product is not the same thing as a good institution

A project can have strong UX, clear differentiation, and still fail when governance, continuity, and crisis response are weak.

2. A fast UX is not the same thing as a trustworthy system

Users love speed.

But speed does not replace recoverability, observability, or exit safety.

3. DAO narratives should not run ahead of governance reality

If actual control, emergency action, and responsibility boundaries remain narrow, then “DAO” can become branding rather than institutional truth.

4. Security response must exist before the crisis

A mature system needs:

disclosure paths
bounty policy
emergency handling authority
communication protocol
recovery playbooks

Not after the incident. Before it.

5. Trust is tested in the worst moment, not the best one

The strongest signal of a system is not how it performs at peak momentum.

It is how it behaves:

under pressure
during incidents
during shutdown
during ambiguity
when users want to exit

Why this matters to builders like us

For teams building on-chain trading systems, these are not “somebody else’s problems.”

They are inevitable problems.

That is one reason some teams, including ours, are choosing not to rush into a token-first path.

Governance does matter. A lot.

But tokenization should not outrun operational maturity.

Our current view is straightforward:

build the product foundation first:

asset safety
exit paths
observability
receipts and reconciliation
clearer responsibility boundaries
stronger anti-failure design

Only then does governance stand on something real.

Long term, we still believe more advanced DAO design is possible.

But it should be built on top of systems that already behave responsibly under stress.

Not the other way around.

Final thought

Kong is worth studying not because it failed, but because it got enough right to make the later failure deeply instructive.

That is what makes it a useful case for builders.

The real question is not whether Kong “should have survived.”

The more important question is this:

What kind of on-chain systems do we want to build next?

If the answer is “faster, safer, easier to trust, and better prepared for the hardest scenarios,” then Kong’s story is not just a postmortem.

It is a design brief.

From: https://www.sssdefi.ai/blog/what_we_learned_from_kongswap-en

Sources

Kong homepage: https://kongswap.io/
Kong comparison article: https://kongswap.io/kb/articles/icp-eco-dex-comparison
Kong API docs: https://kongswap.io/kb/documentation/kongswap-api-documentation
Kong whitepaper: https://github.com/KongSwap/documentation/blob/main/kong_whitepaper.md
Kong sunset thread: https://forum.dfinity.org/t/sunsetting-kongswap-please-remove-your-liquidity-by-april-6th/65951
Kong bounty disclosure thread: https://forum.dfinity.org/t/the-real-reason-for-the-kongswap-sunset-bounty-disclosure/65975
Kong Locker docs: https://konglocker.com/docs
SNS overview: https://learn.internetcomputer.org/hc/en-us/articles/34084394684564-SNS-Service-Nervous-System

Designing a Fully On-Chain Trading System: Lessons from SSS

SSS DeFi — Fri, 10 Apr 2026 06:49:09 +0000

Most decentralized exchanges today are built on AMM models.

While AMMs solve liquidity bootstrapping, they are not ideal for high-performance trading.

In this article, we explore a different approach: designing a fully on-chain trading system.

Key Design Problem

The core challenge is:

How do you achieve CEX-level UX while remaining fully on-chain?

This requires solving three constraints:

Latency
Execution precision
State consistency

Internal Ledger Design

Instead of relying on external token balances, SSS introduces an internal ledger.

Benefits:

Instant balance updates
No per-transaction gas friction
Simplified accounting

This allows the system to behave more like a centralized exchange internally.

Execution Model

SSS does not use AMM curves.

Instead, it implements:

Orderbook-style logic
Limit orders
Partial fills

This enables:

Precise pricing
Reduced slippage
Better trading control

ACK vs Finalized

One key innovation is separating:

ACK (fast response ~0.15s)
Finalized (on-chain settlement ~2–3s)

This creates a hybrid UX:

Users get instant feedback
State remains fully verifiable

Trust Boundary

Unlike CEXs:

No custody of user funds
All logic is on-chain

Unlike AMMs:

Execution is deterministic
Not dependent on liquidity curves

This creates a new trust model.

Conclusion

Fully on-chain trading systems are not just an optimization.

They represent a new architecture for crypto trading.

As infrastructure improves, this model may replace both AMMs and traditional DEX designs.

References

Docs: https://docs.sssdefi.ai
App: https://app.sssdefi.ai
Website: https://www.sssdefi.ai