So cool Michel! Awesome work. Fun!
Very nice! Keep up the great work
Hello,
I create ICP content on YouTube, and I always try to address the tech aspect of ICP. Here is my channel (https://www.youtube.com/@LetsAskClaudeCrypto) As a non-techie, I would like to publish a video about the importance of this moment where WP can now be functional on ICP. Can anyone inform me how this is a breakthrough, and what it could mean for future adoption and the ICP token? I will attempt to use as much info as this community gives me. Thank you.
Look up all the WASP threads from Michel and read them all.
All the information is right here.
He couldn’t implement it using a single canister design due to instruction limit limitations on the IC along with other limitations that happen per round… but he didn’t give up and figured out how to create a design with 3 canisters and a cache that isn’t perfect, but works. Given more time, I have no doubt Michel will get more things running and hopefully with the least amount of latency so they are actually usable. It’s a great achievement.
This is a conceptual architecture for a Zero-Trust banking payment system in WordPress based on ICP (Internet Computer Protocol).
This concept is based on the fact that WordPress, with its PHP-based logic, database structure, and browser-dependent UI layer, does not represent a trusted environment for financial operations. Any layer — server, plugin, or browser — can potentially be compromised or manipulated. Therefore, the main goal of this architecture is to completely isolate financial logic from WordPress and move it into a cryptographically secure, deterministic execution environment.
In this model, WordPress remains only as a presentation and content layer, while all critical operations are executed on ICP canisters, which act as the single source of truth and execution layer.
The core of the system is the Payment Core Canister, which functions as a strictly defined state machine. Each payment is created with a unique payment_id and moves through predefined states: Initiated, PendingBank, Confirmed, Expired, or Reversed. State transitions are not performed by overwriting data — instead, every change is recorded as an immutable event, creating an append-only history. This ensures full auditability, reproducibility, and resistance to tampering.
The system is based on an event-driven architecture. Every user action — payment initiation, cancellation, or any interaction — is converted into an immutable event and sent to ICP. WordPress does not store transaction states and does not make financial decisions. It only acts as a relay layer.
Event handling and routing are performed by a Gateway Canister, which validates requests, checks cryptographic signatures, and forwards data to the appropriate canisters. This layer protects the system from tampered or malicious inputs and acts as a security boundary.
Communication with real banking systems is handled by a Bank Outcall Canister, which uses HTTP outcalls. Responses from the bank are not treated as final truth — they are considered external signals that must be verified and confirmed within the Payment Core Canister. In this design, the bank is not a decision-making entity but only an execution interface.
All operations are logged in an Audit Canister, where events are stored in a cryptographically chained ledger. Each record is linked to the previous one via hash references, forming a tamper-evident history. Any modification attempt would immediately result in detectable inconsistencies.
On the WordPress side, there is only a PHP Relay Plugin, whose role is strictly limited. It generates a signed payload containing payment details — such as amount, IBAN, order ID, and expiration time — and sends it to ICP. WordPress does not perform validation, state management, or transaction processing.
In the browser, a Zero-Trust Frontend Renderer operates, which only accepts signed data and verifies it using ICP public keys. If the data is invalid, the payment action is blocked. However, the browser does not make any final decisions — it only reflects already verified states.
Transaction lifecycle management is fully handled on ICP. If a payment is not completed within a defined time window, an automated mechanism moves its state to Expired and logs this event in the system. This removes any dependency on frontend or WordPress-based timeout logic.
The entire architecture is based on a zero-trust principle, where neither the browser, WordPress, nor the bank is considered a trusted source. The only trusted layer is the ICP canister state, which is cryptographically secured and deterministic.
As a result, this concept describes a system where financial operations are executed in a decentralized, verifiable environment, while WordPress serves only as an interface layer for interaction with the system, significantly reducing the attack surface and increasing overall system trustworthiness.
This is a conceptual architecture and is intended as a design proposal that developers can use as a reference to build improved or alternative implementations.
Can you stop spamming your AI contents?
When the forum supports language selection, when all posts are automatically translated into the Android system language on mobile, and when I need your permission to decide how I translate an idea, only then I will stop using AI to translate ideas.
Until I need your permission, you should focus on your own work.
The post is labeled as a concept and is of a fairly high level. The main priority is improving ICP — that is what matters, not what tool I use to translate my idea.
A post is not evidence; it is a possible solution. It is an idea, and when developers see many ideas, they can solve problems better.
With your comment, developers gain no benefit.
Turn this forum into a communist organization and everything will be exactly as you want, but it will last only for a very short time.
Every time you switch to personal insults, I will think aloud and say something directed at you, and you will understand what I mean.
Each time you come to my post, I will say something out loud, so know this in advance before you write anything on my post.
Let’s keep this wonderful thread on topic.Honestly, this is one of the most important endeavors on ICP imo. The is the correct strategy that we should have implemented from day 1 imo.
Michel brings easy migration to ICP and we will begin to bring people here to create the burn we desire esp. with bloated web2 CMS and other type web applications.
Thank you very much!
Hello, I’m Dev, and I posted below how I have a YouTube channel. I want to discuss this development in my next video. May I ask why you decided to engage in this endeavor, and why you believed it was so important? How do you believe this will grow the ICP community? Please feel free to provide any other details. If you do respond, please use non-techie language so that my audience can understand. Thank you!
Caffeine and Cloud Engines are indeed important as is ICP Ninja and all the blockchain tech.
WASP is just a very smart strategic move to gain adoption via super simple migration via compatibility. i.e. It’s just plain common sense.
Blown away by the speed of ICP canisters serving WASP cached pages. With zero optimization, we reached a 99% Speed Index on GTmetrix.com.
Thank you MIadey for your initiative on the project. I just published my video about this project. If you search @letsaskclaudecrypto, you’ll see it on youtube. Really appreciate it.
Hey! That’s a cool video and great idea 
keep it up
Love your video! Keep it up!
Thank you! Means a lot.
Hey @miadey, based on your experience porting web2 systems to web3, do you have a take on how hard it would be to run a compiler (not picky about language) within a canister, and actually build from source on-chain and then run it on-chain?
This would allow canisters and source code to be verifiably paired without users having to perform reproducible builds locally.
As I was writing this I also started thinking about running scripting language runtimes onchain (for lighter workloads).
Hey @Lorimer,
My thinking is that a compiler could be easier than having an interpreter running completely in a canister. First problem that I see is the instruction limit, if you’re running out of the 5B or 40B instructions (5B is free, not 40B). You’d also need a file system, something like GitHub - wasm-forge/stable-fs: File system implementation for the Internet Computer · GitHub could be a good start.
I would give a try at TinyGO, its open source and could be a good ice breaker.
Running script could be more difficult, I can think of running Linux script would need a more complet offer from the ICP canister (wasip2) as there would be tons of functions missing.
I’d give compilation a try with TinyGo