Visibility is fine, that is not the issue, you can just simply change for eg “The Tjati Council allocation is 9%” to 19 % at any time and say it was always that. Without a downloadable PDF file (edit-protected) all this is just “trust me bro”.
That’s a valid point, well taken, we will figure out a way to make this immutable, thank you for highlighting it
We had a team working on a cloakcoin protocol upgrade for 5 months. The code was huge and untangling the privacy mechanics has been extremely enlightening and difficult. But today we are proud to announce that ICP CAN be natively integrated with privacy chains. We have open sourced for community feedback and review as it is a critical piece of infrastructure.
Menese Whitepaper
This was captured on 2026-03-26 from https://www.meneseprotocol.io/
MENESE PROTOCOL
Composable Cross-Chain
Execution
An engine you build on; not a protocol you use.
CHAPTER I
The Problem
Cross-chain DeFi in its current form is broken; not because the ambition is wrong, but because the infrastructure it depends on has been fundamentally flawed from the start.
Over $2.5 billion has been lost to bridge hacks in the last three years alone. The root cause is always the same; bridges hold custody. Whether it is a multisig, a guardian set, or a validator network; someone controls the keys. That someone can be hacked, bribed, or compromised. The promise of trustless finance collapses the moment you have to trust a third party to move your assets between chains.
The fragmentation compounds the problem. Liquidity is scattered across over a hundred blockchains. A user who wants to move capital from Solana to Ethereum needs a separate wallet, a bridge, a DEX on the other side; each introducing its own fees, its own risks, its own points of failure. What should be a single action requires navigating a maze of disconnected protocols.
The current generation of cross-chain technology providers has attempted to solve this; each introducing its own trust assumptions. Message-passing protocols rely on oracles and relayers to verify cross-chain messages; if the oracle is compromised, messages are forged. Guardian-based validators use small sets of trusted parties; often under twenty; to approve cross-chain operations. History has shown these to be high-value targets; a single guardian set compromise has resulted in losses in the hundreds of millions.
MPC wallet providers split your private key across their servers and your device. The cryptography is sound; the trust assumption is not. Your key shares live on a company’s infrastructure; if that company is compromised or shut down, so are your keys. Centralized agentic platforms offered by major exchanges provide “smart” wallet tools; but your agent runs on their servers, your keys live in their custody or their MPC. It is corporate dependency with additional steps.
Beyond security; there is an automation gap that no existing provider addresses. DeFi is manual. There is no protocol that allows you to set a condition; “if APY drops below 5% on Solana, move my liquidity to Ethereum”; and actually execute it trustlessly across chains. You can set alerts. You can run bots on your own servers. But you cannot encode cross-chain financial logic that runs autonomously, on-chain, without depending on infrastructure you do not control.
Finally; there is the walled garden problem. Most DeFi protocols are closed systems. You use their pool, their interface, their rules. You cannot build on top of them. If you want a launchpad; you wait for someone to build one. If you want a custom pool; you fork an entire protocol. There is no composable engine that anyone can build on; no open set of primitives that gives you cross-chain execution without requiring you to become a protocol team yourself.
These are not separate problems. They are manifestations of the same structural flaw; cross-chain infrastructure has been built on trust assumptions that contradict the premise of decentralized finance. The solutions proposed so far have addressed symptoms while reproducing the same conditions they were designed to solve.
CHAPTER II
Menese Protocol
Menese is a composable cross-chain execution engine; anyone can build financial tools on top of it, powered by ICP’s chain-key cryptography, with no bridges, no guardians, no corporate custody.
The protocol operates on a simple principle. ICP nodes collectively hold signing keys using threshold cryptography. No single node, server, or company ever holds a full key. The signing authority is distributed across an independent decentralized network; no single company, no single provider; secured the same way the other chains themselves are secured. The complete private key is never reconstructed; not during generation, not during signing, not ever.
Many cross-chain providers use forms of threshold cryptography or multi-party computation to manage keys. They solve the signing problem; distributing key shares so no single party holds the full key. But signing is only one piece of the puzzle; and this is where the critical distinction lies.
MPC providers give you a distributed key and stop there. You still need your own servers to watch the market. You still need your own bots to decide when to act. You still need your own infrastructure to coordinate between chains. The intelligence lives off-chain; in your stack, on your servers, dependent on your uptime.
Menese collapses the entire execution loop into the canister itself. A Menese canister does not just sign; it reads the world via HTTP outcalls; blockchain RPCs, price feeds, any API; directly from on-chain code. It decides what to do based on logic encoded in the canister. It signs and submits real transactions on the destination chain. The smart contract becomes truly intelligent; it perceives, decides, and acts; autonomously, on-chain, without any off-chain infrastructure.
This is the difference between a distributed key and a distributed brain.
The distinction in trust model is equally important. When an MPC wallet provider splits your key; the shares live on their servers, in their data centers, managed by their team. With chain-key on ICP; key shares are held by independent node operators running a decentralized network. No single company controls them. No single provider can be pressured, hacked, or shut down to compromise your keys. It is the same trust model that secures Bitcoin and Ethereum; distributed consensus, not corporate custody.
The guarantee that follows from this architecture is absolute. Even if the Menese frontend goes down; even if the team disappears; your canister is on-chain, your keys are in the subnet, your automation keeps running. The canister keeps watching, keeps deciding, keeps executing. There is no relayer to go offline. There is no guardian to compromise. There is no company whose terms of service can change under your feet. This guarantee extends to every protocol Menese integrates with; if the DEX you are swapping through loses its frontend, if the lending protocol’s relayer goes down; you can still execute through Menese’s on-chain canister. The on-chain frontend is not just a hosting choice; it is a fallback layer for the entire ecosystem of protocols we connect to.
CHAPTER III
The Ecosystem
Menese is not a single product; it is an execution engine. Everything we build; swaps, pools, launchpad, automation; is built on the same primitives available to everyone. We are not restricting any of this.
This distinction matters. Most protocols build tools and keep the underlying engine closed. You can use their swap; you cannot build your own. You can provide liquidity to their pool; you cannot spin up a competing one with different parameters. The protocol is the product and the product is the boundary.
With Menese; the engine is the product. If you want to spin up your own swap pool; you can. Your own launchpad; you can. Your own lending market, your own yield aggregator, your own cross-chain payment system; the SDK gives you chain-key signing, HTTP outcalls, and on-chain execution across every supported blockchain. A few lines of code to launch an ERC-20 token on Ethereum. A few more to create a Solana program. The same interface to send an XRP payment or provide liquidity on any chain. What you build with it is up to you.
The SDK is designed with an AI-friendly interface; deliberately so. Developers can use AI-assisted tools to compose and create their own financial products on top of the Menese engine. Describe what you want to build; an AI agent can help wire together the cross-chain primitives to make it real. This is not DeFi for protocol teams with twenty engineers. This is composable finance for everyone.
What is already live demonstrates this. Multiple cross-chain pools are in community testing; executing swaps at world-class speeds. Your assets remain in your custody; Menese executes the trade, not a custodian. Liquidity providers can participate in any supported pool; setting their own price ranges and fees, with the protocol aggregating from available liquidity.
The automation engine is where the vision becomes most concrete. Set conditions in plain logic; “if SOL APY drops below 5%, move my liquidity to Ethereum.” Your canister monitors chains via HTTP outcalls; evaluates your conditions; and executes cross-chain transactions autonomously. No cron jobs. No AWS Lambda. No centralized keepers. The canister is the automation; on-chain, unstoppable, running on ICP’s timer system. This applies across every automation pattern; APY migration across chains, dollar-cost averaging into any asset on any chain, limit orders where the canister watches and executes when price conditions are met, portfolio rebalancing that maintains target allocations automatically.
The same infrastructure extends to AI agents. The MeneseAgent canister paired with OpenClaw plugins and the SDK gives agents the ability to read markets via HTTP outcalls; propose strategies; and execute trades through the same trustless infrastructure that powers everything else.
The token launchpad has already been showcased; accepting payments across multiple chains through one sale canister. Cross-chain fundraising without bridges. And because it is built on the same composable engine; anyone can deploy their own launchpad with their own terms. Lending and borrowing follow the same pattern; supply collateral on one chain, borrow on another; same chain-key security, same on-chain execution guarantee.
The entire application runs from ICP canisters. No AWS. No Vercel. If the domain goes down; the canister still serves the frontend. If the frontend goes down; your automations still execute. This matters beyond Menese itself. As the protocol integrates with external DEXes, lending platforms, and staking protocols; the on-chain frontend becomes a security layer for those integrations as well. If a third-party protocol’s relayers are compromised or their access is disrupted; users can still execute through Menese’s on-chain interface. The canister does not depend on anyone else’s infrastructure to remain accessible.
CHAPTER IV
CKMC
When a token exists on multiple chains; the most fundamental guarantee in finance breaks down. Total supply becomes unverifiable. Wrapped tokens create inflation risk that is invisible until it is catastrophic; who ensures the one-to-one backing? The answer across the industry has been trust; trust that the bridge operator maintains reserves, trust that the lock-and-mint mechanism functions correctly, trust that the guardian set validating the mint has not been compromised. This is the same trust model that has already cost billions.
The Chain Key Master Canister solves this problem through native execution. CKMC maintains constant total supply across all chains by executing mint and burn transactions on-chain. When MENES is moved to another chain; the CKMC burns on the source and mints on the destination; atomically, verifiably, with no custodian. There is no wrapped token. There is no lock-and-mint. There is a single canister with signing authority over MENES token contracts on every supported chain; enforcing that total supply remains exactly 100,000,000 at all times.
MENES will be the first token to use CKMC. The implementation is straightforward in principle; the canister holds the derived signing keys for each chain’s token contract. When a cross-chain transfer is initiated; the canister burns on the source chain and mints the equivalent on the destination chain in a single coordinated operation. The total supply is verifiable on-chain at any point; enforced by code, not by trust.
Every other approach to multi-chain tokens relies on lock-and-mint; which is custodial by definition; or message-passing; which is trust-dependent by design. CKMC is neither. It is native execution of supply management; the same chain-key guarantee that powers every other part of the Menese engine.
CKMC is not exclusive to MENES. Any project launching a multi-chain token through the Menese engine can use CKMC to guarantee constant supply across all their supported chains. This is part of the composable architecture; the same primitives we use are available to everyone.
CHAPTER V
MENES Token
The MENES token has a fixed total supply of 100,000,000 tokens; this supply will never change. The token follows the ICRC-2 standard on ICP.
The allocation reflects a deliberate balance between community ownership, long-term alignment, and operational sustainability. The largest allocation; 27.5% at 27,500,000 tokens; is reserved for Treasury and LP. This funds liquidity pool seeding and operations; with 4,000,000 tokens earmarked specifically for the Tjati community budget. The second largest; 20% at 20,000,000 tokens; is designated for the SNS Decentralized Sale. There is no venture capital round. There is no private sale. The SNS sale is community-driven by design.
Team and Founders receive 18% at 18,000,000 tokens; subject to an 18-month cliff and 36-month vesting schedule. Mercatura receives 10% at 10,000,000 tokens under the same cliff and vesting terms. These lockup periods ensure that the team’s incentives remain aligned with the protocol’s long-term success; not short-term price action.
The Tjati Council allocation is 9% at 9,000,000 tokens; structured as 9 seats at 1,000,000 MENES each. Each seat is priced at $0.05 and requires a buy-and-stake commitment with an 18-month lock. Currently; 3 seats remain available. This is not a grant; it is a purchase that binds the council member’s capital to the protocol’s performance.
Staking Emissions account for 7% at 7,000,000 tokens; distributed at 1,750,000 tokens per year over four years. The APY decreases as more stakers join the pool; this is by design. Locked shares from the team, Tjati, and Mercatura allocations will also be staked once live; aligning every locked token with the network’s staking incentives.
Community and Marketing receives 5% at 5,000,000 tokens; managed by the Tjati Council for campaigns and chain expansion. The Early Public Sale was 3.5% at 3,500,000 tokens; priced at $0.035 per token; now completed.
MENES tokens are currently available through the Menese Protocol Liquidity Pool and through available Tjati Council seats.
CHAPTER VI
Staking and Referrals
Anyone can stake MENES tokens; even below 5,000 tokens you earn emissions. There is no minimum to participate in staking rewards. However; tiers unlock progressively greater benefits across the entire Menese ecosystem.
The first tier is Scribe; requiring 5,000 to 49,999 MENES staked. Scribes receive a 5% discount on SDK subscriptions, a 5% discount on swap fees, 50 AI credits per month, and a 1x referral multiplier. This is the entry point; the minimum commitment that grants access to the referral program and ecosystem discounts.
The second tier is Nomarch; requiring 50,000 to 249,999 MENES staked. Nomarchs receive a 20% SDK discount, 15% swap discount, 500 AI credits per month, and a 1.5x referral multiplier. Nomarchs also unlock sovereign wallet customization, 48-hour early access to new features, and Governance Lite voting rights on non-critical proposals.
The third tier is Pharaoh; requiring 250,000 to 999,999 MENES staked. Pharaohs receive a 35% SDK discount, 25% swap discount, unlimited AI credits, and a 2x referral multiplier. Pharaohs unlock .menese name registration, one-week early access to new features, and full Governance Lite participation.
The highest tier is Tjati; requiring 1,000,000 MENES staked with an 18-month lock. Tjati members receive all Pharaoh benefits plus a 3x referral multiplier and full governance powers as council members.
The referral model is designed to create a self-reinforcing growth loop. Every user who stakes at Scribe tier or above receives a referral link. When someone you refer uses Menese services; swaps, SDK calls, automation; you earn a percentage of the protocol fees they generate. The percentage is multiplied by your staking tier.
To illustrate; your referral swaps $1,000 through Menese. The protocol takes a 0.3% fee; that is $3.00. As a Scribe with a 1x multiplier; your referral reward is $0.30. As a Nomarch at 1.5x; $0.45. As a Pharaoh at 2x; $0.60. As a Tjati at 3x; $0.90. At scale this compounds significantly. A Pharaoh with 20 active referrals; each doing $5,000 per month in volume; generates $300 in monthly protocol fees from those referrals. At the 2x multiplier; that is $60 per month in referral rewards.
The base referral rate is set by protocol governance and can be adjusted as the ecosystem scales. A minimum tier of Scribe is required; referral rewards are distributed in MENES tokens; a per-referral cap prevents gaming; and referral links expire after 12 months unless the referrer is still actively staking.
The emissions schedule distributes 1,750,000 MENES per year proportionally to all stakers. APY starts high and decreases as the staking pool grows. Locked shares from the team, Tjati, and Mercatura allocations are also staked once live; aligning long-term incentives across all participants.
CHAPTER VII
Revenue Model
The protocol generates revenue from multiple sources; swap fees, SDK subscriptions, automation execution fees, token launchpad fees, and in the future; lending and borrowing spreads. Each of these revenue streams grows proportionally with ecosystem adoption and chain expansion.
The distribution of protocol revenue follows a clear and deliberate structure.
55% of all revenue goes to buy back and burn. Over half of every dollar the protocol earns is used to purchase MENES on the open market and permanently remove it from circulation. This is not a discretionary decision; it is encoded in the protocol’s revenue distribution. The deflationary pressure increases proportionally with usage; as more chains are added, as more swaps are executed, as more developers build on the SDK; the burn rate accelerates. Supply decreases while utility increases.
20% of revenue is allocated to the community budget. This is distributed to all stakers; not exclusively to the Tjati Council; so that the broader community can self-organize initiatives. Marketing campaigns, content creation, chain advocacy, liquidity programs; any staker can propose and vote on how this budget is deployed. The intent is to give every participant the same capacity for community leadership that the Tjati Council exercises at the governance level. Composable governance for a composable protocol.
25% of revenue covers protocol expenses. Infrastructure, development, security audits, legal compliance. The allocation is reported transparently to the community.
The flywheel that emerges from this structure is self-reinforcing. More chains lead to more swaps; more swaps generate more fees; more fees drive more burns; burns reduce supply; reduced supply supports token value; higher token value attracts more stakers; more stakers provide more liquidity; more liquidity enables more chains. This cycle does not depend on emissions alone; it is powered by real revenue from real usage. The protocol’s economic sustainability is built into its architecture; not dependent on perpetual token issuance.
CHAPTER VIII
Tjati Council
The Tjati Council consists of 9 seats; each corresponding to a blockchain. Each Tjati member purchases and stakes 1,000,000 MENES at $0.05 per seat; locked for 18 months. Currently 3 seats remain available. This is not a nomination or an election; it is a capital commitment. Your stake is your seat. Your alignment with the protocol’s success is measured in the same token that everyone else holds.
Each Tjati member is assigned a blockchain and bears responsibility for its integration quality, liquidity growth, and community development. This is not a passive governance role; it is chain stewardship. The Tjati for Solana owns Solana’s success within the Menese ecosystem. The Tjati for Ethereum owns Ethereum’s. The accountability is direct and measurable.
The council’s powers are structured around five governance functions. Chain stewardship allows each member to submit roadmap items for their assigned chain; voted on by the full council with a 5 of 9 majority required to pass. Treasury proposals allow members to request funds from the community budget; capped at 3% per proposal; which amounts to 270,000 MENES; again requiring a 5 of 9 vote. Protocol parameter votes cover fee changes, new chain additions, pool parameters, and protocol upgrades. Emergency proposals can be triggered by any single Tjati member; initiating a 24-hour fast-track window that still requires 5 of 9 to pass. This is reserved for security incidents, delistings, or critical fixes.
The fifth power is Nomarch nomination. Each Tjati can nominate up to 3 Nomarchs; community managers who require a minimum of 50,000 MENES staked. Nomarchs run community channels and events for their assigned chain; they hold Governance Lite voting rights on non-critical proposals; and they are directly accountable to the Tjati who nominated them. Underperforming Nomarchs can be replaced through a council vote.
The governance flow creates a cascading structure of accountability. The Tjati Council sets direction and manages the community budget. Nomarchs execute community growth on assigned chains. Growth feeds back into the protocol through increased usage and liquidity. Protocol revenue funds the community budget. The Tjati allocates that budget. The cycle reinforces itself.
There is a re-staking requirement that prevents complacency. At the end of the 18-month lock; every Tjati member must re-stake to retain their seat. If they do not; the highest staker holding 1,000,000 or more MENES takes their position. There are no lifetime appointments. Skin in the game; always.
CHAPTER IX
Competitive Landscape
The cross-chain infrastructure space is not short on providers; it is short on providers whose security model survives contact with reality. Each category of existing solution has produced its own class of failures; and the failures are structural, not incidental.
Message-passing protocols; some supporting over a hundred networks; relay messages between chains and depend on oracles or relayers to verify them. The security assumption is that the oracle network remains honest. When that assumption fails; and it has; forged messages drain funds. Menese does not relay messages. The canister reads chains directly via HTTP outcalls and signs real transactions on the destination chain. There is no oracle middleman; the canister sees the state of the world for itself.
Guardian-based validators use small sets of trusted parties; often under twenty; to approve cross-chain operations. The history of this approach speaks for itself; a single guardian set compromise has resulted in losses in the hundreds of millions of dollars. The attack surface is concentrated by design; compromise the guardians and you compromise everything they protect. Menese distributes signing across a decentralized network; no single company, no single provider; secured the same way the chains themselves are secured.
MPC wallet providers; some with tens of millions of users; use the same family of threshold cryptography to distribute keys. The math is similar; the trust model is not. But more importantly; they solve only one part of the problem. They distribute the key; they do not distribute the intelligence. You still need your own servers, bots, and keepers to watch markets, make decisions, and coordinate execution across chains. Menese collapses the entire loop; the canister reads the world via HTTP outcalls, decides what to do with on-chain logic, signs and executes the transaction. All in one place. All on-chain. The difference is between a distributed key and a distributed brain.
Centralized agentic platforms; now offered by major exchanges; provide wallet tools and “onchain operating systems.” The marketing suggests autonomy; the architecture delivers dependency. Your agent runs on their infrastructure. Your keys live in their custody or their MPC. If they go down, get hacked, or change their terms; you lose access. With Menese; your agent is a canister, your keys are in the network, your logic is on-chain. There is no corporate dependency to manage or mitigate.
What none of these providers offer is open composability. You cannot build your own launchpad on a message-passing protocol. You cannot spin up a custom pool on an MPC provider’s platform. You cannot deploy your own automation strategy on a guardian network. These are closed systems that offer access to their products; not their primitives. Menese is an open engine; the same primitives we use to build our products are available to anyone. With AI-assisted tooling that lowers the barrier; building cross-chain financial products becomes accessible to solo developers, small teams, and AI agents alike.
CHAPTER X
The SDK
The Menese SDK gives you access to every supported blockchain from a single interface. This is not a wrapper around one chain’s tools; it is an execution engine that lets you build on every chain, sign on every chain, and deploy on every chain; all from one place.
Launch an ERC-20 token on Ethereum with a few lines of code. Create a Solana program. Send an XRP payment. Provide liquidity on any chain. The SDK abstracts the complexity of each chain’s native tooling into a unified set of endpoints; over thirteen cross-chain operations covering EVM liquidity, Solana swaps, Cardano, XRP; each handling the full execution lifecycle. The developer calls the SDK; the canister handles chain interaction via HTTP outcalls and signing.
Subscriptions are tiered; from individual developers to enterprise teams; pricing scales with usage. Stakers receive up to 35% discount on all tiers.
The composability is by design; not by accident. The SDK exposes the same primitives Menese uses internally. If you want to build a cross-chain launchpad; you use the same token deployment and multi-chain payment endpoints we use. If you want a custom AMM pool; you use the same liquidity and pricing primitives. If you want a yield optimizer; you compose automation, swap, and liquidity endpoints together. Nothing is locked away. There is no premium tier that unlocks “the real API.” The engine is open.
The AI-friendly interface is deliberate. The SDK is designed so that AI agents and AI-assisted development tools can compose financial products naturally. Describe what you want to build; an AI agent can wire together the right endpoints, deploy the canister, and set up the automation. This removes the barrier that has historically limited DeFi innovation to well-funded protocol teams. A solo developer with an idea and an AI assistant can build and deploy a cross-chain financial product that would have previously required a team of twenty.
The automation capability is what distinguishes the SDK from every other blockchain development kit. The SDK is not limited to one-off calls. Developers can build persistent automations; canisters that monitor conditions across chains and execute strategies around the clock without any off-chain infrastructure. HTTP outcalls mean your canister talks directly to any blockchain RPC. There is no middleware. There is no keeper network. There is no server to maintain. The canister is the server.
There is no vendor lock-in. The signing canisters are on-chain. If the Menese API layer ever goes offline; developers can call the canisters directly. Your automation does not depend on our servers. Your financial product does not depend on our uptime. The engine runs on ICP; not on Menese’s infrastructure.
CHAPTER XI
Vision
The trajectory of cross-chain infrastructure over the past five years has followed a familiar pattern; each new generation of providers promises to solve the problems created by the last, while reproducing the same structural dependencies under different names. Bridges became guardian networks. Guardian networks became MPC providers. MPC providers became “agentic platforms.” The vocabulary changed; the trust assumptions did not.
Menese is built on a different premise. Not a protocol you use; an engine you build on. A composable, cross-chain execution layer where anyone; a solo developer, an AI agent, a community DAO; can create financial tools that work across every blockchain.
The same security. The same execution guarantees. The same open primitives. No bridges to hack. No guardians to bribe. No relayers to go offline. No permission needed.
Just code, cryptography, and execution; for everyone.
MENESE PROTOCOL — 2026
We really appreciate it 
thank you
Will check it out, fantastic progress.
We have open sourced a full LTC node in Motoko with its primitives and libs for the community. This is part of a great effort between @MForum and several private and public universities here under something called the Hive Mind Project, it’s a project that was established to evaluate L1 candidates for several national subnets. We are benefitting from this and did contribute to it and we are sharing this benefit even tho we can’t deploy it for cost considerations at the moment. We will be able to deploy it on our dedicated engine later along with several other nodes that we have finalized for other chains as well(yes we have similar works like this in final audit phase)
Things to look forward to in our next updates:
1- New ads creative campaign plus PR https://x.com/meneseprotocol/status/2047233091240960417?s=46&t=ZbNb94M7k9y5EWO4fsxEOg
2- Privacy pools using Cloak, we already enabled privacy send by computing privacy addresses and adjusting cloak node infrastructure to suite ICP
3- Staking and APY allocation across Sui-Cardano-Solana and Eth
4- CLMM pools with an LP marketplace that activates based on automated strategies allowing non custodial LP allocation and flexibility in capital allocation
5- Hyperliquid and trading games
6- Ck variants for internal trading plus CLMM pools for ICP tokens
7- testing debit card issuance infrastructure with a partner is on going, we are testing for timing feasibility at the moment
We will keep you updated, end of this Q, we are planning either SNS and/or CEX listings.
We did forget to add, CLMM pools are coming to the ecosystem both cross chain, ecosystem tokens and our chain key tokens. Two weeks count down.
Our new ad campaign started, we going with sketches this time
Menese Protocol is indeed an interesting initiative, as it aims to connect ICP with other blockchains and banking integrations may realistically become part of it. The involvement of the Dubai team indicates that cooperation with banks in the region is highly likely, which would allow users in Georgia and neighboring countries to top up cycles directly through banking payments.
However, my support for this project depends on one critical condition: canister balances and cycles burn must be publicly visible on‑chain. Without transparency, Menese Protocol would only be another “black box,” where usage cannot be verified and trust will be lost.
If this condition is met, Menese Protocol could become a genuine step forward for ICP — both technically and economically. Otherwise, the risks to trust and legal stability are too high for the project to be sustainable.
Theres already a public cycles ledger. Canister cycles balances should not be mandatorily public as that’s a security risk.
What are on the process actually of enabling people to contribute to cycles purchase with a credit card-other means as well so everyone can make sure their infrastructure has redundancies, as mentioned by @Lorimer it would pose a security risk. However being proactive as allowing people to top off the canister would mitigate part of your concern
I understand why not the balance, but shouldn’t inter canister transfers be public and recorded on the ledger? Or is there a security risk with that too?
Lorimer, You found me here too? Are you chasing me? 
An intermediate path could look like this: aggregate burn metrics are published so everyone can see how many cycles were burned in total or by category; data is released with a delay, for example once a day or once a week, so it can’t be used for real‑time attacks; instead of showing the exact balance of a specific canister, only a range is published, like 1–10T cycles; and full logs are accessible only to auditors, while public users get summarized statistics. This way transparency is ensured and security is protected.
Finding balance is necessary, not leaning to either extreme.
Security should benefit everyone, but never serve corruption.
That’s understandable concern, but we did not receive any cycles in terms of grants or giveaways. Menese is already generating revenue and sustaining over 14 team members full time with enterprise usage in the pipeline. We can think of a system that shows historical cycles consumption and different rates, it would help with investor reports so this point could be relevant actually. Bear in mind we have 26 canisters and over 140 for R&D just within Menese Protocol ecosystem
I intuitively like Dubai’s involvement in this matter and I see the great potential Dubai holds as a financial and technological hub, and the important steps it can take. Therefore, I welcome the Menese Protocol and its initiative. At the same time, I welcome balanced security and transparency as essential foundations for trust. I wish you success from Georgia 
We are starting to let our CLMM cross chain pool to the public. We will want to decentralize all canisters handling CLMM operations with the SNS, just those canisters to mitigate trust assumptions. We hope this will be a solid step in rallying everyone to this cross chain expansion. A separate topic will be created for this cross chain CLMM pools infra
Episode 2 of our ad series is here, would you believe it if we told you the director is award winning film maker and trained under Martin Scorsese…true story haha
New ad is out, our marketing team is building on interest from enterprise to integrate. We are already supporting 4 ecosystem dapps through general and special SDK canisters