PEP-19: The Development of PocketRS, Ongoing Client Support, and Feature-Rich Documentation


  • Author(s):
    JAMSO Financial Group, LLC . Alias: JAMSO OTC, JAMSO OTC Exchange

  • Recipient(s): Two Senior Engineers and Two Junior Developers employed by JAMSO Financial Group, LLC.

  • Category: Imbursement

  • Asking Amount: 500,000 POKT


We are currently designing a POKT client (PocketJS) in the Rust programming language called PocketRS. We aim to garner funding to finalize its design and provide active support for one calendar year.

Including a high-performance, compilable language like Rust to the Pocket Ecosystem will allow for a dynamic range of development in terms of library utilization and access to natively generated C Bindings.


Rust has a large and growing presence in the crypto community space. As such, we’re confident that the Rust community will grow into the Pocket space and utilize this service. We also feel that PocketRS will provide a foundation to further language support due to its low-level capabilities.


Pocket is a decentralized IaaS that is rapidly growing. It is not a matter of if, but instead a matter of when, that Pocket will unseat large-scale cloud infrastructure providers as the de facto IaaS of choice for crypto development.

Pocket’s technology stack is quite expansive - the team and the overarching community have put extensive work into the Pocket Core, the UI/UX experience of, and more. However, there is currently only a JavaScript and a proposed Python implementation of the client.

Having a Rust binding brings the Pocket client into the purview of systems developers and enterprise software engineers. The native bindings that Rust can generate will further language support for decades to come.


We are asking for 500,000 POKT.

PocketRS will be an open-source project in Rust for the Pocket Project. Our team will be launching the service with extensive documentation, multiple examples, and an intuitive API surface. We will also be ensuring that modifications to PocketJS will be promptly reflected in both PocketRS and its corresponding binaries. Additionally, we will be creating a community discussion group to support developers using PocketRS, PocketJS, and the proposed PyPOKT.

To achieve this, we will devote the resources of two senior engineers and two junior developers, to see this project launch. The requested funds will be transparently budgeted to fund their salaries.


Our team will be working full-time to bring the PocketRS client to market. We plan on leveraging the skills of our senior and junior development teams to launch the library within six calendar months.

From this point, we will provide maintenance and active support for new features that appear in PocketJS. Our role will become maintenance and community support for one calendar year.

The base service of POKT is to provide developers with the tools to decentralize their access to specific blockchains. Our goal is to provide an upgrade to this base service to provide enterprise support as a community resource.

Dissenting Opinions



We aim to deliver PocketRS along with C bindings within six calendar months. We will provide support for 12 calendar months.


Jamso Financial Group, LLC will be the sole contributor of PocketRS to launch. After launch - we will open support for community contribution via source control pull requests. We serve the POKT community with our OTC, JAMSO Exchange. We also contribute a range of community resources like @POKTPriceBot and the Unofficial Spanish Telegram chat for POKT.


Copyright and related rights waived via CC0.


whew That price tag!

That being said, this is a significant contribution to the ecosystem with a high level of complexity. I support this proposal.

I am in support of more detailed clients, and I think that this will be a great addition to the POKT ecosystem. Due to PyPokt not being active, I recently have started my own implementation (PocketPy), so maybe there could be some collaboration between our projects. Even though the price tag is a little heavy, I support this proposal.

Edit: On reconsideration I think that the price tag should be lowered by at least 1/3 if not more.

1 Like

With this being a partial reimbursement, what has already been done?

Could you share a technical spec of what this would be? Specifically, the list of APIs you plan to bring to PocketRS. From my understanding PocketJS in it’s current form is a rather basic SDK, and I would be interested in seeing what more abilities PockeRS would provide.

Thanks for the proposal!

That is a steep price tag relative to what we’ve seen here thus far.

How will the funds be used exactly? 500,000 POKT (let’s ay $500k to make it easier) will net you ~3-4 junior engineers or 2-3 senior engineers over the course of a year. Are that many folks going to be involved? Is there a roadmap?

I feel like more information is needed before handing out half-a-million POKT.

I’d also like to see some clauses regarding disbursement of funds in here regarding ongoing maintenance after hitting MVP or 1.0.0 status.

Hey, Shane, firstly great question. To comment on the “Partial Reimbursement” - this may be a misrepresentation of our exact understanding of the PEP format. To date - we have completed a full technical investigation on the endpoints related to querying the POKT blockchain itself. We’ve also implemented an early version of this client to suit our current needs. To make the PEP more concise - we have edited the proposal to omit the “Reimbursement” field.

In essence, regardless of this proposal’s status, we are not looking to be reimbursed for the work completed. Our main reason for this PEP is to continue work on the client to map both the features of PocketJS as well as any outstanding features of the POKT CLI.

PocketRS will be a strict superset of PocketJS. Our goal is to include the functionality of PocketJS and any remaining accesses with the Pocket Core while adding QOL features to make development more accessible. One of the features that we noted on PocketJS which we aim to expand on is documentation. We are going to provide English-native documentation that fully spans the client while providing intuitive examples to rapidly bring developers up to speed.

Thanks for the answers! This is by far the largest proposal for a development tool, so more information greatly helps :slightly_smiling_face:

A few more:

Could you release the early version of PocketRS to show what was already build? I assume it was built for your OTC business?

With full technical investigation completed, could you release a spec summary and signify the difference between what was already created and what the final PocketRS would be?

I concure with @ArtSabintsev’s requrest. A roadmap of the specific deliverables would helpful. I’m not sure if this is something that we will see frequent progress with, or if everything drops at the end of 6 months.

What would your support look like? Would this include community support in Discord with a dedicated team member? I see from your listing in the Secondary Markets page that JAMSO is community-established, but I’m not sure I know what Discord user is behind it. Any details on the support/community aspect would be great :slightly_smiling_face:

@shane & @ArtSabintsev,

Evening, all - and again, thanks for these great questions. I hope that this response will help continue our dialog on the proposal. Please forgive any delay in my sending these responses - we’re collaboratively working to best answer all questions. For convenience, I will attempt to break down our responses cleanly and concisely.

Regarding The Current Status of PocketRS

You are correct - we did design this system with our OTC in mind. The system is very much pointed toward making blockchain manipulations using the POKT token. We are 1 - 2 days away from the launch of our newest flagship product - Project BiFrost - affectionately named after Bifröst - the mythological bridge that connects Asgard with Midgard.

We will happily provide the source code in the same public organization that we have previously shared the Pocket Blockchain Network Metrics DataSet.

However, as it is solely for internal tooling, the system is frankly not going to be pretty. We designed the API surface of the early prototype of PocketRS around our specific needs. It is not - in any format - prepared to be installed by the community.

Regarding Exactly Who Is JAMSO Financial Group, LLC

We are a community-operated OTC because the founding partners of Jamso Financial Group are members of the community. However, during the course of doing business, our company has evolved into much more than a community-driven OTC - we actively collaborate with different networks and have a presence among VC firms. Additionally, for the community, we have provided a host of free resources for the sole betterment of the project.

Regarding our actual company, our financial breakdown does show the names (surnames redacted for privacy) of our employees. Additionally, we are a ‘doxxed’ company. Our Company is based in the great state of Wyoming, United States of America. Our mailing address is 32 N Gould Street Ste R, Sheridan, WY 82801. Our email is We check our mail frequently and are always available to answer an email.

To be listed as one of the few vetted OTC Exchanges at POKT, we had to provide a POKT employee with sufficient and sensitive documentation regarding our business structure and founding members. Additionally, our Co-Founder has met with and does provide consultancy work for Pocket Network, Inc.

We currently provide full-time support to the POKT community through the active management of the unofficial Spanish POKT group.

In short - if nothing else - we are transparent to who we are in this space.

What the Community Support Entails

Developers - both hobbyists and professionals - require support at times to help aid in the development process of their programs. While proficient documentation can arise from open-source, community-driven efforts, this is often organic and derived over a long time span.

What we’ve seen with POKT and the several other web3 blockchain technologies we serve is that even a rock-solid project can dissuade professionals and hobbyists from entering due to a lack of documentation. We’re up against the industry greats like Infura, Alchemy, and more, and these companies have a lot of well-written documentation.

One of the reasons we decided to proceed with this PEP is that the documentation is not there with PocketJS. Documentation, however, is not the full scope of support. Currently, Pocket provides an app builder’s channel on its official Discord Channel for community support. However, it’s not always the case that requests on this channel are answered.

We are proposing to provide enterprise-grade documentation for PocketRS and a staffed community forum (through Discord, Telegram, and through our version control system) to aid in any technical questions that a developer may have which is blocking their progress.

Regarding A Road Map

We agree that having a roadmap is an excellent way to keep the community, the DAO, and any developer who is interested in PocketRS informed on any progress. To provide this support, we have prepared a roadmap that JAMSO Financial Group, LLC will make a best-effort attempt to fulfill within the following defined timeframes:

Month 1 - Full API Surface Specification
During this phase, our team will produce detailed documentation on a public repository that outlines the specifics of how PocketRS will be structured. We will ensure that the API is presented to the community for both review and the submission of constructive feedback.

Month 2 through Month 4 - The Design and Release of PocketRS V0.5
During this phase, our team will be designing the structure of the library. During this phase, we will provide a public crate that users can use to beta test the package for local testing only. Progress will be transparent and made through frequent submissions of code to PocketRS’ public Github repository.

Documentation at the function level will be provided at the V0.5 launch.

Month 4 through Month 6 - The Design and Release of PocketRS V1.0
The public API will be finalized during this phase. Additionally, any reasonable feedback provided by the community will be implemented during this time. Progress for V1.0 of PocketRS will have advanced beyond the current offerings of contemporary software packages like what PocketJS provides. Full use-case and individual function documentation will be provided after this phase.

Month 6 through Month 18 - Ongoing Maintenance & Community Support
The consequent twelve calendar months after PocketRS V1.0 will consist of the active maintenance and occasional feature improvements to PocketRS. Additionally, any changes in the official Pocket Network clients will be reflected in PocketRS.

During this time, a community forum of choice (Telegram / Discord) will be staffed with a PocketRS & PocketJS expert to provide active and consistent responses for community members and developers (seasoned and new devs alike).

At the close of this period, our team will pass the stewardship of the PocketRS to community development. At this time, we will provide an additional PEP proposal to continue support. However, if this proposal fails to be voted on positively, we will appoint community leaders who are interested in continuing support.

Regarding Budgetary Constraints. Where will the POKT be used?

We hope this attached budget will be sufficient to satisfy the justified concerns to how JAMSO Financial Group will utilize capital in the constraints of PEP-19. Our senior accountant/compliance officer has provided the attached document.

As our primary expense is salaries and our employees are already on payroll (with benefits for US staff), we are obligated to provide consistent pay throughout the project. As we cannot speculate on the future price of POKT, we find our accepting of funds in small increments of volatile tokens tied to a fixed budget in USD to be irresponsible as an employer. As such, we’ve budgeted our operating expenses at the current market rate of POKT (1 USDC/POKT) and are asking for this proposal to be paid in full.

Our standing in this space as a reputable institution is immensely valuable as we serve, in addition to the POKT community, a network of VC contacts and web3 token corporations. We are fervent with the mindset that the mutual benefit of PocketRS to the POKT token will far outweigh the operating costs of which we are asking.

As I am a new user, I am only able to reply with one media message. Attached is Exhibit B of our budget outline.

Thanks @JAMSOFinancialGroup for all the responses and information. Every piece of information is helpful when trying to decide on a proposal of this magnitude.

With the information shared thus far, this is where I’m currently at:

The hang-up for me right now is I don’t understand the proposed cost. For 500k POKT I would expect a full Rust node client as an alternative to pocket-core, not an API SDK. I would venture to say that PocketJS itself hasn’t had 500k POKT worth of work put into it in the first place, so paying that much for a port, I don’t understand. I also can’t justify the need for funding this much staff for this port.

Since there isn’t an approachable technical spec to gauge the scale of this project (outside of being a direct port), I would want developers who are familiar with Pocket to weigh in on if this proposal is worth the amount, taking into consideration what PocketJS is today. If we pay 500K for a SDK port to a less popular language like Rust, how much are we expected to pay for the popular languages that would have more demand (like Python, Java, or Go) and require much more support?

I would also want to hear from Pocket devs on what their plans are for PocketJS and information about other SDKs under development. If there are major changes in the pipeline, then I’d be concerned with changing timelines or additional costs. Pocket 1.0 has already been talked about in community calls, and with moving completely away from Tendermint, that in itself would probably require new SDKs. If the budget for this port costs this much, I’d be concerned about the cost to port a Pocket 1.0 SDK to Rust.

I’m also uncomfortable that it’s being asked for all upfront. If this was a reimbursement for work, then all upfront makes complete sense, but not for such a huge payment where the real product isn’t expected for 6 months. While I understand working for a volatile token is challenging (which I have done for years), I don’t see why a payment plan, when specific milestones are met, is seen as unfeasible. I firmly believe DAO work should come with a premium because of volatility and other factors, but I don’t believe the only way to counter volatility is to pay upfront, especially with such an enormous ask. If there was a track record of delivering on past proposals, I could see the DAO trusting with an upfront, but that trust would need to be earned IMO.

Ultimately there is a lot of blind trust that I would have to put into voting yes for this proposal. I’m not prepared to do that at this time, especially since the asking amount is far beyond what I would have expected for an SDK.

Hi, @shane .

Firstly - thank you for your response. It is our sincere hope that the professionalism and transparent financials that we’ve provided will become the norm for PEP proposals to come. Regarding PEP-19, we are sorry to read that you do not share our vision of the immense value that PocketRS will bring to the network & community in, what we feel, is a comparatively low fee.

As a team experienced in adapting projects to, and creating ones in, the Rust language, we don’t advise anyone to look at this as just “an API SDK” or limited to a “less popular language like Rust.” The fault in this line of thinking limits the benefactor(s) of a project such as PocketRS to a low level expectation and result - the exact opposite of what we are doing.

In terms of the revenue growth to the community fund that PocketRS will provide, we find it prudent to look to Pocket’s relays. According to the RelaysToTokensMultiplier parameter, 0.01 POKT is generated per relay as a block reward. Of this, the DAOAllocation parameter extracts 10% for 0.001 POKT per relay. Following this, just 500m relays would need to be generated as a result of the PocketRS client for the DAO to, essentially, break even. As Pocket is rapidly expanding, and many of its metrics such as this one with it, this outcome is all but guaranteed (nota bene: The Pokt.Network site offers a metric of over 1,000 Million relays per week). Furthermore, with proposals such as PUP-11 currently being deliberated on, we expect the number of relays required to match 500k POKT to be less than these calculations.

As per our proposal, we plan to provide compiled C-binaries on the PocketRS repository which leverage the high-level aspects of Rust. These C-Binaries can be natively used in the wrapping of popular languages like Java, Python, and GO to provide further support. This speaks to your other point - in the long run this project will only make future implementations cheaper and easier, saving the DAO money.

Additionally, we will be providing the community and client with rich documentation for PocketRS. The lack of sufficient documentation is a major barrier to entry for many developers. As an example, to utilize PocketJS to our needs, our team had to spend days understanding the source code of the package to find which bindings to use. Our team is a diligent and determined bunch - others may not be as interested when alternate large-scale providers exist.

What we believe is that each of these efforts outlined in the proposal will reach, and exceed, the 500M relay goal to reimburse the DAO. A razor-fast client, the C-bindings for the bootstrapped development of binding support in other languages, rich documentation, and professionally staffed community support is a major value-add for the Pocket Network.

More revenue and users for the project and decreased future costs are the key takeaways here.

Rust is in no way an easy language, and because of this, after our analysis and discussion with our most senior Rust expert, the team can only be this small. 2,080 man hours per person is the estimate we have drawn up as a conservative deliverable timeline on PocketRS. That includes 6 months each of full-time work at a regular workweek (although we are sure there will be many late nights that turn to early mornings) and 12 months of half time work at half a regular workweek. The calculation is as follows : 26 weeks (half year) x 40 hours = 1040 + 52 (full year) weeks of support x 20 hours a week. In terms of seeing our support now, I recommend contacting us on telegram and chatting with us in our telegram, using our POKTPriceBot valued by the community, or even taking a peek in the Spanish channel we have created for the community.

Exhibits A and B provide more detailed explanations of those costs, and the salary and loss hedging involved, follows below.

At a base level, we share and understand your sentiments toward being paid in cryptocurrency for your work. Your designs on NodePilot and the upcoming Node Launcher are exceptional, and we look forward to seeing the directions you take with Decentralized Authority.

Although we founded Jamso Financial Group on these principles, our engineers have families who expect to receive consistent fiat for their time and effort. For example, if we were to obtain 50,000 POKT a monthShane at market value now to pay salaries for the first three or four months, that would work well at current market rate. But, what if the price of the token changes? In February the token price could be 10 dollars, but what if it isn’t? If the price drops to 10 cents, now still fixed on a base rate of the original 500,000 total at 50,000 a month, we can’t pay staff and the project goes defunct. Then the DAO is out of not only 200,000 POKT, but also does not get to see a high value project unfold. For better or worse, to get good developers in this space, especially at so below going market rates (about 450,000 a year in some startups), consistent and assured payment is necessary. As much as the owners of JAMSO love POKT, it is hard to make our employees love it enough to work for uncertain salaries and wishful thinking.

Please do not forget to consider that this is an 18 month project and it requires, at most, 53.85 dollars per highest paid employee per hour. To give you scope on salaries in the United States (not sure if you are from here), one of our existing members worked recently at Ernst & Young, LLP, one of the largest professional services firms in the world, and charged 155 dollars an hour as a senior staffer. Compared to what we are asking here, and the professionalism and experience we are offering, this is, if anything, a discounted offer to the community for a high level of work product.

In terms of knowing us better, the idea that we are invisible in the community or hidden in any way are false. Daily, we proudly wear who we are on our sleeve as we work with and on behalf of the POKT community. Between the hundreds of thousands of dollars we trade honestly and successfully for JAMSO community-vetted OTC members, one of our members working part-time on POKT INC’s sensitive financials, our full legal incorporation in Wyoming, USA, full commitment to regulatory compliance we have provided, and the multiple times we have provided free resources to the community, “blind trust” is not something we are asking anyone to deal in. Being heavily involved in the community-resources section, including the recent rise of POKT pools, this point is only driven further. It’s true that we are a newer player in the POKT scene, but we are confident that we have proved ourselves time and again to earn the community’s faith. To that point, as this is the community fund, we have come here, and not POKT Network Inc. or one of the other several DAOs we work with, to submit this proposal.

Regarding trust, we firmly believe in transparency. If you’re interested, we’d love to connect for a chat with our team. We want the opportunity to show you our workings - please set up a call with us using or chat with us on Discord or Telegram.

Jamso Financial Group is very committed to creating a strong relationship with this DAO, and we know, for reasons mentioned above, that this as an excellent value-adding project to start with. We have other ideas that we want to implement, but many of those rely on this initial implementation to not only establish a groundwork, but also once again prove our trustworthiness and high-level product output ability. With this we are sure that we can materialize massive benefits for the POKT community for not months or years, but decades, to come.

From here-on, we completely open the floor to any developers who are interested in discussing the positives and negatives of this implementation and its effect on the network. As one last note to the budget and cost of the project, we have allocated funds to paying any consulting fees required to liaise with the POKT development team to discuss upcoming and planned future changes to PocketJS (see exhibit B). We outlined a promise to reflect any changes from PoketJS and our goal is to start development with full communication with one or more of the development team directly.

I appreciate the detailed response and especially the professionalism shown when faced with criticism. I really value the open discussion you are willing to have :slightly_smiling_face:

That is a good point. C-binaries would open up those type of opportunities down the road.

Considering 100% of Pocket’s relays come through the Portal because of it’s QoS and backup infra features, I don’t know if I agree with this reasoning. This is why I asked what features may be built into PocketRS (beyond PocketJS), because the current PocketJS isn’t robust enough to compete with the Portal. Granted, Pocket 1.0 will probably change things a lot and make direct SDK integrations more feasible for applications, but I feel that is too far down the road to quantify the market impact of today’s PocketRS proposal.

I for one am aware of your comms in the unofficial Telegram. I don’t believe anyone meant to infer that you are invisible or hidden.

I was not aware that JAMSO team members work for Pocket Network Inc as well. This is new to me and I’m sure the community as well.

I think this goes to show there is a lot I did not know about JAMSO, and I’m happy to continue learning more. Have you considered doing a PocketRS presentation in a community call?

Agreed. Hopefully we’ll have more dev folks join the convo. I’m very open to having my mind changed :slightly_smiling_face:

Following up here. I appreciate the large volume of transparency and detail.

A few more questions and thoughts, if you don’t mind.

Would it be better to re-adjust this proposal to ask for $500,000 in POKT at a given point (or points in time) vs 500,000 POKT up front? Therefore, you’re not affected by the fluctuating nature of the token price, and the DAO may not need to give away as many tokens if the price does go up (as we’ve seen over the last week).

Next, I think payment should come out over some fixed amount of time, (e.g., quarterly), where progress can be assessed. Therefore, the DAO pays you upfront to do 3 months (6 sprints) worth of work and then assess progress and the viability of the project (e.g., hedging their bets and putting pressure on you all to deliver). This forces a roadmap to be made and adjusted as needed (according to agile best practices). I mention this because the $500k you’re asking for amounts to seed-stage funding (on the lower end) for a non-existent project which no one is asking for right now. I get that this is your goal for the future (see your own quote below), but I don’t think the project is there yet.

As per our proposal, we plan to provide compiled C-binaries on the PocketRS repository which leverage the high-level aspects of Rust. These C-Binaries can be natively used in the wrapping of popular languages like Java, Python, and GO to provide further support. This speaks to your other point - in the long run this project will only make future implementations cheaper and easier, saving the DAO money.

Pocket hasn’t even reached 1.0.0 status, so the current API contract is not guaranteed to hold. Therefore, timing for this proposal/request may not be right for a project of this nature, which is predominantly why I am having the contrarian reaction here.

Lastly, as you are an OTC and all of the individuals on the team are all current employees of the company already, does it make sense for the DAO to be financially obligated in covering all of the benefits (e.g., insurance, employee benefits, etc.). I am assuming the OTC-side of the business will still be running and the profits made there can cover the non-raw-labor costs.

Thanks for hearing me out - I hope you understand my position here.

1 Like

Hi, @shane and @ArtSabintsev !

Please excuse the late reply. Regardless, I hope your holidays have been going well. I will try to answer you both in a detailed, but concise, fashion.

Mainly to @shane :

We would be more than happy to lead a formal presentation to the community on this point. I think having a sit down with our chief Rust developer will be very valuable to the community. In that call we can go through all of the value-adds that will undoubtedly arise from this implementation.

We are seriously looking forward to this - please reach out at and we can set something up!

To @ArtSabintsev :

I agree with you on your first point. Having a fixed amount paid out, at a Fair Market rate of 500,000 USD(C/T), regardless of the POKT rate at the time, would be smart. After reviewing previous PEPs and other proposals in this space, we did not know this was an option. If we can contract with the DAO to make this happen, as milestones are reached, and we can cover costs safely, I would be happy to adjust the proposal.

To your point on a “non-existent project which no one is asking for right now.”

Although in terms of production this is in a very nascent state, I think this is more a point to be made on the nature of a DAO. As of right now, the DAO is actually not asking for anything. So, for better or for worse, it is left up to the community to find ways to add value. Until the DAO produces up a list of project contracts it wants completed to advance the network (not a bad idea), the projects proposed here will mostly be things “no one is asking for.”

Regarding your point on the timing of this project, I would love to discuss that further in a community call. I think that will be the best place to weigh the benefits and/or disadvantages of the client’s proposed start / release date in the context of PNI’s release schedule.

To be clear on salaries and costs: JAMSO OTC is not providing the services of this proposal. JAMSO Professional Services, a distinct service line of Jamso Financial Group, LLC, organized in Wyoming, is making this proposal. For more clarity, Jamso Financial Group, LLC is the parent organization of three subservice lines: JAMSO OTC, NodeFolio - A Node Running Company, and JAMSO Professional Services.

The profit and cost-centers of JAMSO Professional Services will be involved in this proposal upon approval. Furthermore, JAMSO OTC runs at a revenue rate that covers costs in its own realm of the business and is not expected to be a part of this PEP proposal - a rate that is currently the lowest in the market to promote fair and open access to POKT. This decision was made because when cost sharing starts to bleed into different related business sectors, this is a co-mingling of risk that is inadvisable for three distinct service lines with three distinct goals, clients, costs, and functions. Thus, OTC employees are not the main ones working on this project. Simply put, regarding why benefits are structured as they are, this is one of the few ways we can get highly experienced developers, who are in high demand by companies like Apple, Google, Facebook, Microsoft, and the likes of other Web 3 blockchain firms. Getting this type of talent to come on for projects for substantially lowered potential salaries is a challenge in-and-of itself. Furthermore, in terms of “raw labor costs,” in reality we are sacrificing those to give employees peace of mind with benefits they give up when they leave “traditional” jobs.

Overall, this market is incredibly competitive whether in regard to labor requirements or just the sheer volume of projects in the space. The key to understanding success in this space is knowing, at this point in a project such as POKT, that a touch of the “traditional” is necessary. As much as this may irk many idealists in the crypto-space, when this touch and flair is added, projects will only grow when highly experienced professionals and serious associations of talent see a meaningful reward for helping a community on timescales like the one we have proposed.

This is what JAMSO culminates to.

Community motivation is a key component of any early crypto project. This pattern of community drive happened here in the early days of the POKT project. However, POKT has had the help of a Tampa-headquartered Delaware C Corporation behind it from the early days with employees, salaries, benefits, etc.

There has to come a time, especially with a treasury like the DAO at a grantor’s disposal, to draw in the professionalism and talent that makes projects win in the long run. Paying companies that employ engineers at competitive rates while offering valuable deliverables, security, as well as on time delivery and corporate level documentation, will place POKT on further track to come out ahead of competing services.

If you would like to setup a community call, you would need to contact @JackALaing (preferably in Discord) to make it happen. I don’t have those God-like powers :wink:

Would this be from James or John who would created the alpha version and would be developing PocketRS?

Questions and comments from someone with no technical background:

If PocketRS can help grow POKT’s market share, it’s a welcome initiative. While Mike’s optimism is heartening: “Pocket will unseat large-scale cloud infrastructure providers as the de facto IaaS of choice for crypto development,” such dominance is far from certain in the unpredictable, topsy-turvy crypto space. POKT must do all it can do to get an edge.

Question: Will PocketRS facilitate servicing the Polkadot ecosystem and parachains that use RUST?

What token corps and RUST projects? (Might be relevant.)

Community call seems to be a must. Mike should take part with other team members including technical expert. Meeting his team will be helpful.

As an aside, if Mike’s comments are valid, POKT should perhaps look at beefing up its Discord support and hand-holding services, especially until its own documentation is updated and enhanced.

Thanks for the detailed reply, once again. I understand what it takes to hire high-caliber talent as I am in the tech industry as well and am constantly on the hunt for great people to join my teams. Hear you loud and clear on why you’re looking for what you’re looking for.

To distill my current opinion, here’s where I currently stand and here are my current questions:

  • Do we really need this now? Jack is the best person to facilitate a Community Call to discuss this topic in depth.
  • Do the employees of Jamso Professional Services participate in any operations performed by the other Jamso subsidiaries? If so, then there is co-mingling, and the salaries/benefits should come from the original employment terms from the 5 members that were highlighted as working on this project. That does not mean Jamso shouldn’t be compensated at all, they definitely should be, but I think the converted USD amount is what’s getting to me here. Why? Established projects, like POKTScan and Node Pilot, have an outsized impact in the ecosystem, and have received DAO grants (after proving their worth), with amounts that are a fraction of what is being requested here.

I’m not saying we shouldn’t fund projects that are at the inception/pitch stage, but current precedent is smaller grants for established projects.

Thanks for continually entertaining my questions on this matter - I appreciate it.

@ArtSabintsev and @shane , and everyone else. I will reach out to Jack tonight to set up a call! Lets forward all questions here and future to that call so we can discuss them in length. Thank you again for the thoughtful inquiries! Apologies for the holiday delay on this!

1 Like

Firstly, apologies for the delay on my reply here, I was on vacation when this was being debated and am only now getting a chance to catch up.

Hear, hear! If a well-documented attentively-supported PocketRS can influence our culture for the better, I’d say this is money well-spent. Thanks for highlighting this value-add and I look forward to seeing these contributions, assuming this proposal passes.

My other concern was one that Shane echoed, regarding PocketJS’s likelihood of being overhauled in the near future and again with v1.0 on the horizon. But I believe you have addressed this below

I would support an adjustment of the budget to reflect the suggestion below, with the addition of payment milestones for the different stages of the roadmap, with payment conditions based on delivery of the features promised at each stage. Though I can’t personally comment on whether $500k is the appropriate valuation of the work.

Lastly, I’d be happy to coordinate a call. I’ve been contemplating governance calls already so this could be a good topic to kickstart that practice.