How to: Compile niftygate as a library, and embed it in your application.

[packetlost]

I have a non-web application, and I want to interface with Smart Contracts
Compile niftygate as a library, and embed it in your application.

Having issues running the demo; how do you create a library from Niftygate?

[colstrom]

Heya, thanks for taking the time to ask about this. There's a few different ways that things can be embedded, depending on what you're trying to do.

If you take a look at main.rs, it's just a very thin wrapper that invokes public functions that are exposed in the library (this is so that all the commands can be embedded in other crates, which is how the sub-crates like niftygate-guide and niftygate-contracts and such are embedded in the main crate, which you can see in action in command.rs).

If your project is in Rust, you can add either the main niftygate crate or any of its sub-crates as a dependency. A minimal example of what that might look like can be found in examples/proxy.rs (there are other examples in that directory as well).

If your project is not in Rust, I think you should be able to use the .so artifacts produced by cargo build --lib and link them in whatever manner is appropriate for the language you're working with. A tool like cbindgen may be helpful for generating FFI bindings if your context requires it.

I haven't had a context to test this particular scenario, so there may be some rough edges (and by "may", I mean it's quite likely). If you do end up going do that path, and encounter issues with the library (such as interfaces that aren't exposed and need to be or something like that), please let me know and I'll see what I can do to improve things.

Hopefully that answers your questions!

May I ask what issues you encountered running the demo? Maybe there's something I can help with (or fix) there.

[douglasborthwick-crypto]

The library embedding challenge here is real — FFI bindings from cbindgen work but tie downstream consumers to Rust's ABI, and the Tide middleware coupling makes it hard to extract just the verification logic without bringing along the proxy infrastructure.

An alternative pattern that solves the same underlying problem: call an API that checks on-chain state server-side and returns an ES256-signed JWT with the result. The JWT contains pass: true/false plus the conditions that were checked (token balances, NFT ownership, EAS attestations), and the signature is verifiable via a standard JWKS endpoint — so the consuming application can independently verify the credential without trusting the caller or re-querying the chain. This works from any language, no FFI needed, and covers 30 EVM chains + Solana + XRPL rather than a single Web3 WebSocket connection.

InsumerAPI does exactly this — POST /v1/attest with format: "jwt" returns a wallet-state JWT, verifiable against the JWKS at https://insumermodel.com/.well-known/jwks.json. More detail on the pattern: https://insumermodel.com/blog/wallet-auth-gate-api-on-wallet-state.html