Category: Articles

  • The Architectural Answer to the Mythos AI Security Vulnerability: GRIDS

    The Architectural Answer to the Mythos AI Security Vulnerability: GRIDS

    Security Brief for Central Banks and Regulators
    QPQ AG, Zug, Switzerland – 20 April 2026

    On 7 April 2026, Anthropic announced Mythos and Project Glasswing simultaneously. The two announcements cannot be understood separately: Mythos is the model; Project Glasswing is the defensive response to what it could do.

    What it could do: Mythos autonomously identified and exploited a 27-year-old vulnerability in OpenBSD – an operating system known specifically for its security record – granting root access from anywhere on the internet, without authentication, without human involvement after the initial instruction. Root access means complete control: the ability to read every file on the system, install anything, delete anything, impersonate any user, and move silently to every connected system – invisibly, at machine speed.

    Mythos found this flaw, built the exploit, and executed it autonomously. It can chain three to five such vulnerabilities end to end, and it found thousands of them across every major operating system and browser in production use.

    The Response

    Confronted with this, Anthropic initiated Project Glasswing, giving approximately 50 selected organisations – including Amazon Web Services, Apple, Google, JPMorganChase, Microsoft, and Nvidia – early access to scan and patch their own systems.

    Within days, the US Treasury Secretary and Fed Chair convened Wall Street’s largest bank CEOs for the first joint emergency meeting of its kind since October 2008. The Bank of Canada convened its Financial Sector Resiliency Group. The Bank of England is convening its Cross Market Operational Resilience Group within the fortnight.

    On 13 April 2026 the Cloud Security Alliance, SANS, OWASP, and a contributor list spanning the former directors of NSA cybersecurity and CISA, the Google Chief Information Security Officer, and the former US National Cyber Director consolidated this into an emergency framework: eleven priority actions for how the industry should respond, with their own caveat that “long-term goals should be considered a quarter away at most.”

    Why That Response is Doomed to Expensive Failure

    The official response has treated this as a security problem requiring better defences: the same tools, the same approach, the same vendors, with more urgency and even bigger cybersecurity budgets. From their perspective this is understandable. It is also wrong for two reasons.

    Firstly, the dynamics are now permanently in the attacker’s favour.

    An attacker needs one route to one credential. A defender has to stop every route, every time, forever. An attacker failing a thousand times costs nothing; one success compromises everything. A defender catching 99.9999% of attempts still lets 0.0001% through, and at machine speed, that fraction is all that is needed. One access point is enough to move laterally across every connected system.

    Defensive AI does not close that gap; it cannot. Even the best-performing models hallucinate between 0.7% and 2% on the easiest tasks. The attacker needs the defender to be wrong once, and can run millions of probes in parallel at machine speed, across every exposed data set in the institution.

    Moreover, however you judge Anthropic’s actions in this, Mythos is the first of its kind, not the last. Whatever emerges to compete with or succeed Mythos will share its properties. The defender is not up against a single model; they are up against a category of capability that will proliferate.

    In this context, more defences and bigger cybersecurity budgets merely inflate the cost of inevitable compromise, harvesting and exploitation; the only variable is when.

    The Architectural Error

    Secondly, and most importantly, treating it as a security problem understates and mis-categorises it: correctly, it is an architectural problem that has been present for thirty years and has now become impossible to ignore.

    The internet was built to share information. HTTPS made that transmission secure and universal. It works for its purpose. That is the Internet of Data, and it is what the cybersecurity industry has been built to defend.

    What the internet was never built to carry is economic activity: the transmission of value, financial credentials, identity, payment instruments, sensitive economic records.

    These have a property information does not have: they must not be copied. A news article exists to be copied; that is how it reaches its reader. A payment that has been copied is not a payment – it is an error, or it is theft. The property that makes the Internet of Data useful is the property that makes it unsafe for economic activity.

    The financial system has run economic activity over information infrastructure for thirty years because no alternative existed. Thirty years of patches – tokenisation, encryption in transit, zero-trust, multi-factor authentication, hardware-backed credentials – are the industry’s accumulated attempt to close the gap, but ultimately it amounts to trying to make a car do what a ship does.

    A car and a ship are not competing designs. They have different properties suited to different purposes. A car cannot cross an ocean and a ship cannot drive down a motorway. Both are necessary, and both have tooling appropriate to purpose. What the financial system needs – and has always needed – is an internet of economics with the appropriate tooling to protect rather than share data.

    The Architectural Answer

    The correct response is to remove sensitive economic data from the connected attack surface entirely. Not to defend it better in place. That separation now exists, is operational, and is open sourced, ready for immediate deployment.

    QPQ AG, incorporated in Switzerland, has built the Internet of Economics – an open economic resource layer, together with the tooling to operate on it. All of it is open sourced, free to use, implement, and operate. One such tool is Gajumaru Remote

    Instruction Dispatch and Serialisation – ‘GRIDS’ – the authentication and authorisation component, and the part that the Mythos announcement has made urgent.

    The mechanism is straightforward to describe, once the purpose is understood. In the current architecture, customer authentication requires credentials and authentication material – passwords, session tokens, two-factor codes, signed cookies – to transit or sit on connected systems, where they can be harvested by an attacker who reaches those systems. Under GRIDS, the credential does not sit on any connected system. A cryptographic key, held inside the hardware secure enclave of the customer’s own phone or laptop, produces a mathematical proof that the customer has authorised this specific instruction. The institution receives the proof, verifies it against the customer’s public key – the mathematical counterpart, which is useless to an attacker – and acts on it. Nothing capable of authenticating anyone is ever present on a connected system.

    GRIDS is a dead-drop signature protocol: the execution context (the connected device) and the signature context (the device holding keys) never share a direct connection.

    How it works:

    1. The connected device (terminal, computer, browser-facing interface) generates a transaction or authentication request and encodes it as a GRIDS URL or QR code.

    2. This is passed – via URL paste or optical QR scan – to the signing device. No network connection between the two contexts.

    3. The signing device decodes the request, displays what is being asked, and awaits approval.

    4. The user approves. The signing device signs cryptographically and returns the signed response via QR code or URL.

    5. The connected device receives cryptographic proof. No credentials. No private keys. No sensitive data of any kind transited the connected layer.

    At no point do private keys exist on the connected device. Not briefly, not in transit, not encrypted in transit: not at all. The key is held in the signing context and never leaves it.

    Each authentication creates a one-off cryptographic exchange between the institution and the customer’s device, open only for the duration of that specific instruction. When the instruction completes, it is gone. There is no persistent channel left behind for an attacker to find. There is no session state to hijack, no token to replay, no credential to retrieve in a subsequent breach. The attack surface that Mythos is built to exploit – the continuous presence of authentication data on connected systems – does not exist in a GRIDS flow, because the data is never placed on a connected system in the first place.

    Anthropic has confirmed that Mythos can bypass two-factor authentication (‘2FA’). A GRIDS flow has no two-factor authentication to bypass. The entire category of harvestable credentials is absent.


    There is no login. There is no password. There is no web socket exposure.

    The same architecture applies to payment authorisation, to staff authentication into internal systems, to inter-institution messaging, to any interaction that currently depends on credentials being transmitted or stored. The institution’s connected systems hold public keys, delivery records, audit trails – none of which can authenticate anyone. They hold nothing Mythos is looking for.

    No Account. No Password. No Database to Hack. This Is How Authentication Should Work.

    End of the Mythos AI Threat: No Login. No Password. No Attack Surface – GRIDS Live Demos

    GRIDS, Mythos AI, and the end of payment credentials in the public domain

    Three Stages of Implementation

    GRIDS is not a single product. It is an architectural protocol with a staged implementation path. Each stage addresses the remaining trust assumption of the stage before it.

    Stage 1: Operational Now – Open Sourced

    GajuDesk (desktop, all platforms) and GajuMobile (iOS and Android, releasing Q2 2026) implement GRIDS using the device’s hardware security enclave as the signing context.

    Private keys are held in the secure enclave and never touch the broader operating system or any network-connected software layer.

    This is a categorically different security posture from any browser-based financial interface: – Zero external software dependencies. Every line of code is written in-house and open sourced and auditable. No NPM packages, no frameworks, no anonymous dependency chains of the kind exploited in the September 2025 NPM supply chain attack that compromised 18 packages with more than 2 billion combined weekly downloads. – No browser plugin environment. The wallet does not run inside a browser. –

    No web sockets, no logins, no passwords, no credential transmission of any kind.

    Stage 1 has two honest limitations. The first is that the device holding the key is itself network-connected. The secure enclave is strong – the key never leaves it and cannot be extracted by software running on the operating system – but the device sits on the internet. That is a smaller attack surface than the current architecture by orders of magnitude, since Mythos or similar AI models cannot harvest a key that they cannot reach, but it is not zero.

    The second is hardware provenance: a device manufactured under unknown conditions may carry hardware-level vulnerabilities that software inspection cannot detect.

    Stage 1 is a strong immediate answer and remains useful for everyday transactions. The cost of compromising a well-implemented secure enclave on a connected device exceeds the value of most individual transactions by orders of magnitude. Stages 2 and 3 add coverage for flows where that calculus does not hold: high-value transactions, institutional treasury, inter-bank messaging, sovereign payment infrastructure. For those flows, the next stage removes the network connection entirely.

    GajuDesk and GajuMobile – working applications that put GRIDS at the centre of their operation – are free to download and use. The GRIDS protocol is open sourced in its entirety under GPL3, auditable by anyone; any institution can implement it into its own infrastructure without any licensing cost. QPQ’s commercial offer is the integration expertise of the team that built it, and the Stage 2 and Stage 3 hardware programme.

    Stage 2: GRIDS Hardware Wallet – In Development

    A dedicated, air-gapped signing device whose sole function is to hold keys and execute cryptographic signing operations. It has no network connection of any kind: no Wi-Fi, no Bluetooth, no NFC, no cellular radio. The only communication channel is optical – QR codes displayed on its screen and read by its camera.

    The connected device never has the keys. Every category of attack that depends on keys being present on a networked device – NPM supply chain attacks, browser exploitation, OS vulnerabilities, Mythos-class systematic scanning – is structurally eliminated. There is nothing to find because the keys are not there.

    This stage is in development, dependent on Series A funding which QPQ is currently raising. Institutions wishing to accelerate this stage through partnership or advance commitment are invited to engage directly.

    Stage 3: Full QPQ Hardware Stack – Sovereign Deployment

    This is the stage most directly relevant to central banks and sovereign institutions. Stage 3 eliminates the remaining trust assumption of Stage 2: hardware provenance.

    Stage 2 trusts that the GRIDS hardware wallet is manufactured without compromise.

    Stage 3 addresses this by manufacturing both the signing device and, in partnership with sovereign actors, the connected devices within auditable, controlled facilities.

    QPQ plans to establish global GRIDS device fabrication facilities in Switzerland and Japan – jurisdictions chosen for their regulatory stability, manufacturing capability, and alignment with the institutions QPQ serves. These facilities will be open to audit and inspection by any sovereign partner. The signing devices produced will have fully verified component-to-assembly manufacturing chains. No black-box components. No unverifiable supply chains.

    For sovereign partners who want the capability in their own hands rather than purchased from ours, QPQ is open to establishing fabrication facilities within partner jurisdictions, including full technology transfer.

    For a central bank seeking to protect national payment infrastructure, the full stack means:

    • Signing devices manufactured in a facility you can audit, in a jurisdiction you trust

    • A GRIDS protocol you can inspect, verify, and deploy on your terms

    • Connected devices (terminals, mobile) whose manufacturing chain is verified to the same standard

    Two Paths

    QPQ has a commercial interest, and has stated it: Stage 1 open source and free; Stage 2 and Stage 3 hardware as the paid programme. That is the shape of our commercial offer.

    The cybersecurity industry framework has its own commercial shape and does not state it. Its lead author has their own AI security tool recommended by name in the document, without disclosure. Training organisations, venture funds invested in security companies, and vendors of the specific products the document recommends are represented across the contributor list.

    The more important difference is what each path resolves. The framework’s path buys time. Each additional investment in defence postpones the point at which a Mythos-class capability reaches a credential it can harvest, but none of the investment removes the credential from the place it can be harvested. The question the framework does not answer is where the spending ends, and what the institution is left with when it does.

    Every cybersecurity budget that has risen for thirty years has been paying to defer an outcome the architecture makes inevitable. At machine speed against an attack surface that grows rather than shrinks, deferral has a shelf life.

    The architectural path has an end state. Once sensitive economic data is no longer on the connected attack surface, the attacker has nothing to harvest and the defensive cost it incurred can be recovered. The institution is not buying more time, it is removing the risk.

    The difference between QPQ’s position and the cybersecurity industry framework is not that one is commercial and the other is not. It is that one clearly defines its commercial interest, provides a free option with no compulsion to pay for anything, and actually solves the problem.

    The Supervisory Question

    “Adequate” security under every major prudential framework has meant adequate defence of credentials on connected systems, because there was nowhere else to put them. There is now. The question that follows is whether the standard should continue to mean what it has meant, or whether architectural removal of credentials from the connected attack surface should become part of what adequate protection requires.

    The regulated population has been moving in this direction for a decade – tokenisation, data minimisation, zero-trust, secure-enclave credentials – and GRIDS is the completion of that direction rather than a deviation from it. The consequence for supervised firms would be significant. Cybersecurity budgets that have risen indefinitely to defend data on connected systems would reduce, because the attack surface those budgets defend would no longer exist in GRIDS flows. The security posture of the regulated estate would transform, because compromise would no longer depend on the next patch cycle outpacing the next exploit.

    It is a question for the supervisory community, not for us. We have set out the diagnosis and the architecture as honestly as we can. The standard-setting is yours.

    What We Are Proposing

    Immediate:

    A 15-20 minute live demonstration, on your own machine or ours. Download GajuDesk from gajumining.com/downloads; we will send installation instructions and a mining licence so you can log in yourself during the session. If local installation is precluded by policy, we screen share our own live operations.

    Near term: 

    QPQ will work with any central bank, government agency, and related regulated firms to implement Stage 1 GRIDS across institutional interfaces – authentication, payment authorisation, inter-institutional communication. The protocol is open source. The cost is implementation time and any specific customisation, not licensing.

    Medium term: 

    QPQ will accelerate Stage 2 hardware wallet development in partnership with institutions that commit to the programme. A sovereign institution’s commitment to deploy GRIDS hardware wallets across a defined user base changes the manufacturing economics and accelerates the timeline.

    Long term: 

    QPQ is seeking sovereign partners for Stage 3 fabrication facilities. This is the Internet of Economics at institutional scale: national economic infrastructure in which sensitive financial data never touches the internet-connected layer, manufactured in a jurisdiction whose integrity can be assured.

    Technical Summary

    ▶ Full Technical Reference: Un-White Paper – Section VIII: Security Architecture

    qpq.swiss · gajumaru.io · gajumining.com

  • Killing the Whale Subsidy: Why A2P State Channels are the Only Path to Provider Profitability

    Killing the Whale Subsidy: Why A2P State Channels are the Only Path to Provider Profitability

    The current unit economics of online services are broken. Whether you are providing raw compute, AI inference, or streaming media, you are likely trapped in a losing investment cycle: burning venture capital to subsidize a sea of free-tier users, while praying a few enterprise whales overpay enough to keep the lights on.

    The culprit isn’t the service, it’s the tyranny of payment overhead. We have, as an industry, normalized this to such a degree that the problem has become invisible. When credit card fees and administrative friction make it impossible to charge less than $10, you can’t capture the massive, granular demand of the emerging agentic economy.

    Enter A2P (Agent-to-Provider) micropayments via Gajumaru State Channels.

    By orchestrating Gajumaru’s state channel implementation, we are enabling a radical shift from SaaS subscriptions to pure utility billing. This isn’t just a technical upgrade; it’s a business model revolution for providers:

    • Sub-Cent Settlement: Stop losing 30 cents + 3% to processors. State channels allow agents to pay providers for every single token, frame, or CPU cycle in real-time, with near-zero transaction costs.
    • The End of Onboarding Friction: Real users, and the agents they deploy, aren’t afraid of spending pennies. They are afraid of $20/month commitments for services they use sporadically.
    • Instant Liquidity: Instead of waiting 30 days for a payout cycle, providers see value flow into their channels as the service is rendered.
    • From Streaming to Scaling: This model is the holy grail for high-bandwidth services like streaming, where the cost-per-user can finally be mapped 1:1 to revenue-per-second.

    For providers, the message is clear: Stop waiting for the next VC round to cover your growth metrics. By adopting A2P orchestration, you can finally move to a Pay-as-you-Flow model that turns every interaction into immediate, granular revenue.

  • GajuPay: the answer to the broken multi-billion dollar payment solutions industry

    GajuPay: the answer to the broken multi-billion dollar payment solutions industry

    The global payment processing solutions market is estimated at USD 47.61 billion in 2022, and projected to hit USD 139.90 billion by 2030, at a CAGR of 14.5%. Despite a booming industry, the businesses it supposedly serves are left with little profit, if any – some may even operate at a loss. 

    “When a foreign tourist uses a credit card issued in their home country to make a 10,000 yen purchase at a Japanese shop or restaurant, the credit card processing fee typically ranges between 1% and 3%, depending on the transaction volume. For simplicity, let’s consider a fee of 1.99% for a large-scale store, which would result in a 190 yen income for the card company. However, the issue arises with subsequent costs — Yamaoka explains that these companies must pay various fees, including about 10 yen for domestic system operations and 180 yen in interchange fees to the overseas card issuer. Additionally, they pay around 80 yen to international brands like Visa and Mastercard for the use of global settlement infrastructure. As a result, the card company ends up with a deficit of about 70 to 80 yen per transaction. This explains why the more foreign tourists use their cards, the deeper the losses for Japanese card companies.”

    News on Japan

    It’s a multi-billion dollar mega-market whose patrons deserve much better than the limited options they’re currently restricted to. And this is what GajuPay was created for.  

    GajuPay is a point-of-sale payment processor for merchants interacting with Gajus via GajuMobile. Through GajuPay, Gajumaru opens the door to transition the real global economy to operating on-chain.

    It’s one of the tools we’ve lined up to bring the benefits of blockchain technology to real-world business – as in actual, real-life, practical use. GajuPay would enable shop owners to integrate digital payments with no upfront cost and minimal effort, and accept payments with lower operating costs, making it worthwhile for even small local cash-only businesses to, at the very least, give it a try.

    Understanding Real-life Business Needs 

    So how do retailers work with blockchain? How is this achieved without requiring intermediation from Visa, Mastercard, an issuing bank, a receiving institution, a payment processor and all the other services that pile on fees? How does a peer-to-peer payment get reported into their business systems?

    Despite how obvious it seems, nobody in ‘blockchain’ has ever seriously tackled the question: how does a shop actually accept on-chain payments?

    Putting to one side the joke that nothing in ‘crypto’ masquerading as blockchain is serious, the moment you try to answer that question practically – by talking to actual shop owners – you immediately collide with problems that no blockchain project has explored:

    How do you link a blockchain transaction to a real-world sales instance?
    How do you handle two registers paying to the same business account?
    How do you log the fiat-to-Gaju conversion rate (assuming that you are not operating in native Gajus) at the moment of sale, which is a legal reporting requirement in most jurisdictions?
    How do you issue refunds when the cashier doesn’t control the disbursing account?
    How do you prevent a malicious actor from logging out the cashier and logging in their own “shop” to steal funds?

    These are not exotic edge cases. They smack you straight in the face the moment you move from “wouldn’t it be cool if shops accepted crypto” to “here’s how you actually do it.”

    GajuPay is our solution.

    Beyond Payments–Accounting and Compliance

    Because GajuPay enables direct transactions without the need for multiple intermediaries in between, transaction fees are consistently lower than other digital payment solutions. That on its own warrants serious consideration by any business that accepts digital payments. But GajuPay goes beyond this basic proposition. 

    Built into the GajuPay system is an automated accounting, reporting, and data export utility which simplifies the problem of tracking Gaju payments in fiat denominations and vice versa – all of which assist with tax reporting and compliance for businesses. 

    Real-world accounting occurs off-chain – because the authorities to which businesses submit compliance requirements currently do not operate on-chain, but in traditional, or perhaps hybrid online-offline offices. And what they require is quite a handful of paperwork in the physical world.

    A shop needs to track which sales session belongs to which cashier, route payments to the correct accounts, log exchange rates for tax compliance, match incoming transactions to specific sales instances, handle refunds through proper authorization chains, and export all of this in formats that accounting software and spreadsheets can interpret.

    None of this is on-chain. The blockchain handles the payment. Everything else–the orchestration that makes payments useful to an actual business–requires backend infrastructure derived from deep domain expertise. 

    GajuPay provides that backend: payment facilitation and reporting software for on-chain commerce. It’s essentially what Stripe started as, before Stripe became a financial services conglomerate.

    The Evolution Path

    GajuPay follows the same evolution that made Stripe successful: start with the simplest possible integration, then expand as merchants grow.

    Stage 1: Web Portal (MVP)

    The vanilla version handles everything within a web page. The merchant signs up, we host their data, and the immediate problem is solved without them deploying anything. Basic features out of the box: sales tracking, transaction matching, exchange rate logging, receipt generation, accounting exports.

    Free to get started, fees are levied on throughputs, no complicated service tiers, no arbitrary thresholds. It scales smoothly from a market stall doing ⽊50 per day to a retail chain doing ⽊50,000 per day.

    A basic demonstration using a PinePhone (Linux mobile) is in development to showcase how lightweight this can be. Any device with a browser becomes a point-of-sale terminal.

    The tradeoff is that their accounting data lives on our servers. For most small merchants, this is fine, actually preferable, since they don’t want to manage infrastructure. It won’t satisfy everyone – larger retailers will want to handle their own data, or at least, will want to evolve to that.

    Stage 2: Webshop Integration

    The point-of-sale use case is critical to proving the real-world utility of GajuPay as a service, but it only covers half of the commercial cases that vendors are faced with. The next step for GajuPay is to provide a set of plugins, remotely served widgets and framework tools for existing web shops to integrate with in a simple way.

    It will also be very important to publish documentation for third party developers and independent operators with the requisite technical skills to perform their own integration with the GajuPay system within their web shop.

    Stage 3: Self-Hosted Backend (SaaS Package)

    For merchants who need their accounting data in their own hands, whether for compliance, privacy, or control, we will offer a self-hosted version. They run their own backend node and interface server.

    This will require a more involved set-up and provide many more options for the retailers to implement that are specific to their needs – this is not a five-minute setup through a web portal as per the base offering. DNS configuration, server management, security responsibility, all shift to them meaning that other service providers are likely to be involved too.

    Pricing will reflect this consultative element and the different support model they choose from us, but the base fee as a percentage of throughput will remain. For businesses with IT capability and regulatory requirements that demand data sovereignty, it’s the right answer.

    Same features, same interface, different hosting model.

    Why This Matters

    Every feature merchants desperately need is also deeply annoying to implement.

    Consider refunds. 

    You can’t just “send money back”, the cashier doesn’t control the disbursing account. Someone has to authorise the refund. That means refund queues: a mechanism for cashiers to request refunds that get approved by account holders. This distinction between “I need to refund this customer” and “I have authority to disburse from this account” is not obvious until you try to build it.

    Consider security. 

    A phone or tablet sitting at the front of a shop is an attack surface. Keys on that device can be captured. A malicious cashier could switch the payment destination to their own account. A malicious customer could switch the screen while the cashier isn’t looking. A random person could log out the cashier and log a fake shop in. These attacks happen with existing point-of-sale systems.

    GajuPay needs visual cues confirming the receiving account is legitimate, isolation of risk so compromising a front-of-shop device doesn’t compromise the business, and indirection of authorities so cashiers can operate without holding keys that could empty the business account.

    Consider multi-register reconciliation. 

    If a shop has two registers but one receiving account, how does each cashier know which incoming transaction corresponds to their current sale? You can’t tell from the blockchain alone, you don’t know the sender’s address before receiving the transaction. The backend has to track expected transactions per register and match them as they arrive.

    Addressing these problems are not optional to deliver a solution for retailers. Doing so makes the difference between an idea and a product.

    GajuPay will deliver that.

    Know of any businesses that can benefit from GajuPay?

    GajuPay is set to launch this year in tandem with GajuMobile

    We would happily help onboard new businesses, and reward you for the referral!
    We have an incentive system for people who help expand the Gajumaru ecosystem. Don’t hesitate to reach out–we’d love to hear from you. Send a message to partners@qpq.swiss

    More information on GajuPay and other upcoming products will be published as we approach launch. You can also subscribe to the newsletter to stay updated on developments within the Gajumaru ecosystem.

  • The Gajumaru Un-white Paper is Published

    The Gajumaru Un-white Paper is Published

    Learn more about the story behind, and the vision ahead for Gajumaru blockchain.

  • Gajumaru Wallets: from Desktop to Mobile

    Gajumaru Wallets: from Desktop to Mobile

    In 2025, we launched GajuDesk. This year, we’re going mobile. 
    Here is an overview of GajuDesk, and a brief intro to GajuMobile.

    GajuDesk

    GajuDesk is a cross-platform, open-source desktop program for interacting with the Gajumaru blockchain system. Its primary features are:

    • Management of accounts
    • Management of wallets (collections of accounts)
    • Generating and submitting spend transactions
    • Retrieving and signing transaction data via the GRIDS protocol
    • Retrieving and signing message data via the GRIDS protocol (S3O)
    • Development and deployment of Gajumaru contracts
    • Making calls and dry-runs to on-chain contracts

    Basic Wallet Features

    The main screen for GajuDesk is a simple wallet manager which lists the accounts that are in the wallet, a balance displayed for the currently selected wallet, and options for account management (create, recover, show mnemonic, etc), sending money, entering a GRIDS URL, and opening the default browser to the currently selected account’s explorer page

    GRIDS

    The “GRIDS URL” button opens a text input field where a URL can be pasted. The GRIDS URL schema encodes a series of action requests for GajuDesk, such a requesting a text message or binary signature (useful for logging in via S3O or document authentication), generating a “spend transaction” (sending funds from one account to another), or signing a transaction request such as a contract call.

    The most important part of this feature is that GRIDS allows isolation of the signature context from any other application context. It also makes it easy to communicate URLs either as text or as QR codes that can be read with a digital camera. This way a game, web shop or social media application can be running in a browser but the secret key required for signing a transaction related to it can be isolated completely from the browser runtime, or even be restricted to a completely separate device. You could be shopping on a tablet or notebook but sign a transaction on a different computer that you configure to be a better, more secure custodian of your secret account keys.

    All the signature device requires is knowledge of the relevant GRIDS URL.

    Dependency Management

    In the course of developing various wallets, it became clear that the execution environment, code supply chain, and management strategy for various wallet code bases did not meet our requirements, so GajuDesk has been built from scratch without external dependencies.

    Developer Features

    An additional and important feature set lies behind the “function” button. This button opens a separate interface window which is for developing, deploying and interacting with Gajumaru smart contracts.

    Contracts are deployed to the chain along with their source code by default, so contract source can also be loaded from the chain. A call interface is generated for each “entry” function exported from a deployed contract, and can be executed as a full contract call that is committed to the chain, or as a “dry run” which is executed on the receiving node but does not actually update the state of the chain (convenient for querying contract interfaces that are read-only without spending gas).

    This is by far the most convenient out-of-the-box tooling we have ever encountered for developing and interacting with smart contracts, and Sophia is by far the best smart contract language we have surveyed.

    GajuMobile

    GajuMobile is a mobile application for Android and iPhone. It acts as an account manager, wallet utility (sending/receiving funds), and general signature device via the GRIDS protocol.

    For most people GajuMobile will be the primary way they interact with Gajumaru chains and apps backed by the Gajumaru blockchain system. It is also the most convenient and secure login device, as your key management environment runs within your phone, completely isolated from your notebook, desktop or tablet.

    Just like with GajuDesk, the mobile environment and libraries that QPQ encountered were assessed to be insufficient for our needs, so GajuMobile has been developed from scratch, with no external dependencies other than the core libraries provided by the Android and iOS platforms.

    More info on GajuMobile will be coming out shortly. If you want to know more about what’s coming up from QPQ AG for Gajumaru blockchain, check out this post.

    If you’re interested in building on Gajumaru, using any of the products, or getting involved in any other way, feel free to reach out to developer@gajumaru.io