Here’s a small experiment that I suggest running this week during Ipe Village: [2603 Grant Proposal] Rootstock Buildathon Track and Sponsorship at Ipê Village 2026 - #51 by Axia
TL;DR create a lightweight builder-follow up playbook to start helping builders with GTM and post-hackathon support.
Hello team! We are back with our weekly updates for next milestone.
These past two weeks we discussed the implementation plan, we factor it in our sprints, and we started the work on our first task in this milestone.
Task Backend API adapted to interact with Rootstock mainnet
Task is completed. This is backend only, so no “touch points” yet for the user. Next update we hope to have the issuer website released. And with some luck, the mobiles apps tested too.
The production backend (identity-web3-node-prod) is running with Rootstock mainnet configuration, connected to the verified mainnet contract, and deployable through the GitHub Actions + OIDC + SSM pipeline. Mainnet values are applied and validated in operations/runbook docs, and client integration guidance has been updated accordingly.
WEB3_CHAIN_ID=30WEB3_RPC_URL=https://public-node.rsk.coWEB3_CONTRACT_ADDRESS=0xCc8dfB72BA18f6cBd626A1e609F8864707d77EdFidentity-web3-node-prod) was created from the dev AMI and promoted for mainnet use.sbweb3-prod*) is connected to AWS through OIDC.Next week we plan to report on next tasks (work is in progress, but not complete).
As always, questions and comments are welcome.
Regards!
Thank you so much for the updates while you work through M3 deliverables, @mrmtech . And appreciate the pro-active communiciations!
We do have some clarification questions:
In the previous milestone, it was explicitly requested that the team increase the invariant testing depth before going live on Mainnet.
You noted in your report that you were adding English language support based on a validator request.
Thanks @mrmtech. Backend API on Rootstock mainnet is a meaningful milestone for M3.
Even with the “backend only” framing, we want to flag what’s externally observable so far. The mainnet contract is deployed and source-verified on Blockscout, the ABI matches the audited testnet contract, and the same-day verification turnaround is a good sign of release hygiene. What we can’t yet observe is the backend half of the integration: the contract’s transaction history shows only the deployment itself, no setManifestCid calls, and the deploy pipeline is described in narrative without a public artifact link.
Could you share one externally-verifiable signal that the backend is exercising the mainnet contract? A single admin-initiated setManifestCid from the prod backend, a deploy run link, or a health-check artifact would close the gap between “contract on mainnet” and “backend integrated with mainnet.”
Hello @DAOstar_gov , @Tane and collective community, here our weekly update.
This week we achieved
We uploaded our apks to the same folder we used last time, so feel free to download and test them.
They are using mainnet now, and they have been translated to english.
Issuer webiste is live at
Also english translated.
What we didn’t get enough time to complete is issuer hardening. We moved that to next week.
And thank you for your questions and comments. Let us address them.
Invariant testing depth: We uploaded it to the repo just now.
identity/contracts/audit/DidManifestRegistry-FuzzInvariant-Verification-Report.md
It includes purpose, scope (local Foundry vs live Mainnet), config table, reproduce commands (forge test / npm run test:foundry), 14/14 pass summary, approximate 259k execution headline, pointers to evidence files, and Foundry 1.5.1-stable version info.
identity/contracts/audit/forge-test-evidence-summary.txt
Plain-text listing: exit code 0, every PASS line for fuzz + invariants, runs: 500, calls: 50000, reverts: 0 for each invariant, and aggregate 14 passed, 0 failed. Suitable when reviewers do not want markdown.
identity/contracts/audit/forge-test-evidence-latest.txt now points at the two files above (a raw PowerShell redirect had encoding issues, so we avoid claiming that file is a verbatim console dump).
Question about english translation. Yes, everything will be added english support. The apks and website are added now, we’ll work on the other items to finish the milestone.
Question about externally verifiable transactions. Thanks for this question! We rotated our owner keys, and that caused a problem. The good news is that this let us test our retry mechanism, after we changed the owner of the mainnet contract to match the new one, the transactions posted correctly.
Here are the values of the transaction we used, feel free to check in the explorer the same.
did:dht:nowrosg9rwq1ddi1m9cufa11zkm9wgw3g4mm46u3xukoazw5ygfyQmWYgu4LbXrNmd1Vifr3WdEVybDvuL8tW8dFZmfaSi61SW0xd5a3275488ad3160ca647774a5a2d88004a711371b39f123cdfbec7255582bfb0x003c9cc96d0eefefe468e484f407d5136830cdf2601fdc7cad2ede7e4864300dWe’ll keep working and if everything goes well, we may complete our tasks next week!
Questions and comments are welcome as always
Regards!
Thank you so much, @mrmtech for this progress report, it’s encouraging to see the progress you’ve completed, particularly the successful stress test against the Mainnet contract. Increasing the invariant testing depth to 500 runs and 50,000 calls provides the level of security assurance we expect for production-grade infrastructure on Rootstock.
Before you conclude Milestone 3 (and we would love to see the same excellent standards of your M2 detailed completion report), we would request clarification on a few final points:
Issuer Hardening: You noted that “Issuer Hardening” has been moved to next week. Could you define the specific security features this will include (e.g., MFA or RBAC) to ensure unauthorized parties cannot issue credentials via the portal?
Mainnet Monitoring & Alerting: In M2, the team verified the Tenderly alert configuration via screenshots. Now that the Mainnet contract is live, could you share a similar confirmation showing the active Alert Rules for the production environment? Additionally, has the team successfully transitioned these notifications to a professional production channel (e.g., Slack or webhooks) as discussed during the previous milestone?
Documentation & Localization: It is great to see English support added to the apps. Just for clarification, since we were not sure you meant both Spanish & English language in your comment above. Can you clarify that for the final developer guides in M4, will these be hosted in a bilingual format to ensure the open-source reference implementation is accessible to the global Rootstock developer community?
Tks! And looking forward to the M3 report!
Hello team,
Following our commitment to regular updates on this thread, here is our Milestone 3 progress report. We consider all goals completed.
The services run on production-grade infrastructure (AWS, mainnet contract, prod issuer portal) while remaining a demo/reference implementation with no live end-user population at this time — institutions adopting the stack may use these same services (DHT, piñata, AWS), but most probably will plug in their own identity provider, token services, and operational policies.
All our code is open sources, and any institution may use it.
We are in conversations with organizations interested in testing our solution for Milestone 4
As always we are open to comments and suggestions.
Scope per post #33.
| # | Deliverable | Status | Highlights |
|---|---|---|---|
| — | Mainnet launch of the Rootstock-enabled SSI sandbox | Complete | DidManifestRegistry on Rootstock mainnet (chain 30). Prod identity API, issuer portal, and mobile production profiles wired to mainnet. |
| 1 | Backend API adapted to interact with Rootstock mainnet | Complete | Prod node on chain 30; contract 0xCc8dfB72BA18f6cBd626A1e609F8864707d77EdF. GitHub Actions → SSM deploy to identity-web3-node-prod. |
| 2 | Issuer hardening (add authentication) | Complete | Amazon Cognito + NextAuth on prod issuer portal. Session-gated UI and /api/proxy; server-only identity API key. |
| 3 | Issuer working against Rootstock mainnet | Complete | Prod issuer calls mainnet-enabled identity API. Approvals trigger Rootstock writes via Web3RegistryWorkerService. |
| 4 | Validator apps working against Rootstock (open source) | Complete | IDA-Verificador-App and IDA-Ciudadano-App production profiles on chain 30. Open-source repos on GitHub. |
| 5 | Add English language (validator request) | Complete | Spanish and English in issuer web and both mobile apps (i18n / language switcher). |
| 6 | Ensure IPFS option besides Pinata | Complete | IpfsGateway abstraction; alternatives evaluated (Filebase, Storacha, Kubo, IPFS Cluster). Report: docs/IPFS-Pinata-Replacement-Options-Report.md. |
| 7 | Infrastructure set-up for production readiness (Amazon + web2) | Complete | Prod EC2, Elastic IP, nginx/TLS, dual Amplify apps, Cognito, OIDC+SSM deploy, Tenderly on testnet and mainnet. |
| 8 | Demo credential issuance + validation flow E2E | Complete | Citizen request → issuer approval → IPFS → Rootstock write → Verifier validation. Proven on testnet in M1/M2; mainnet stack exercised in M3. |
Contract: 0xCc8dfB72BA18f6cBd626A1e609F8864707d77EdF (chain 30)
Prod API: identity node with mainnet WEB3_* configuration; smoke GET /requests → 200 on prod instance
Deploy: identity-web3-node-prod, tag-based GitHub Actions → SSM
Testnet URL: https://dev.d259s5nn01m0g8.amplifyapp.com/
Cognito user pool (prod), NextAuth, middleware route protection, custom signup/email-confirm APIs
Identity API key kept server-side (IDENTITY_API_KEY); browser uses same-origin /api/proxy only after login
APKs to test the applications working on mainnet
Issuer web: lib/i18n/en.json, es.json
Verifier + Citizen apps: react-i18next with EN/ES toggle
We documented that Pinata is not a lock-in: the backend already defines a provider-agnostic IpfsGateway interface, includes a Kubo-compatible adapter sketch, and we published a full alternatives evaluation for operators and integrators.
Full report (in repo): docs/IPFS-Pinata-Replacement-Options-Report.md
| # | Deliverable | Status | Highlights |
|---|---|---|---|
| 1 | Filebase | Paid SaaS | IPFS Pinning Service API, S3-style ops; recommended paid default for standards alignment. |
| 2 | Storacha | Paid SaaS | Managed pinning + Filecoin-backed persistence; Protocol Labs ecosystem. |
| 3 | Kubo | Self-hosted | Full control; kuboCompatibleGateway.service.ts in repo (sketch, not yet production-tested). |
| 4 | IPFS Cluster | Self-hosted | HA pinning across multiple peers; best self-hosted production pattern. |
Pinata remains the recommended option.
We migrated our alerts to mainnet.
Issuer hardening in this milestone is meant to protect the instance from abuse, and to showcase that RBAC can be implemented. GIven that each organization has its own authentication mechanisms in place, adding complexity to this instalation, at this time, yields no benefit. A production organization would typically replace or augment this with its own IdP (Azure AD, Okta, etc.) and SSO — which aligns with Milestone 4.
| Human access | Amazon Cognito User Pool (prod): email as username, email verification before use, password policy (minimum 12 characters, upper/lower/number/symbol) |
| Session | NextAuth (JWT session); unauthenticated users redirected to /login |
| Application routes | Next.js middleware (withAuth) protects all issuer pages except login and auth callbacks |
| API bridge | /api/proxy requires a valid server session before calling the identity backend |
| Backend API | NestJS ApiKeyAuthGuard on issuer endpoints; API key is server-only (IDENTITY_API_KEY), never exposed to the browser for issuance calls |
| Signup abuse | Self-service signup with email confirmation code; duplicate-account and password-policy errors surfaced to the user |
MFA: Amazon Cognito supports TOTP/SMS MFA natively. For this sandbox we prioritized email-verified accounts and strong password policy; MFA can be enforced in Cognito with one console/policy change when an institution hardens for production. We document this in IDA-Emisor-Web/docs/COGNITO_AUTH.md.
Bottom line: Unauthorized parties cannot issue credentials via the portal without passing Cognito authentication and holding a valid session; they also cannot call issuance APIs without the server-held API key. This meets the M3 “issuer hardening” intent for an alpha sandbox.
Testnet (Milestone 2): Tenderly alert rules were configured and verified with screenshots on the testnet contract (ManifestCidSet, ManifestCidDeleted, ownership transfer events).
Mainnet (Milestone 3): The same monitoring approach is applied to the production mainnet deployment:
| Item | Detail |
|------|--------|
| Contract | 0xCc8dfB72BA18f6cBd626A1e609F8864707d77EdF on Rootstock mainnet (chain 30) |
| Platform | Tenderly — contract verified, event-decoded |
| Alert rules | Parallel to testnet: CID set, CID delete, ownership transfer on DidManifestRegistry |
| Validation | Alerts active on the Tenderly project; mainnet writes from the identity backend are observable on Blockscout |
Notification channels:
| Channel | Status |
|---------|--------|
| Email | Active for sandbox operations (same pattern as M2 verification) |
| Slack / webhooks | Tenderly supports Slack, webhooks, PagerDuty, etc.; webhook destination is configured for the ops project so production incidents can route to team channels without dashboard-only monitoring |
| Institutional deploys | Operators point Tenderly (or Alchemy/Moralis equivalents) at their own Slack/on-call stack — documented in prod runbooks |
We can share mainnet alert-rule screenshots on request (same layout as M2 testnet evidence). The monitoring pattern is production-ready; channel choice is an operator preference, and webhook/Slack is supported for this deployment.
Clarification on “English support”: Yes — we mean both Spanish and English across the user-facing sandbox:
| Component | Languages |
|-----------|-----------|
| IDA-Verificador-App | Spanish + English (react-i18next, in-app switcher) |
| IDA-Ciudadano-App | Spanish + English |
| IDA-Emisor-Web | Spanish + English (I18nProvider, EN/ES toggle) |
This addresses the validator request from Milestone 1 review (issuer/verifier were previously Spanish-only).
Milestone 4 developer guides: Yes — the final comprehensive guides for developers and institutions (M4) will be published in a bilingual format (Spanish and English) so the open-source reference implementation is accessible to the global Rootstock developer community and our Latin American pilot partners. Technical docs in the repo (docs/, contract README, deployment runbooks) will follow the same EN/ES pattern where they are user-facing; API/architecture references remain English-primary with Spanish companion pages for onboarding.
Consolidated from implementation work on the prod issuer and mainnet cutover:
Cognito dev + prod pools, NextAuth, Amplify env rollout
Session-gated /api/proxy, server-only IDENTITY_API_KEY
Custom /api/auth/signup and /api/auth/confirm (Cognito Hosted UI signup workaround)
Prod issuer connected to mainnet identity API
API key rotation and alignment on prod instance
IPFS alternatives evaluation report published
| Resource | URL |
|----------|-----|
| Mainnet contract | Rootstock address details for 0xCc8dfB72BA18f6cBd626A1e609F8864707d77EdF | Blockscout |
| Issuer portal (prod) | https://main.d1fkse5la21xp8.amplifyapp.com/ |
| Issuer portal (testnet) | https://dev.d259s5nn01m0g8.amplifyapp.com/ |
| Identity repo | GitHub - Ikabott-MRM/identity: Decentralized identity for governments and organizations. · GitHub |
| Issuer web repo | GitHub - Ikabott-MRM/IDA-Emisor-Web · GitHub |
| IPFS options report | docs/IPFS-Pinata-Replacement-Options-Report.md (in identity monorepo / SSI docs) |
Regards,
mrmtech
Thanks for the M3 wrap-up, @mrmtech, and for the answers on hardening, alerts, and bilingual docs.
On the “production-grade infrastructure” framing, there is one piece that does not yet match what’s deployed. The production identity backend is reachable on the public internet at http://32.193.15.27:3000 over plain HTTP, with any origin allowed to call it and a static API key as the only authentication. The same-origin proxy in the issuer protects the legitimate user flow, but the backend itself stays directly callable from anywhere, and credential-issuance bodies traverse cleartext. Your repo already includes a TLS deployment path, and a TLS-fronted endpoint at https://api-ssi.iovf.org is already reachable in front of the same service. Could the backend exposure be addressed before the M4 proposal goes on-chain?
Two smaller items on the report:
IDA-Verificador-App or IDA-Ciudadano-App under Ikabott-MRM or IOV-Foundation. Could you share the public repo URLs?docs/IPFS-Pinata-Replacement-Options-Report.md “in repo,” but we don’t see it on either branch of Ikabott-MRM/identity or under IDA-Emisor-Web/docs/. Pending push, or a different path?Happy to be corrected if we’ve misread the deployment.
Hi @Tane thank you for pointing these items out.
We spawned a new domain so we could use a secure https connection to the backend. We recreated the apks, and replaced the ones we share before to use the new url. https://api.ssi-api.xyz is new url.
Folder with compiled apks
The actual repos for the apps have been made public at
And the ipfs document was pushed to the right folder, now visible on
Let us know if there are more questions or comments.
Regards!
Thanks for the quick turnaround, @mrmtech. The repos and the IPFS report check out on our end.
One follow-up on the new domain. When we hit https://api.ssi-api.xyz, the cert returned identifies api-ssi.iovf.org rather than the new hostname, so any client that enforces TLS validation will reject the connection on a hostname mismatch. The same SSI APKs we’d hand to a pilot user would hit this on first launch.
Could a cert covering api.ssi-api.xyz be issued before the M4 proposal goes on-chain? Happy to be corrected if we’ve misread something here.
Thank you so much, @mrmtech, for such a thorough breakdown for the M3 completion report - great job! Your level of operational detail, especially around the Amazon Cognito and NextAuth integration, alongside the IPFS alternative evaluation report, is exactly the type of detailed reporting that we are looking for, nicely done!
We also want to acknowledge this excellent work. Your original proposal only required the Issuer and Validator APKs to be tested against the Testnet for this milestone. By delivering them fully operational on Mainnet ahead of schedule, you’ve gone above and beyond your original commitments and shown great proactive development. Tk u!
We also really appreciate you taking the time to clarify the localization layout. Confirming that the sandbox apps are fully bilingual with a native EN/ES toggle directly addresses the ecosystem’s feedback. More importantly, ensuring that the upcoming M4 developer guides and deployment runbooks will be hosted in a bilingual format is fantastic! It guarantees the open-source reference implementation is genuinely accessible to both the global Rootstock community and your local Latin American pilot partners.
To wrap up this phase and complete the public audit trail, we just have one quick request:
Once those quick snapshot artifacts are added to the thread, We’re very satisfied with the technical delivery of M3 and fully support your continuation of this project for M4 funding.
Hi @Tane !
Thanks for flagging this — your observation was correct.
api.ssi-api.xyz was already resolving to our hardened production node (32.193.15.27), but nginx was still serving a Let’s Encrypt certificate issued only for api-ssi.iovf.org. That causes strict TLS clients (including mobile) to fail hostname validation.
We have now fixed this on prod by expanding the certificate SANs and reloading nginx.
Verification examples
nslookup api.ssi-api.xyz
HTTPS on the new hostname succeeds
curl -I https://api.ssi-api.xyz/
(404 at / is expected from our Nest root endpoint; the key point is TLS handshake + hostname validation now pass.)
In short, a certificate covering api.ssi-api.xyz has now been issued and deployed before M4 goes on-chain. Pilot APKs targeting https://api.ssi-api.xyz should no longer hit hostname-mismatch on first launch.
Hi @DAOstar_gov thanks for that feedback! We are hard at work with this project, its very rewarding to be noticed!
Here the alerts configured on tenderly for mainnet.
Let us know if you want to see anything else
Regards!
These look great, @mrmtech thank you so much for the quick response! Looking forward to seeing M4 roll out! Tks!
Confirmed on our end: https://api.ssi-api.xyz/ now passes TLS hostname validation cleanly. Thanks for the fast turnaround, @mrmtech. M3 looks good from our side.
@mrmtech, heads up on the new on-chain proposal. It’s labeled “M1lestone:3” and references M3 completion, but M3 was already funded and executed in April. The disbursement amount of 4,500 USDRIF also matches M4’s budget, not M3’s 4,000 USDRIF. We believe this is intended as the M4 proposal.
We’d recommend canceling this proposal if possible, or letting it be defeated, and resubmitting with the correct milestone label and description. A clean on-chain record matters for the grant’s audit trail, especially on the final milestone. cc @tamlerner
We’re ready to vote on M4 once a correctly labeled proposal is up.
Thanks for catching that, @Tane , we already voted in favor, as we are supportive of M4 funding, but missed the milestone label on the on-chain vote.
@mrmtech Thanks for the detailed M3 report and for the quick follow-up on the deployment issues that were raised. From my read, the substantive M3 scope appears to be completed: the Rootstock mainnet contract is deployed and verified, CID writes are observable on mainnet, the backend and issuer flow have been moved to mainnet, authentication has been added to the issuer portal, the mobile apps are public/configured, and the English/IPFS-related validator requests were addressed.
The one concern I see is administrative rather than technical. The updated milestone plan lists M3 at 4,000 USDRIF and M4 at 4,500 USDRIF. If the current on-chain request is labeled as Milestone 3 but requests 4,500 USDRIF, that seems to correspond to M4 funding rather than M3. For the sake of a clean grant record, I’d support correcting the milestone label/description before proceeding.
Hi @mrmtech , we are voting against on this proposal for the reasons previously highlighted by other delegates. Please apologize if this sounds overly bureaucratic and technical, but for reasons of traceability and accuracy that will allow for future verification, we believe this proposal should be deleted and a new, corrected proposal should be submitted, with the label clearly indicating that the funds proposed for release correspond to those of Milestone: 4.
We are ready to vote in favor in the corrected voting, as we understand that you have fully delivered on the committed output.
As far as I know, the on-chain proposal system only supports milestones 1–3, and does not include milestone 4.