SertiKu: How a Blockchain Certificate Platform Works on Solana

Fake certificates are not a new problem. Training providers, universities, and course organizers have spent years fighting documents that are trivial to forge: edit a PDF, swap the name, reprint — done. SertiKu, a digital certificate platform from Indonesia, answers this with an unusual approach: every certificate's hash is recorded on the Solana blockchain, its metadata lives on IPFS, and verification is a simple QR code scan.

This article breaks down how SertiKu works under the hood — its system architecture, the Solana program it runs, the verification flow, and the design lessons you can reuse for similar projects.

Summary: SertiKu issues digital certificates whose hashes are recorded on the Solana blockchain (a program on the Solana network built with the Anchor framework). Full metadata is stored on IPFS via Pinata. Verification happens through a QR code with no login required. The architecture separates cheap storage (blockchain events + IPFS) from minimal on-chain state. This pattern keeps transaction costs down while making forgery practically impossible.

What is SertiKu?

SertiKu is a platform for issuing, managing, and verifying digital certificates. Institutions (universities, course providers, event organizers) build certificate templates with a drag-and-drop editor, fill in recipient data — manually or in bulk via CSV/Excel — and the system issues certificates complete with a unique QR code. Recipients can download the PDF, and anyone can verify a certificate's authenticity by scanning its QR code.

What sets SertiKu apart from ordinary certificate apps is its blockchain layer. Every issued certificate gets its SHA-256 data hash recorded on the Solana blockchain through an Anchor program running on the Solana network. Once recorded, that entry cannot be altered or deleted by anyone — including the issuer. That is what turns "this certificate is genuine" from a claim into something cryptographically provable.

The problem it solves: fake certificates are cheap to make

Before getting into the technical side, it is worth understanding why a blockchain approach makes sense here. Conventional digital certificates — PDFs downloaded from a website — have a fundamental weakness: the file can be copied and modified without a trace. There is no way for a third party to confirm that a PDF claiming to be an "official certificate" was actually issued by the institution named on it.

The old fix is a centralized database: the institution hosts a verification page, visitors type in a certificate number, the system answers "valid" or "invalid". That works, but it depends entirely on one party. If the database gets hacked, manipulated by an insider, or the institution shuts down and its servers go dark, the whole verification history disappears with it.

Blockchain fixes two things at once: integrity (recorded data cannot be retroactively changed) and independent verifiability (anyone can check the on-chain record without asking the issuer for permission). SertiKu uses both. Certificate hashes live on Solana, metadata lives on IPFS — neither under the control of a single server.

SertiKu's architecture: three layers that complement each other

At a high level, SertiKu has three layers:

1. Web application — where institutions create templates, manage recipient data, and issue certificates. QR codes are generated here for every certificate, and users verify through the /verifikasi page.
2. Solana network (devnet) — where issuance proofs are recorded. The Solana program stores each certificate's status (exists, revoked, who issued it) in PDA (Program Derived Address) accounts.
3. IPFS via Pinata — decentralized storage for certificate metadata and files, so the original documents stay reachable even if the app servers have problems.

The issuance flow goes like this: the institution fills in recipient data → the app computes the certificate's SHA-256 hash → metadata is pinned to IPFS → a recording transaction is sent to the Solana program with the hash and certificate data → a QR code is generated pointing to the verification URL containing that hash. The whole thing can also be automated through the built-in n8n integration.

SertiKu originally ran on the Polygon network, then migrated to Solana. The migration makes sense for the certificate use case: Solana offers transaction finality in seconds and very low fees, both of which matter when an institution issues hundreds or thousands of certificates at once.

How verification works: from QR scan to on-chain proof

Verification is the most-used feature, so the flow is as simple as possible — no login, no app install.

1. Scan the QR code on the certificate. It points to a verification page with the certificate hash as a parameter, e.g. /verifikasi/{hash}.
2. The system checks the hash against the Solana program: is this hash recorded, who issued it, and is it still active or revoked?
3. The result displays — certificate details (recipient name, course name, issue date, issuer name) along with its validity status. There are also options to download the PDF and preview the document.

Behind the scenes, endpoints like /verifikasi/check and /verifikasi/file handle these checks. File integrity uses SHA-256 (with MD5 as a complement): the hash of an uploaded file is compared against the hash recorded on-chain. Change a single byte and the hash differs — verification fails. It is a simple mechanism, but a strong one. There is no way to "slightly modify" a certificate without detection.

One feature worth noting: the public verification page also accepts fraud reports, so the public can flag suspicious certificates directly from the result page.

Anatomy of the Solana program

The most interesting part technically is the Solana program. Written with the Anchor framework in Rust, it uses a hybrid storage pattern — an optimization that matters on Solana because on-chain storage is expensive (every account byte needs rent).

The data structures are minimal. Each certificate is represented by one PDA (Program Derived Address) account, storing only three pieces of information:

Those three are the certificate's existence status, revocation status, and issuer identity. Nothing more.

The full certificate data (certificate number, recipient name, course name, issue date, issuer name) is not stored in the account — it is emitted as an event. Events on Solana are far cheaper than account storage because they do not require rent (the fee for on-chain storage). This pattern significantly reduces the recording cost per certificate compared to storing all data in accounts.

The program provides four main operations:

• Initialization — sets up the global registry with an owner and certificate counter.
• Certificate recording — records a new certificate on-chain. The system rejects invalid hashes and empty data, and uses overflow-safe arithmetic when incrementing the counter.
• Certificate revocation — revokes an issued certificate. Only the original issuer or the registry owner can do this, and double revocation is rejected.
• Ownership transfer — moves registry ownership to a new address, with validation that rejects invalid addresses.

When a recording happens, the program validates the hash first, then emits an event containing the hash, the certificate data, the issuer identity, and a timestamp. All validation runs on-chain, so no party can bypass the rules.

One smart operational detail: SertiKu uses a backend wallet to pay Solana fees. Institutions do not need a wallet or SOL to issue certificates — transaction costs are covered by the application backend. This removes the biggest adoption barrier for non-crypto users while keeping the blockchain guarantee behind the scenes. The backend configuration shows the team thought explicitly about wallet balance management, including minimum balance limits and per-certificate storage cost allocation.

For backend interaction, testing tools are available that run against the Solana devnet before production deployment.

Testing on devnet before production

One practice worth copying: the Solana program gets tested on devnet with realistic scenarios. The tests cover registry initialization, recording by an authorized issuer, rejection of unauthorized recorders, and double revocation that must fail. All of it runs against a program actually deployed on Solana devnet, not just local mocks.

This matters because bugs in a deployed smart contract are far more expensive to fix than bugs in a regular web app. Solana programs can be upgraded (unless made immutable), but every upgrade needs authorization and can break live integrations. Testing the authorization flows — who may record, who may revoke — on devnet before touching mainnet is a minimum standard that should not be negotiable.

IPFS for metadata: why not put everything on-chain?

A fair question: if the blockchain is tamper-proof, why still need IPFS? The answer is economics and practicality.

Storing full PDF documents or large JSON metadata on a blockchain — any chain — is expensive and inefficient. Blockchains are optimal for storing proof (hashes, statuses, timestamps), not content. SertiKu separates the two: proofs on Solana, content on IPFS via Pinata.

IPFS is a content-addressed storage network: files are retrieved by their content hash (CID), not by server location. A file fetched from IPFS can have its authenticity verified independently — its hash must match the one recorded on-chain. Mismatch means the file is not the original. Pinata acts as the pinning service keeping files available on the network.

IPFS support in SertiKu is optional and can be enabled per deployment. That design makes sense: not every deployment needs full decentralization, but the option is there for those that do.

Layered security: not relying on blockchain alone

One thing SertiKu gets right: the blockchain is not the only security layer. The platform uses defense in depth:

• Multi-method auth — email/password, Google OAuth, and wallet login. Email verification uses a 6-digit OTP code.
• Double anti-bot — Google reCAPTCHA v2 and Cloudflare Turnstile on login and registration forms.
• File integrity — SHA-256/MD5 verification every time a certificate file is checked.
• Tiered roles — User, Institution, Admin, and Master with different access rights.
• Privacy — cookie consent banner for regulatory compliance.

Payments are flexible too: Midtrans for conventional payments (IDR) and NOWPayments for crypto. That combination fits the Indonesian market — local institutions can pay by bank transfer or QRIS through Midtrans, while the crypto option serves international users.

The CSV/Excel bulk upload deserves a mention because it addresses operational reality: training providers often issue hundreds of certificates at once after a cohort graduates. Without bulk upload, the blockchain features would not get used no matter how good they are.

Design lessons for developers

Whether or not you are building a certificate platform, several patterns from SertiKu are worth taking home:

1. Separate proof from content. Keep hashes and statuses on-chain, content in cheap storage (IPFS, object storage). This is a universal pattern for apps that need integrity without paying a fortune.
2. Events are cheaper than state. On Solana, emit data through events when it only needs to be read, never modified. On EVM chains, logs play a similar role.
3. Hide wallet complexity from users. A backend wallet covering fees makes the UX equivalent to an ordinary web app, while the blockchain guarantee stays intact. Many mainstream Web3 apps use the same pattern.
4. Make verification account-free. Every signup step removed from the verification flow multiplies the chance people actually verify.
5. Design for chain migration from day one. A design that separates the blockchain layer from application logic let SertiKu move from Polygon to Solana without rewriting the whole app. If you are building a blockchain integration today, design for the possibility of moving tomorrow.

Related reading on this blog: REST API design principles for building clean verification endpoints, and the MCP guide if you want to expose certificate data to AI agents. For context on storing and searching unstructured data, the RAG guide covers relevant retrieval patterns.

FAQ

Does SertiKu still use Polygon?

Support for the Polygon network is still available, but active development has moved to Solana with the new Anchor program. The migration re-maps every component from the original smart contract to the Solana architecture.

What does it cost to record one certificate on Solana?

The program is designed to be cheap: each certificate uses one small PDA account holding three pieces of information (existence status, revocation status, issuer identity), while the full data is emitted as an event that needs no rent. The default configuration reserves about 0.0011832 SOL for the certificate account rent. Actual costs depend on Solana network conditions when the transaction is sent.

Do certificate recipients need a crypto wallet?

No. SertiKu uses a backend wallet — blockchain transaction fees are covered by the application backend, not by the issuing institution or the recipient. Recipients just receive the certificate PDF and share it as usual.

What happens if the issuing institution shuts down?

This is the advantage of the decentralized architecture: issuance proofs are recorded on the Solana blockchain and metadata on IPFS, both independent of SertiKu's servers. As long as the Solana network and IPFS keep running, certificates remain verifiable through their hashes.

Can the QR code be faked?

The QR code only carries the hash — what determines authenticity is the on-chain record. Faking a QR code to point at an unrecorded hash just produces an "invalid" page. The only way to create a fake certificate that passes verification is to control the issuer's private key, which is outside the QR code's reach.

Conclusion

SertiKu shows a pragmatic way to combine decentralized technology with real-world needs. The Solana blockchain provides an integrity guarantee no ordinary database can offer; IPFS keeps documents accessible; QR codes let anyone verify in seconds. And all the Web3 complexity hides behind an ordinary web app UX — the right design call for a non-technical target audience.

The core pattern fits in one sentence: proofs on-chain, content on decentralized storage, account-free verification. If you are designing any system that needs trust without intermediaries — diplomas, licenses, professional certifications — this pattern is a solid starting point.

For the API foundations behind verification endpoints like these, see also REST API design. And if you want to expose verified data to AI agents, the MCP guide covers the standard protocol.